GZip de l'image de lecteur créée à l'aide de la commande `dd`
J'ai créé hier une image de disque avec GZip.
J'ai ouvert le fichier 51.3 GiB nommé ssd.img.gz pour voir une icône qui représente un paquet de 3,9 GiB, oui, celle-ci représente la taille de neuf gigaoctets et porte le nom suivant: l'image en tant que ssd.img
Cela ne me semble pas correct, la création d’images a-t-elle fonctionné ou non?
Oui, les disques contiennent des données et un système d'exploitation.
Aurais-je dû utiliser cat à la place? seulement je le faisais et il a continué à dire qu'il n'avait rien à faire.
Est-ce que l'utilisation du | Zip à la place serait une meilleure option?
** EDIT **
La commande utilisée était:
mark@zotac:~$ Sudo -l
Enter password:<entered password to get in to root>
root@zotac:~# dd if=/dev/sda | gzip -c > "/media/mark/Seagate External Drive/ssd.img.gz
le terminal a passé la plus grande partie de 10 heures à créer l’image, quelque chose en lui-même que j’ai aussi trouvé suspect;.
Le lecteur source /dev/sda n'avait aucune partition montée.
** EDIT **
Juste pour clarifier les choses, j'essaie de créer une image du lecteur pour la sauvegarder ultérieurement si des problèmes se produisent lors d'une réparation. Le lecteur lui-même doit être un fichier sur un lecteur, car la partition du lecteur cible utilise presque tout le lecteur. les partitions ne peuvent pas être redimensionnées sans le formater et je ne vais pas perdre 1,4 To de données.
Donc, le dd if=/dev/sda of=/<target> n'est pas ce dont j'ai besoin, ce dont j'ai besoin, c'est d'une image du lecteur sur laquelle je puisse restaurer l'image à partir du lecteur si la réparation tourne mal.
Alors, quelle commande dois-je utiliser, dd ou chat? Pourquoi | Zip n'arrête-t-il pas de me dire qu'il n'a rien à faire lorsqu'il est utilisé avec cat mais pas d'erreur ou d'avertissement avec dd
Si le disque est presque plein, il n’ya aucun sens à compresser l’image; cela prendra des siècles sans effet pratique. Et la restauration sera aussi beaucoup plus lente.
dd copie des disques ou des partitions physiques, octet par octet. Cela fonctionne en lisant N octets à partir de l'entrée et en les écrivant dans la sortie, puis en les répétant. N est par défaut 512 octets .
Pour copier physiquement un disque/une partition, utilisez
dd bs=10M if=/dev/sda of=/path/to/dest/image.img
cela lira des blocs de 10 Mo à la fois. Si vous avez beaucoup de RAM, vous pouvez également augmenter ce nombre. La taille du fichier sera exactement la même que la taille du disque/de la partition utilisée (mais il peut occuper moins de disque parfois --- dd peut créer des fichiers fragmentés).
Vous pouvez vérifier la progression dans un autre terminal avec
ls -lh /path/to/dest/image.img
qui vous donnera la taille du fichier image (plus ou moins - ce sera en morceaux, vraiment).
Vérifiez trois fois (avec mount) qu'aucune partition du disque à copier n'est montée ou utilisée n'importe où, sinon l'image créée ne sera pas valide (et les pires situations peuvent également se produire). Faites également attention aux zones d'échange.
Vous pouvez monter l'image pour vérifier si elle fonctionne correctement avec un système de fichiers en boucle et quelques astuces .
Quoi qu'il en soit, il existe également des outils d'aide aux tâches: Comment créer une image disque et la restaurer plus tard?
Si votre système n'est pas récent (le système à partir duquel vous démarrez, je veux dire), soyez averti de ce bogue --- corrigé à partir de 14.04, mais toujours présent pour les anciens noyaux .
La compression de l’image d’un lecteur entier ou d’une partition à l’aide de Gzip peut entraîner une réduction considérable de la taille du fichier, mais uniquement dans le cas où aucun reste de données inutilisé stocké et l'espace non utilisé est rempli uniformément , par exemple par Zéros.
Cela peut être le cas pour un lecteur très récent, très peu utilisé, ou pour un lecteur où nous avons rempli manuellement l’espace inutilisé avec des zéros (par exemple, en utilisant l’utilitaire zerofree ).
Ce n'est cependant pas le cas pour un ancien lecteur utilisé où les restes de données seront dispersés de manière aléatoire sur tout le lecteur, pour un lecteur où un effacement sécurisé a été rempli espace inutilisé avec des nombres aléatoires, ou après un cryptage disque total. Dans ces cas, Gzip ne pourra pas compresser autant ou pas du tout (les nombres aléatoires ne peuvent pas être compressés).
Il en va de même pas le cas pour un SSD utilisé en écriture pendant un certain temps car à chaque écriture, tous les blocs de mémoire seront répartis de manière égale sur tout le lecteur par firmware du lecteur pour éviter l'usure nivellement. Ensuite, toute compression d'une image compressera également ces restes de données qui seront de plus en plus aléatoires dans le temps.
Ainsi, dans votre cas, une image compressée de 3.9 GiB d'un SSD de 50 GiB _ peut être possible pour un lecteur relativement récent peu utilisé ou pour un lecteur principalement utilisé pour la lecture mais pas pour l'écriture. sur elle. Mais alors c'est une valeur raisonnable.
Pour le savoir, il faudrait décompresser l'image pour comparer son contenu avec la source.