Sauvegarde disque complet

Bonsoir, j’ai une petite question bête…

Jusqu’à aujourd’hui, j’utilisais partimage pour sauver mes partitions…

Aujourd’hui, j’ai un pc, dont je voudrai sauver la totalité du disque… si je fais :

lorsque que je restorerai, mon image sera t’elle bien bootable ?

Merci :slightly_smiling:

PS:

Pour restaurer cette partition, j’utilise quelle commande si je veux passer par un pipe ?

salut.

clonezilla te permet de sauvegarder un disque en entier et de le copier sur un autre disque dont la taille est au moins égale à celle du disque origine.

[quote=“vohu”]Bonsoir, j’ai une petite question bête…

Jusqu’à aujourd’hui, j’utilisais partimage pour sauver mes partitions…

Aujourd’hui, j’ai un pc, dont je voudrai sauver la totalité du disque… si je fais :

lorsque que je restorerai, mon image sera t’elle bien bootable ?

Merci :slightly_smiling:

PS:

Pour restaurer cette partition, j’utilise quelle commande si je veux passer par un pipe ?[/quote]

perso j’utilise cette syntaxe, testée et marche chez moi :slightly_smiling:

le disque sera conforme a l’original,il faut donc qu’il soie déjà bootable avant (mai rien n’empeche de le faire après si il s’agit juste du tag), note pas encore tester pour un disque ssd , mai d’après ce que j’ai pu lire a droite et a gauche sa ne devrai pas non plus être un problème.

marcastro: je ne vois pas le rapport avec sa question et dd ?

Un lien qui va t’interesser: guides-info.org/linux/admin/cloner.php

[quote]Clonage direct de disque dur

* Requis : un PC, au moins 2 disques (celui où cloner étant de contenance égale ou supérieure à celui à cloner), & les partitions ne doivent PAS etre montées
* Sauver l'image exacte du premier DD et de son secteur de boot (MBR) avec :
  dd if=/dev/hda of=/dev/hdb, puis
  dd if=/dev/hda of=/dev/hdb bs=512 count=1
  Ici hda = le premier DD du PC & hdb le 2nd DD.
  Après quoi le DD 2 est la copie exacte (clone) du DD 1.

[/quote]

Merci panthere et yanlolot :slightly_smiling:
Ca confirme ce que je me demandais,

Par contre, puisque je redirige la sortie de dd vers un pipe, pour compresser, j’arrive pas à trouver la commande inverse pour restaurer sans passer par une décompression préalable de l’archive gz
:blush:

Bonjour,

salut tous!

@panthere: [quote]marcastro: je ne vois pas le rapport avec sa question et dd ?[/quote] aucun rapport en effet,n’ayant moi même jamais cloné de hd à l’aide de “dd” je ne pouvais pas lui répondre sur ce coup là mais je lui ai refilé l’info concernant clonezilla,on sait jamais ,peut toujours servir. :006

mais je profite pleinement des infos de yanlolot que je remercie au passage :023

Note:

dd if=/dev/hda | gzip > fichierdebackup.gz

et

zcat fichierdebackup.gz > /dev/hda

marche également.

Le dd count=1 fait un backup du premier secteur inutile ici puisque déjà fait. C’est utile si on fait un backup des partitions seulement.

J’utilise

dd if=/dev/hda bs= 512M | gzip > fichierdebackup.gz

qui améliore la vitesse (mais il faut de la RAM)

Rq: On a eu une discussion avec cep pour les disques SSD. Cette méthode marquera tous les blocs comme écrit ce qui fait que le controleur devra effacer les blocs avant de les réécrire. En clair, si l’OS et le SSD supportent l’optimisation TRIM, celle ci ne sera pas efficace avant un certain délai. D’après cep c’est à prendre en considération (et il n’a sans doute pas tort). Un backup idéal est donc plutôt dans ce cas un tar et un dd du secteur de boute afin de reconstruire le système de fichiers plutôt que de partir d’une image globale.

C’est grave ?? cela veut juste dire que ces blocs seront bloqués et donc ne seront pas “usés” ?

Ca veut dire qu’on ne peut pas utiliser cette méthode ? celle de gzip ? ou celle avec l’option bs=512 ?
On peut faire un pipe avec tar ? mais, quelle est la différence ? c’est juste un fichier compressé non ?
(dsl :blush: je comprends pas trop)

Alors

  1. Ce n’est pas grave, ça donne juste une écriture un tout petit peu moins rapide.

  2. Le principe du trim est d’effacer à l’avance des blocs. Prenons un exemple: tu as un backup d’un disque (SSD ou non) de 40G. Bon. Tu as un disque SSD neuf de 40G que tu veux utiliser à la place. Ce disque a tous ses blocs pre-effacés.

