Paramètres optimaux pour la réalisation d'une image système avec dd

Bonjour,

Pour réaliser une image système de la carte SD d'un Raspberry Pi sur un périphérique branché en USB, j'utilise la commande suivante:

Code:

---

dd if=/dev/mmcblk0 | pv | dd of="/chemin/fichier.img" && sync

---

ou

Code:

---

dd if=/dev/mmcblk0 | pv | gzip | dd of="/chemin/fichier.img" && sync

---

si je veux une image compressée.

Voici ce que j'ai constaté:

Avec un RPi3, avec ces paramètres par défaut, la copie se fait correctement, aussi bien avec que sans compression.
L'image disque est parfaitement lisible depuis un logiciel d'archivage sous Windows.

Avec un RPi 1B, la copie se fait correctement, mais lorsque je veux vérifier l'image avec mon logiciel sous Windows, il échoue en indiquant un .img défectueux (cela dans les 2 cas, avec ou sans compression).

J'ai tenté de modifier le paramètre bs en le passant à 4096 pour la réalisation de la copie depuis le RPi1B. Outre le fait que la copie se fait beaucoup plus rapidement (normal !), j'obtiens cette fois une image valide après vérification. Pensant avoir obtenu le beurre et l'argent du beurre (la qualité et la vitesse de la copie), je tente donc de passer le même paramètre pour la copie sur le RPi 3. Mais cette fois j'ai une image indiquée défectueuse lorsque je tente de l'ouvrir pour la vérifier !

Pour le RPi1b je copie sur un disque dur 2.5' portable datant de quelques années, pour le RPi3 sur un disque dur récupéré d'un PC portable assez ancien. Cela peut-il être l'explication du phénomène ?

Comme je réalise un script qui devra pouvoir être utilisé dans diverses configurations matérielles, quels paramètres optimaux utiliser avec la commande dd afin d'avoir une image valide dans tous les cas ?

Merci d'avance pour vos éclairages.

En utilisant cette commande:

Code:

---

dd if=/dev/mmcblk0 bs=4096 | pv | gzip -c >"$1" && sync

---

L'image obtenue depuis RPi3 est, cette fois, valide.

En utilisant une redirection plutôt qu'un pipe, l'image obtenue est-elle toujours bien une copie bit à bit et non une simple copie de fichiers ?
Autrement dit, en reconstruisant une carte SD depuis cette image système, aura-t-on bien un système bootable opérationnel ?

Je me réponds, tout au moins en ce qui concerne mon second message.

En relisant la man page de dd, on voit:

Citation:

---

of=fichier
Ecrire les données dans le fichier mentionné, et
non pas sur la sortie standard.

---

Donc, a priori, of agit comme une simple redirection, ce qui laisse supposer que la commande

Code:

---

dd if=/dev/mmcblk0 bs=4096 | pv | gzip -c >"$1" && sync

---

qui fait cette redirection, est tout aussi valide et copie bien bit à bit.

En poursuivant les tests, les surprises continuent. Si je fais la même opération cette fois sans compression, c'est-à-dire

Code:

---

dd if=/dev/mmcblk0 bs=4096 | pv >"$1" && sync

---

là l'image obtenue est reconnue comme endommagée.

Ayant fait des tests plus approfondis, j'ai constaté qu'une même commande pouvait parfois donner aussi bien une image correcte qu'une image corrompue.

La réalisation des images étant faite à chaud (sur un système en fonctionnement), j'émets l'hypothèse que l'image réalisée peut être corrompue dans le cas où le système procéderait à certaines écritures pendant la sauvegarde.
Quelqu'un peut-il confirmer ou infirmer cette hypothèse ?

Dans l'affirmative, existe-t-il des solutions permettant de "geler" le système pendant la réalisation de l'image système et de le réactiver en fin de copie ?

Code:

---

kill stop

---

puis

Code:

---

kill cont

---

par exemple permettrait-il de faire cela ? Dans ce cas, comment effectuer la sélection des processus à stopper ?

Bonjour,

Citation:

---

La réalisation des images étant faite à chaud (sur un système en fonctionnement), j'émets l'hypothèse que l'image réalisée peut être corrompue dans le cas où le système procéderait à certaines écritures pendant la sauvegarde.
Quelqu'un peut-il confirmer ou infirmer cette hypothèse ?

---

Sachant que c'est la chose à laquelle j'ai pensé en lisant votre premier message, je pencherai pour cette hypothèse.

Je ne sais pas comment on pourrait bloquer toutes les écritures (et cela me semble un petit peu dangereux, dans le sens où je pense que cela freezerai le système).

Je suis totalement dubitatif.
Je viens de refaire un test sur le RPI3, non utilisé comme serveur, et sans toucher au système pendant la réalisation de l'image.
J'ai utilisé

Code:

---

1 2	dd if=/dev/mmcblk0 | pv | dd of="$1" bs=4096 && sync

---

et là, image endommagée !

Alors que

Code:

---

dd if=/dev/mmcblk0 | pv | dd of="$1" && sync

---

est passé ainsi que

Code:

---

dd if=/dev/mmcblk0 bs=4096 | pv | gzip -c >"$1" && sync

---

:koi:

Non utilisé ? Ça veut dire partition démontée ?

Ce que je voulais dire, c'est qu'il s'agissait d'un système indépendant qui ne risquait pas d'être utilisé en dehors des actions que j'y ferais explicitement. Autrement dit, aucun risque d'écriture sur la carte SD pendant la phase de réalisation de l'image système.

Je ne comprends pas le sens de indépendant. Est-ce qu'elle est montée la partition ? Ou montée en read only ?

Le système est un système basé sur Raspbian, relié au réseau mais ne jouant aucun rôle dans le réseau (donc normalement pas de risque d'écriture intempestive sur la carte mémoire liée à une requête extérieure comme cela peut arriver sur un système faisant office de serveur). La sauvegarde se fait depuis un script s'exécutant dans le système lui-même, sur un disque dur monté en USB. Une fois la sauvegarde lancée, je ne touche plus au système pour ne pas provoquer d'écriture sur la carte SD.

Vous ne faites aucune interaction avec le système, soit, mais rien ne vous assure qu'il n'y a pas d'écriture (tester avec iotop). Le noyau est toujours actif, les daemons aussi et ainsi de suite.
Démonter une partition permet de s'assurer de l'absence de son utilisation :aie:. Sinon, il faut la passer en read-only.

Citation:

---

Envoyé par LittleWhite

Vous ne faites aucune interaction avec le système, soit, mais rien ne vous assure qu'il n'y a pas d'écriture (tester avec iotop). Le noyau est toujours actif, les daemons aussi et ainsi de suite.

---

Tout à fait. C'est pourquoi je n'ai dit nulle part qu'il n'y avait aucun risque d'écriture. Je ne peux que ne pas en provoquer. Ce qui est étrange c'est que certains paramètres échouent systématiquement, alors que d'autres réussissent souvent, mais pas forcément systématiquement.

De nombreux articles ou tuto sur le web présentent proposent la commande dd sous diverses formes pour faire des images système à chaud, notamment pour des serveurs qui ne peuvent être déconnectés.

La question est donc: cela est-il vraiment possible sans risque d'image endommagée par des écritures intempestives ?

On en revient à ma question posée par la suite: est-il possible de "geler" provisoirement et sans risque le système ? C'est ce que tu sembles évoquer en parlant de le passer en read only. Est-ce faisable à chaud ?

Sous Windows, il existe le système Shadow copy qui permet de faire des sauvegardes de systèmes en cours d'utilisation.

Par ailleurs, avec Raspbian Stretch, est apparu un outil permettant de faire un clone du système à chaud, piclone. Mais l'outil ne permet pas de faire une image système, juste de cloner sur une autre carte montée en USB avec un adaptateur.

J'ai peut-être une piste que je vais explorer.

Code:

---

1 2	service --status-all

---

permet d'afficher l'état des services, et donc de savoir ceux qui sont actifs. En stoppant les services avant copie, puis en les redémarrant ensuite, on doit pouvoir éviter les accès intempestifs sur le système pouvant provoquer l'échec de la copie. Toute le problème est de déterminer, parmi les services actifs, ceux qui peuvent ou non être arrêtés sans problème par rapport à la tâche à effectuer.

Si vous avez des pistes sur ce sujet !

Voici un retour pour ceux que la question intéresse.

Jusqu'à présent, j'avais vérifié la validité des images en tentant de les monter sur un système Linux, ou de les ouvrir depuis un gestionnaire d'archive sous Windows. Très souvent cela échouait, et me laissait croire à un problème lors de la phase de copie du système dans le fichier image en raison d'écritures intempestives liées à des services fonctionnant en tâche de fond.

J'ai donc exploré la piste d'arrêt des services avant copie, puis redémarrage des services après, et je suis arrivé au même constat.

J'ai donc refait des tests plus approfondis en allant jusqu'à la reconstruction de l'image sur une autre carte SD pour en vérifier la validité. Et là je me suis aperçu que toutes les images faites en test, même sans arrêt des services, étaient valides.

Réaliser une image par la commande dd qui fait une copie bit à bit est fiable, même à chaud. Mais cela semble présenter un inconvénient par rapport aux méthodes mixtes (copie bit à bit des seuls secteurs système et ensuite copie des fichiers) utilisées par d'autres outils :

• les gestionnaires d'archive échouent souvent à ouvrir de telles images ;
• le montage de l'image sous Linux est plus délicat, mais peut quand même se faire.

Pour réussir un montage sous Linux, il faut procéder de la manière suivante:

On affiche les partitions contenues dans l'image

Code:

---

fdisk -lu test.img

---

On note la valeur start (ou départ) de celle des 2 partitions que l'on veut monter
On calcule l'offset par
offset = valeur du start x 512
On crée un répertoire de montage

Code:

---

sudo mkdir /media/mapartition

---

La commande habituelle

Code:

---

mount -o loop,ro,offset=xxxxx monfichier.img /media/mapartition/

---

échoue, mais on peut réussir le montage en utilisant l'option supplémentaire norecovery ou noload

Code:

---

mount -o loop,ro,norecovery,offset=xxxxx monfichier.img /media/mapartition/

---

ou

Code:

---

mount -o loop,ro,noload,offset=xxxxxx monfichier.img /media/mapartition/

---