Comment manipuler une copie faite avec la commande "dd"?

non cela soutend que dd peut copier des blocs sans se préoccuper de savoir s’il y a des fichiers ou non. RAW Copy c’est de la copie de secteur par exemple.mais après tout dépend de ses options.
C’est bien pour ça qu’on ne peut pas faire de clef bootable avec cp, mais faisable avec dd.

On peut parfaitement faire une clé (ou un disque) bootable avec cp ou cat

https://www.debian.org/releases/stable/amd64/ch04s03.en.html

1 J'aime

En français c’est mieux.
https://www.debian.org/releases/stable/amd64/ch04s03.fr.html

Le sujet:
Comment manipuler une copie faite avec la commande “dd” ?

Cette nouvelle obstination et avalanche à vouloir tenter de démontrer que ‹ dd › serait subitement devenu ‹ useless › et à oublier est ridicule, même si un ‹ blogueur › (?) le pense, sans avoir compris ce qu’était dd qui est une opération système très bas niveau.
Essayez de faire ceci avec cp ou cat pour mieux comprendre le sens de ‹ raw copy › qui visiblement n’est pas compris:

dd if=/dev/zero bs=1 seek=446 count=64 conv=notrunc of=dd_image_file
dd if=/dev/sda of=/home/mbr_sauvegarde bs=512 count=1

La référence au wiki Debian:
cp debian.iso /dev/sdX

… ou écrire un fichier, non pas sur une partition, mais sur un disque complet, sans partition, donc rien à voir avec le clonage d’une partition vers une autre partition qui est le sujet. Certes, ça peut marcher pour un petit fichier, ou pas, mais reste ambigü, sans aucun contrôle, selon de la taille du fichier ou de la partition.
Les commandes cat ou cp n’ont jamais été prévues et spécifiées pour cloner des disques ou des partitions, ce qui ne veut pas dire que ça ne marche pas, un peu par hasard ou pas, mais pourquoi vouloir jouer avec des opérations non spécifiées, sans aucune option de contrôle ?
Un peu la roulette russe.

Ce sujet est noyé de considérations qui ne concerne pas la question, alors que je reste convaincu que la première question pour petitchat serait de clarifier ce qu’il veut vraiment faire de ce ‹ clone › (bit à bit) ou ‹ copie › ou ‹ archive › (compresssée ou pas) de partition.
Cloner, copier, archiver est une chose.
Comprendre ce que va se passer lors du ‹ déclonage › en est une autre.
Bonne expérimentation (le plus important…).
――――――――――――――――――――――――――
ps: mon avis est que cloner une partition bit à bit remplie à 10%, sans compression ne sert à rien (jamais fait ça).
Bien que je ne clone pas (inutile à mon avis), de mémoire, partimage faisait un bon job:
partimage : Sauvegarde de partitions dans un fichier image compressé

1 J'aime

Merci pour vos réponses. Alors oui j’aime bien bavarder mais je n’imaginais pas ces désaccords sur ce sujet.

je souhaite backuper mon système de façon fiable.

Ce sujet est noyé de considérations qui ne concerne pas la question, alors que je reste convaincu que la première question pour petitchat serait de clarifier ce qu’il veut vraiment faire de ce ‹ clone › (bit à bit) ou ‹ copie › ou ‹ archive › (compresssée ou pas) de partition.

Sur le plan pratique je voudrais pouvoir faire une sauvegarde de la partition système, la stocker quelque part (donc besoin de pouvoir la copier) et le jour où le disque système de ma machine rend l’âme, je voudrais pouvoir prendre un nouveau disque, restaurer dessus le système sauvegardé.
J’avais cru comprendre que « dd » était une commande dédiée à la réplication de partition avec prise en charge des secteurs d’amorçage.
Sur le plan intellectuel, mieux comprendre les différences entre « dd », « cp » et « cat ». S’il existe des commandes différentes c’est qu’elles sont utiles dans des situations différentes même si leur champs d’action peut se chevaucher.
Miaou

Sans bonne maîtrise, dd est dangereux, et sans compression
Pour aller piano, installe partimage et partimage-doc (dans les dépôts) et regarde si ça te va.
»» Partimage - Screenshots

« Sans compression » ça veut dire que si je dd une partition de 30Go avec 4Go occupés et 26 Go d’espace libre, alors le fichier image fera la taille de la partition soit 30Go et non pas 4Go comme on pourrait croire ?

je confirme avoir fait ça plusieurs fois avec cp et ça marche très bien. Mais ça m’a étonné aussi. ( cf. http://dindoun.lautre.net/spip.php?article165 : cp live-image-amd64.hybrid.iso /dev/sdg && sync )

Oui. dd fait une copie bit à bit, sans compression. Pas optimum du tout.
Partimage fait du bon job, bien rodé.
Tu peux essayer, tout en réfléchissant si c’est réellement bien du ‹ clonage › que tu veux faire, ou si de l’archivage pourrait suffire.

est une pure invention de ton imagination. Personne ici n’a rien soutenu de tel. On se borne à dire que dans le cas d’utilisation de cette discussion, cp et cat conviennent aussi bien.

Pas du tout. dd n’utilise que des fonctionnalités applicables aux fichiers normaux et non de « bas niveau », contrairement à hdparm par exemple lorsqu’il écrit ou lit directement dans un secteur. D’aileurs toutes tes commandes dd fonctionnent aussi bien avec des fichiers normaux comme source et destination.

Peu importe que ce soit un disque ou une partition, ce sont tous les deux des périphériques bloc pour lesquels cp ne fait aucune différence. Il copie le contenu, point.

Ni plus ni moins que dd, dont la plupart des options n’ont rien à voir avec les disques et partitions. Mais sous Unix, « tout est fichier » donc ce qui marche avec un fichier normal marche aussi avec un disque ou une partition.

La compression n’aidera pas beaucoup si les blocs inutilisés contiennent du bruit pseudo-aléatoire qui se compresse très mal. Ce qu’il faut, c’est ne copier que les blocs utilisés. Cela suppose d’avoir une connaissance du système de fichiers contenu dans la partition.

Mais d’après la description du paquet et sa page de manuel, il ne semble pas avoir été mis à jour pour prendre en charge les systèmes de fichiers récents comme ext4 ou btrfs, contrairement à son concurrent partclone. Contrairement à partimage, partclone ne fait pas de compression mais je suppose qu’on doit pouvoir compresser le résultat avec n’ilmporte quel compresseur standard. D’autre part il a une fonction que je trouve pratique permettant de créer un fichier image « creux » qui a la même taille apparente que la partition d’origine et qui est montable comme elle, mais qui n’occupe de l’espace disque que pour les blocs utilisés de la partition.

Pas du tout. dd est une commande généraliste qui permet de copier du contenu d’un endroit à un autre en appliquant optionnellement certaines transformations. Si tu crois que cloner la partition système va cloner le secteur d’amorçage (qui ne fait pas partie de la partition), tu te trompes lourdement et tu vas au devant de grosses déconvenues.

Exactement. Dans ton cas d’utilisation (création d’une image de partition), ils se chevauchent.

Non, aucun rapport. Tu confonds deux choses indépendantes :

  • le fait de ne copier dans l’image que les blocs utilisés de la partition (ce qui suppose de connaître le format de la partition, comme déjà dit plus haut)
  • le fait de compresser le contenu de l’image (qui ne nécessite pas de connaître le format de la partition)

Si les blocs inutilisés sont remplis de zéros, alors ça se compresse très bien. Mais c’est rarement le cas, sauf si on a activé le TRIM/discard (donc sur un SSD ou disque SMR) et que le disque a un TRIM de type RZAT (read zero after TRIM).

1 J'aime

Personnellement j’utilise clonezilla live pour faire ça. C’est efficace et je n’ai pas à installer quoique ce soit sur mon système.
et c’est simple à faire sans considérations de blocs avec des &zéros ou quoique ce soit d’autres. D’autant en plus que la partition clonée, peut être ensuite restaurées sur une partition égale ou plus grande que la partie clonée elle-même.

Sauf que dans mon cas particulier « cat » a plus de charme. :slightly_smiling_face:
La lecture de la discussion me donne envie d’approfondir sur les différences entre « dd », « cp » et « cat », c’est à dire me taper la doc. Sur le web j’ai trouvé des articles intéressants mais en anglais.
Partimage, Partclone: j’y réfléchis sérieusement. Mais je trouve que se débrouiller avec les commandes classiques est plus élégant si je peux.
Je comptais vaguement procéder ainsi:

  1. éteindre le système, mettre un disque amovible comme support de sauvegarde
  2. démarrer à partir d’une clé Debian
  3. repérer la partition source à copier et la destination, monter dans un dossier ce qui doit l’être puis:
  4. dd if=/dev/sda1 of=/destination/fichier
  5. tar -czvf /destination/sauvegarde.tar.gz fichier
    Pour restaurer le système plus tard:
  6. installer le disque système, le partitionner de façon à créer une partition de taille au moins égale à celle qu’on souhaite restaurer et avec le drapeau « boot »
  7. connecter le disque amovible qui contient la sauvegarde compressée
  8. démarrer avec une clé Debian. Si le disque lâche dans 4 ans, entre temps j’aurais certainement eu besoin de recycler la clé originelle, j’aimerais pouvoir démarrer d’une clé Debian avec la version qui aura cour alors.
  9. monter le disque amovible (source) et le disque système(cible, disons sda1)
  10. tar -xzvf sauvegarde.tar.gz
  11. dd if=sauvegarde of=/dev/sda1
    Est-ce naïf ?

Etapes 3 et 9 : la partition à sauvegarder/restaurer ne doit pas être montée, ni lors de la sauvegarde ni lors de la restauration sous peine de corrompre le résultat. Attention car certains systèmes live ont tendance à monter automatiquement tout ce qu’ils trouvent.

Les étapes 4 et 5 peuvent être combinées en compressant directement la sortie standard de dd sans passer par un fichier image intermédiaire. D’autre part, pas besoin de créer une archive tar pour compresser un fichier.

dd if=/dev/sda1 | gzip > fichier.gz

ou encore plus simplement

gzip -c /dev/sda1 > fichier.gz

et pour restaurer :

gunzip -c fichier.gz > /dev/sda1

Etape 6 : le drapeau « boot » ne suffit pas (voire ne sert à rien) pour rendre le nouveau disque amorçable. La première partie du chargeur d’amorçage se trouve toujours en dehors de la partition système, soit dans le MBR et d’autres secteurs du disque pour l’amorçage BIOS, soit dans une partition système EFI pour l’amorçage UEFI. Concrètement, il faut réinstaller le chargeur d’amorçage sur le nouveau disque.

A priori non, mais attention sur les partitions bootable. Une simple copie ne suffit pas forcement, j’ai parfois eu des problème avec ce type de méthode.

Merci ces précisions importantes. En fait c’est simple de sauvegarder sa partition système avec dd ou gzip. Mais oui, pour la restauration il faudra que ma machine démarre sur la partition système. C’est un autre sujet, celui ci est résolu. Je vais étudier comment démarrer d’une partition, il y a longtemps j’avais réussi un dual-boot entre Windows7 et une ubuntu (lucid) avec Grub2…

Petitchat est un(e) coquin(e)… pour faire parler les membres du forum, il/elle sait s’y prendre !

Sa question est bien vague… si tant est que l’on veuille bien y voir une question : « je souhaite backuper mon système de façon fiable » et si oui, laquelle ?

Ou bien son « titre » : comment-manipuler-une-copie-faite-avec-la-commande-dd?

Pour ce qui et du titre :
tout dépends de ce qui a été copié avec dd (ou tout autre outil, pour ne fâcher personne !)

En ce qui concerne la fiabilité… si Petitchat veut par là dire fidèle (la copie…!!!) à l’originale, il y a des versions de dd un peu plus orientées
vers cet usage :

https://dcfldd.sourceforge.net/

Kali linux live en « boot » forensic" est alors une version de debian plus adaptée pour ce type d’opération…

Pour ce qui est de la fiabilité de la copie, je pense qu’il s’agirait en l’occurrence de disposer de matériel de qualité (fiabilité matérielle, capacité suffisante et système de fichier de stockage (xfs, mais c’est un autre sujet) et éviter tout risque de coupure ou microcoupure d’alimentation électrique ou surchauffe pouvant générer des erreurs de lecture ou écriture …

Quant à manipuler l’image, crée par dd ou non, il est possible de monter l’image en écriture, mais dans quel but??

Si, en réalité, ton objectif petitchat, en dehors de suciter une discussion,
est de pouvoir rétablir l’état antérieur du disque pour un usage courant,
la procédure de la documentation de dd de ArchLinux est des plus « fiables » :
https://wiki.archlinux.org/title/Dd


A-pour générer l’image (du disque entier), comprimée

dd if=/dev/sdx conv=sync,noerror status=progress bs=64K | pigz -c | split -a3 -b2G - /path/to/backup.img.gz 

sdx pour un disque sata et sda , en général ($ lsblk ou $ df -h f ou # disk -l …)

pigz au lieu de gzip pour utiliser les ressources des cpu multi-coeur et split pour fractionner l’image afin d’éviter des soucis de taille du fichier image.

  • La taille du bloc peut être ajustée
    (par essais de 30s répétés …) pour réduire quelque peu le temps de création de l’image.
    La taille du cache du disque est la valeur recommandée… Mais la taille par défaut de 512 permet en contrepartie de minimiser la répercussion des erreurs à la lecture si le support source est endommagé…

B- Et pour la restauration… ATTENTION, CELLE-CI DÉTRUIT TOUTES LES DONNÉES présentes sur le support de destination of=

# cat /path/to/backup.img.gz* | gunzip -c | dd of=/dev/sda  status=progress

Quant à l’utilisation de cat et CP comme alternatives, c’est fort intéressant (mais dans quel but…), je « donne ma langue au chat », à Zargos, Verner, Dindoun, Bruno1 et PascalHambourg!

Mais je suis curieux de vous lire…

Donc si je comprends bien, au moment de la sauvegarde , je ne monte pas la partition source (que je sauvegarde) mais la compresse avec gzip -c vers un fichier sur une partition, elle, montée ?
Et au moment de la restauration, je ne monte pas la partition cible (vers laquelle je vais restaurer), par contre je monte normalement la partition contenant fichier.gz et là je gunzip -c ? Pardon d’insister mais je n’ai pas tellement envie de perdre mes heures de paramétrage.

D’autre part - alors là c’est la suite de la manœuvre, je peux ouvrir un nouveau post si on me demande - concernant la sauvegarde du MBR j’ai lu sur le net cette manip.
Pour sauvegarder le MBR (c’est à dire les 512 premiers octets), en admettant que le disque soit /dev/sda:
dd if=/dev/sda of=mbr.sav bs=512 count=1
et pour restaurer :
dd if=mbr.sav of=/dev/sda bs=512 count=1
Question: au moment de la restauration, est-ce que l’ordre entre la restauration du système et du MBR a son importance ? Dois-je par exemple d’abord restaurer le système puis le MBR, ou l’inverse ?

En fait si tu as fait unensauvegarde de tout le systeme (des partitions), normalement, tu as le MBR qui est dedans.

Oui. En résumé rien d’autre ne doit lire ou écrire dans cette partition de quelque façon que ce soit pendant la sauvegarde et la restauration sous peine de créer des incohérences. Or monter le système de fichiers d’une partition, c’est donner au système la possibilité d’y lire ou écrire à tout moment.

Pourquoi veux-tu sauvegarder le MBR (et seulement le MBR) ?

« Le système », ça ne veut rien dire, c’est vague.

les partitions de la machine.