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. 
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:
- éteindre le système, mettre un disque amovible comme support de sauvegarde
- démarrer à partir d’une clé Debian
- repérer la partition source à copier et la destination, monter dans un dossier ce qui doit l’être puis:
dd if=/dev/sda1 of=/destination/fichier-
tar -czvf /destination/sauvegarde.tar.gz fichier
Pour restaurer le système plus tard: - 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 »
- connecter le disque amovible qui contient la sauvegarde compressée
- 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.
- monter le disque amovible (source) et le disque système(cible, disons sda1)
tar -xzvf sauvegarde.tar.gz-
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.
Sauf que des éléments du « système » peuvent être en dehors des partitions (chargeur d’amorçage BIOS, noms et UUID de partition utilisés notamment dans les entrées de boot EFI) voire carrément en dehors du disque (entrées de boot EFI dans la NVRAM).
C’est une partition, ou ça fait partie d’une partition;Cependant pour la NVRAM effectivement, mais je ne crois pas que le cas discuté ici utilise cette particularité.
Non, les entrées de boot EFI ne sont pas dans des partitions ni même sur le disque.
On n’en sait rien. Le fait est que ça fait partie du « système », donc si on veut sauvegarder « tout le système », faire une image des partitions ne suffit pas forcément.
Et tu devrais même pouvoir monter (avec -o loop) un fichier copié avec dd pour le tripatouiller de l’intérieur.
pas d’accord:
la partition avec le petit rond gris est celle de l’EFI.
Parce que la partition qui contient Debian « / » n’est pas en début de disque. D’après fdisk -l (j’envoie au besoin), en début de disque il y a la partition d’échange. Du coup je n’ai pas le MBR dans ma sauvegarde, je ne me rappelle plus pourquoi je n’ai pas laissé la partition au début. Je vais devoir sauvegarder cette partition aussi. Le jour où il faudra remplacer le disque, sur le nouveau disque j’aurais à restaurer les deux partitions. C’est vrai en fait pas besoin de sauvegarder juste le MBR.
Oui en fait ça peut désigner « operating system » ou « file system », je me demande si l’anglais « system » se traduit en français si naturellement que ça en « système ».
Et alors ? Je répète : une entrée de boot EFI n’est pas une partition EFI.
Quel rapport avec le MBR ?
Tu ne l’aurais pas de toute façon. Le MBR n’est dans aucune partition.
La partition de swap ? Strictement aucun intérêt. Pour la restaurer il suffira de la recréer avec le même UUID (figurant dans /etc/fstab).
Mais tout ça ne nous dit toujours pas pourquoi tu veux sauvegarder le MBR.