M1: Tu utilises le bon vieux dd et écris sur tout le disque SSD. Dans ce cas, tous les blocs sont considérés comme écrits. Lors de l’écriture d’un fichier, ces blocs devront être effacés avant d’être réecrits d’où un petit délai supplémentaire. Ce délai jusqu’à ce qu’un bloc soit libéré (par effacement d’un fichier) puis réutilisé.

M2: Tu partitionnes ton disque (au besoin en écrivant juste le secteur 0), tu formates les partitions (donc n’écris que sur quelques blocs) puis recopies les fichiers 1 par 1 à l’aide de tar par exemple. Il n’y aura eu aucune écriture sur les blocs libres restant et, lors d’une écriture ultérieure d’un fichier, ceux ci seront toujours effacés. Tu bénéficieras d’un gain de temps.

OKKKKKK, oui en fait, quand tu disais “tar” tu parlais de compresser les fichiers, le contenu du disque, plutot que l’image du disque…

Merci de m’avoir éclairé :stuck_out_tongue:

En cas de crash d’un DD et si l’on restaure sur un DD de plus grande capacité, qu’advient t-il de l’espace non alloué sur le nouveau DD ? faut t-il repartitionner ensuite ???

Exemple :

[code]Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a6102

Device Boot Start End Blocks Id System
/dev/sda1 * 1 19457 156288290+ 5 Extended
/dev/sda5 1 122 979902 83 Linux
/dev/sda6 123 244 979933+ 82 Linux swap / Solaris
/dev/sda7 245 19457 154328391 83 Linux

Disk /dev/sdc: 300.1 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf836211d

Device Boot Start End Blocks Id System
/dev/sdc1 1 36483 293049666 83 Linux

Disk /dev/sdd: 300.1 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf836211d

Device Boot Start End Blocks Id System
/dev/sdd1 1 36483 293049666 83 Linux

Disk /dev/sdb: 82.3 GB, 82348277760 bytes
255 heads, 63 sectors/track, 10011 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00026c2c

Device Boot Start End Blocks Id System
/dev/sdb1 1 10011 80413326 83 Linux
[/code]

Si j’ai un DD pour sda de 500Go , que deviennent les 340Go (théorique qui reste…)

Je pense qu’ils restent libres

Je dois donc repartitionner sda après restauration ??

Je pense oui, du coup, aprè les explications de fran.b je pense que sa solution convient mieux pour une restauration sur un support de taille différente

Je pense comme franb que chaque cas est particulier.
Si on veut cloner tout son disque pour le reporter sur un disque de technologie différente la meilleure solution n’est pas dd, mais du sur mesure.
Maintenant, si on veut faire une sauvegarde totale de son disque pour la conserver à l’abri et la reporter ensuite sur le même disque dd a tout son sens, quitte à faire un peu de ménage d’abord avec des zéro sur les parties non occupées ou autre moyen.
Mais, même dans ce cas on peut aussi envisager, pour gagner du temps si le disque est très gros, de ne récupérer que les données avec rsync, tar, ou autre, de faire une copie des 512 octets du mbr et de ne pas oublier, s’il y en a, de faire une copie de l’emplacement des partitions logiques, par exemple avec sfdisk :
sfdisk -d /dev/hda >table_sda.out
et lorsqu’il faudra réinjecter la table :
sfdisk /dev/hda < table_sda.out

Voir man sfdisk. Ensuite remettre le mbr sauvegardé avec dd, refaire les systèmes de fichiers, puis recopier les données.

C’est moins simple mais on part ainsi sur un fs propre, sur lequel si nécessaire on a reporté de nouvelles options non présentes lors de la création.

Mais, bien sûr, toutes les solutions ont leurs avantages et inconvénients, l’essentiel est d’avoir le choix, et de l’adapter à sa configuration, lvm, etc. etc.

p.s. malgré dd sur le mbr réinstaller grub car dd des 512 octets n’a pas sauvegardé les autres stages sur les octets suivants.

cepcasa > ta solution est super aussi, je l’utilise au travail. L’avntage, c’est qu’elle permet de s’adapter à un autre disque en modifiant le fichier texte de sortie.

Mais la méthode de DD à l’avantage de pouvoir restaurer tout une machine en une fois, sans se préocuper de rien. C’est ce que j’avais besoin pour une machine dont je me sers de serveur, avec trop de partitions, trop de manipulations pour réstaurer chaque partitions séparément, jvoulais un truc rapide :stuck_out_tongue: