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.
Je pensais qu’étant sur les premiers octets du disque le MBR devait se trouver sur la première partition. Là j’ai une sauvegarde de « / », le plan c’est de pouvoir la restaurer et démarrer dessus. Avec le nouveau disque: partitionnement = une partoche pour « / », une partoche pour la swap, une pour « home ». Ensuite il faut gunziper ma sauvegarde de la partition Debian. Mais à cette étape, si je redémarre la machine, elle ne va pas savoir démarrer sur la bonne partition si on ne restaure pas le MBR. D’ailleurs il faut faire comment, installer grub sur le nouveau disque suffit ?
Remarque: ceci pourrait donner lieu à un tutoriel, après tout restaurer une machine c’est le B.A.BA de l’admin system
J’ai pris l’habitude de séparé l’utilisation du mot sauvegarde et clonage.
Pour faire de la sauvegarde j’utilise les outils les plus simple et facile d’utilisation Timeshift et Sauvegardes (je sépare le système de mes données, la fréquence d’execution est bien plus élevé pour mes données que pour mon système qui ne bouge que peu).
Pour des serveurs outre l’utilisation d’un etckeeper pour plus de souplesse nous avons une politique de sauvegarde un peu spéciale, nous ne conservons que ce que nous ne pouvons pas reconstruire à l’identique (vue que nous utilisons abondamment des outils tel que Terraform et Ansible, les machines sont inconstructibles rapidement).
Maintenant de souvenir cloner un disque j’utilisais ça :
dd status=progress if=/dev/sda of=/dev/sdX bs=100M
bien entendu il faudra adapter les disque et le bs au matériel.
Mais comme dit plus haut la manière la plus safe est de réaliser un clone système éteint avec un outil fais pour au format image (cela permet ensuite de monter l’image sur ton système pour venir piocher au besoin des choses dedans).
Non, la première partition n’empiète pas sur le MBR. (Il y a des exceptions comme les images ISO hybrides de Debian ou le format de table de partition Sun/BSD mais on ne trouve pas ça sur une installation normale)
Si le but est de pouvoir restaurer l’amorçage BIOS, alors sauvegarder et restaurer le MBR n’est pas suffisant car le MBR ne contient que la première partie de GRUB (boot image), la suivante (core image), trop grosse pour contenir dans le MBR, est ailleurs (emplacement variable selon la situation) et doit être restaurée exactement au même endroit. Si on fait une copie des partitions et non du disque entier, il est probablement plus fiable de réinstaller GRUB avec grub-install.
Dans le cas d’un amorçage EFI, le MBR ne sert à rien, c’est la partition EFI qu’ll faut sauvegarder.