# Remontage ro de la racine en ssh

**URL:** <https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615>\
**Category:** Support Debian\
**Created:** [Février 15, 2019, 10:54 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615 "2019-02-15T10:54:31Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Février 15, 2019, 10:54 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/1 "2019-02-15T10:54:32Z")

</div>

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é.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 15, 2019, 12:42 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/2 "2019-02-15T12:42:04Z")

</div>

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

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

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Février 15, 2019, 1:20 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/3 "2019-02-15T13:20:22Z")

</div>

> [@PascalHambourg](#):
>
> /var et /tmp sont séparés ?

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.

> [@PascalHambourg](#):
>
> Pourquoi veux-tu faire une image ? Une copie classique ne suffit pas ?

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 ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 15, 2019, 1:36 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/4 "2019-02-15T13:36:50Z")

</div>

> [@mattotop](#):
>
> seuls /boot et /home sont séparées

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…)

> [@mattotop](#):
>
> J’ai essayé partimage

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 ?

> [@mattotop](#):
>
> Et j ne peux pas dd ma home si elle est rw, si ?

Tu peux, mais l’image sera «&nbsp;sale&nbsp;» 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.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Février 15, 2019, 1:53 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/5 "2019-02-15T13:53:48Z")

</div>

> [@PascalHambourg](#):
>
> les déplacer hors du système de fichiers racine

Je vois. Un peu lourdingue.

> [@PascalHambourg](#):
>
> pourquoi une sauvegarde des fichiers ne suffirait pas ?

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.

> [@PascalHambourg](#):
>
> l’image sera “sale”

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

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 15, 2019, 2:23 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/6 "2019-02-15T14:23:56Z")

</div>

> [@mattotop](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Février 15, 2019, 4:08 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/7 "2019-02-15T16:08:57Z")

</div>

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/](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.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Février 15, 2019, 5:50 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/8 "2019-02-15T17:50:47Z")

</div>

> [@mattotop](#):
>
> 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.

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.

> [@PascalHambourg](#):
>
> Pense aussi à la configuration des paquets (debconf) le cas échéant.

**dpkg --get-selections** dans un fichier.

> [@PascalHambourg](#):
>
> Sinon, est-ce que tu as regardé du côté de dump/restore ? Jamais utilisé pour ma part.

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.

> [@Clochette](#):
>
> A voir si ça ne pourrait pas répondre à ton besoin

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.

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Février 15, 2019, 6:14 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/9 "2019-02-15T18:14:27Z")

</div>

> [@mattotop](#):
>
> **dpkg --get-selections** dans un fichier.

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`.

> [@mattotop](#):
>
> Je crois que tar fait tout pareil en fait, et que dump/restore est legacy.

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.

---

<div class="post-metadata">

**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\
**Post date:** [Février 15, 2019, 8:07 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/10 "2019-02-15T20:07:30Z")

</div>

> [@mattotop](#):
>
> 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.

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 :

> **[Borg Documentation — Borg - Deduplicating Archiver 1.4.5 documentation](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.

---

<div class="post-metadata">

**Author:** ![AnatomicJC](https://www.debian-fr.org/user_avatar/www.debian-fr.org/anatomicjc/32/3869_2.png) [@AnatomicJC](https://www.debian-fr.org/u/AnatomicJC)\
**Post date:** [Février 17, 2019, 7:07 UTC](https://www.debian-fr.org/t/remontage-ro-de-la-racine-en-ssh/78615/11 "2019-02-17T07:07:57Z")

</div>

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.
