Remontage ro de la racine en ssh

Support Debian
#1

Bonjour.
Il m’arrive un truc idiot:
je veux faire une image dd de ma partition racine (md1) dans un répertoire sur /home (md2) qui est séparée, et je n’arrive pas à me mettre en situation ou mon / est monté en ro.

Mon premier réflexe a été de remonter bêtement / avec -o remount,ro, mais ça m’indique que la racine est occupée.
Pas envie d’éplucher lsof pour comprendre quoi arrêter, je tente un passage en mode rescue systemctl isolate rescue.target
Oui, mais là, je n’ai plus ssh, zut.

Je suis en train d’essayer de passer par le kvm de mon hébergeur pour faire mon dd en mode rescue.
Avec un peu de chance, j’arriverais à faire marcher cette p17@1n de console…

Mais indépendamment de ça: comment fait on déjà pour remonter la racine en lecture avec juste l’accés à distance ?
Il faut arrèter quoi pour être sûr qu’il n’y ai plus rien qui bloque le remount,ro ?
J’ai oublié, désolé.

#2

/var et /tmp sont séparés ?

Pourquoi veux-tu faire une image ? Une copie classique ne suffit pas ?

#3

Non, seuls /boot et /home sont séparées, c’est la config par défaut chez online.
En fait, je veux scratcher la machine, mais avant, je veux faire un clone et voir si je peux la remonter sur une box.

J’ai essayé partimage avec une machine située dans le même DC, mais je n’arrive pas à faire causer client et serveur (le partimaged démarre, mais je ne vois pas de port sur lequel il écoute, ni de fichier de config ou le préciser).
L’idée de me faire une image locale dd et de la ramener aprés me semblait la plus simple.
Et j ne peux pas dd ma home si elle est rw, si ?

#4

Alors pour pouvoir remonter la racine en lecture seule il faut soit arrêter tout ce qui peut écrire dans /var et /tmp (logs…), soit les déplacer hors du système de fichiers racine (/tmp en tmpfs, /var déplacé dans /home et remplacé par un bind-mount ou un lien symbolique…)

A mon avis ça ne changerait fondamentalement rien par rapport à dd, ça reste une image disque.

Mais ça ne répond pas à ma question : pourquoi une sauvegarde des fichiers ne suffirait pas ?

Tu peux, mais l’image sera “sale” et possiblement incohérente si elle est prise lorsque le système de fichiers est monté en lecture-écriture. Il est plus facile de remonter /home en lecture seule : il suffit de se connecter directement en root, ou avec un compte utilisateur dont le répertoire n’est pas dans /home.

#5

Je vois. Un peu lourdingue.

Je sais pas.
J’ai déjà un tar d’etc, un export de la liste des paquets installés, et une sauvegarde des données utilisateurs et des bases de données, donc essentiellement, la machine est sauvegardée.
Mais c’est comme de mettre une ceinture avec des bretelles, je veux être sur d’avoir un clone qui tourne.

Ecoutes, là, je viens de lancer un clonage à distance de la partition montée:
ssh “sudo /bin/dd if=/dev/md1 | gzip -c” | dd of=root.raw.gz
Je verrais bien si elle est sale ou pas.

#6

Pense aussi à la configuration des paquets (debconf) le cas échéant.

Sinon, est-ce que tu as regardé du côté de dump/restore ? Jamais utilisé pour ma part.

#7

Nous cherchions une solution au taff plus ou moins scriptable pour permettre à des clients de faire un clone de leur système via le réseau.

J’avais tester quelque peu cette solution : http://www.mondorescue.org/

A voir si ça ne pourrait pas répondre à ton besoin, je pense qu’un de ces quatre je referais quelques tests pour intégration comme outil de clonage offert à nos clients.

#8

Donc j’ai fait des images sur un serveur à coté, ça s’est bien passé, mais je suis en train de rappatrier les 286G, et là je vais devoir attendre 36h de download pour savoir si c’est propre ou sale.

dpkg --get-selections dans un fichier.

Si, moi, j’ai du bricoler avec, mais c’était au temps des sauvegardes DAT ou bandes.
Je crois que tar fait tout pareil en fait, et que dump/restore est legacy.

Ben là c’est ponctuel et pas franchement critique, mais j’ai déployé quelques serveur et il est prévu que je mette en place une sauvegarde cloud+nas de tout.
Ce qui n’est pas encore clair avec mon partenaire à qui appartient cette infra, c’est la définition du tout (j’ai déjà des sauveagardes de toutes les données de sites et de domaines gérés), et le délai de remontage qu’il veut en cas de crash grave de ses machines.
Bref.

#9

Je ne parlais pas de la liste des paquets présents mais de leur configuration. Tu sais, les choix qu’on doit faire lors de l’installation ou lors de l’exécution de dpkg --reconfigure et qu’on peut afficher avec debconf-show.

D’après ce que j’ai compris, dump/restore est spécifique à ext* et peut fonctionner sur un système de fichiers non monté, donc non, ce n’est pas équivalent à tar.

#10

Dans ce cas des solutions de sauvegarde complète tel que fais BareOS serait un gros plus pour effectuer une restauration Baremetal, mais c’est clairement pas le même budget et volume de donnée à héberger.

Sinon en solution très efficace et facilement intégrable dans un script :

https://borgbackup.readthedocs.io/en/stable/

Par contre pas de baremetal il te faudra une base déjà installé avant la réintégration des données avec la complexité due au clé de chiffrement.

#11

Une idée en passant: booter sur un LiveCD ajouté dans grub.
Je l’ai fait récemment sur quelques serveurs de chez online pour les réinstaller en ZFS.