'dd' peut-il être utilisé pour cloner sur un disque dur plus petit, sachant que les partitions devront être modifiées?

J'ai l'habitude ddde cloner des disques comme celui-ci:

 dd if=/dev/sdb of=/dev/sda bs=4096 conv=notrunc,noerror,sync

Et ça a toujours bien fonctionné. Tous les documents sur 'dd' prennent soin de vous rappeler que le disque cible doit être de la même taille ou plus grand que la source. Cela doit-il absolument être vrai?

Maintenant, je comprends très bien que si je clone sur un disque plus petit, je ne peux pas m'attendre à ce que les partitions qui sont même partiellement «hors limites» sur la cible soient intactes.

Cependant, sachant très bien que je devrais éditer mes partitions sur la cible plus tard, en supprimant celles «hors limites», pourrais-je toujours utiliser «dd» pour faire une copie en force brute de la source jusqu'aux limites de la taille physique de la cible? Ou "dd" réduirait-il la cible à une pile d'épaves fumantes lorsqu'elle atteindrait la limite de sa taille ;-)

BTW, la recherche, j'ai vu les valeurs recommandées pour bs=tout de bs=1024jusqu'à bs=32M, ce qui est vraiment mieux?

Le lecteur physique ne devrait pas commencer à fumer, au moins, mais les chances sont très bonnes que votre système de fichiers ne fonctionne plus (je veux dire, le système de fichiers cible; si vous venez de copier et de ne rien toucher dans la source, la source elle-même devrait être bien ). Les données à l'intérieur d'une partition ne sont pas nécessairement allouées dans l'ordre croissant. Une partie peut être à la fin de la partition même si la partition n'est pas pleine (en fait, je pense que cela se produit de manière déterministe avec certains systèmes de fichiers, mais je n'en sais pas assez pour entrer dans les détails). Les données qui s'y trouvent peuvent être essentielles à l'intégrité du système de fichiers. Je vous conseille donc fortement de ne pas vous fier à une telle copie.

Si vous voulez faire cette copie, vous devez d'abord réduire la partition avec un outil qui est conscient de sa structure interne et est capable de tout remapper en bon ordre dans une partition plus petite. Ensuite, vous pouvez faire la copie. gpartedest une bonne interface graphique pour faire ce genre de choses.

Pour la bsvaleur, la meilleure idée est généralement d'avoir quelques tests avant de commencer la copie réelle. Il existe des outils qui vous aident à automatiser cette vérification, mais je ne me souviens pas du nom. D'après mon expérience, la meilleure plage est généralement comprise entre 4M et 16M. Plus haut que cela, vous ne gagnez plus beaucoup. Mais cela dépend de beaucoup de choses, y compris des disques eux-mêmes. Par exemple, j'ai rarement travaillé avec de vrais disques haut de gamme, qui peuvent convenir à des valeurs plus élevées en raison d'une vitesse et d'une taille de cache plus élevées.

MODIFIER Si une partition est entièrement copiée, vous pouvez l'utiliser sans problème. Cependant, comme d'autres l'ont souligné, vous devez également vous assurer que la table de partition est intacte (au moins, les entrées pertinentes). Avec les quatre partitions principales de MBR, il n'y a aucun problème, car ils sont décrits dans les 512 premiers octets du disque. Les partitions logiques sont décrites tout au long de la partition étendue, de sorte que les entrées peuvent être perdues (mais elles décrivent les partitions qui seraient perdues de toute façon). Avec GPT, il existe une copie de la table de partition au début et à la fin du disque. Vous perdez le second, mais vous pouvez le reconstruire à partir du premier. Bien sûr, il est conseillé de le faire dès que possible; d'autres réponses étaient plus précises à ce sujet.

Bien qu'au début, le «défi» proposé puisse sembler difficile, non réalisable ou naïf comme certains l'ont commenté, ce n'est pas le cas. L'idée principale derrière l'utilisation de dd pour migrer d'un disque plus gros vers un disque plus petit est parfaitement correcte et présente des avantages pour la migration des données. Bien sûr, avoir suffisamment d'espace libre pour que les données occupées tiennent dans le disque de destination est une condition nécessaire.

L'idée est de penser à définir chaque partition individuellement et non le disque entier à la fois comme initialement proposé. Encore plus peut être accompli: la ou les partitions qui seraient tronquées peuvent également être migrées en toute sécurité avec un peu d'aide des outils de redimensionnement du système de fichiers. En effet, ce type de migration est intéressant afin de préserver les matadonnées du système de fichiers et les attributs de fichier étendus qui ne peuvent pas être facilement copiés avec des outils comme cp, rsync, pax, ... qui opèrent dans la couche système de fichiers et non bloquent la couche périphérique. L'utilisation de dd élimine le besoin de réinstaller le système d'exploitation ou d'avoir à renommer le FS afin d'éviter les problèmes avec SELinux.

Voici ce que je fais habituellement pour accomplir des tâches similaires:

1) Vous devez d'abord réduire le ou les systèmes de fichiers dans les partitions affectées qui seraient tronqués. Pour cela, utilisez l'outil resize2fs (en supposant que nous parlons d'un fs ext2 / ext3 / ext4 - d'autres FS modernes ont également des outils de redimensionnement dans le même but). Notez que bien que - pour des raisons évidentes - un système de fichiers ne puisse pas être plus grand que la partition dans laquelle il réside, il peut en toute sécurité être plus petit. L'astuce de sécurité consiste à réduire "plus que nécessaire". Par exemple: imaginez que vous avez un système de fichiers de 1 To que vous souhaitez migrer vers un lecteur de 500 Go. Dans ce cas, je suggère de réduire le fs à, disons, 450 Gig (vous devez avoir suffisamment d'espace libre pour cela, bien sûr, c'est-à-dire que l'espace actuellement occupé dans ce système de fichiers ne peut pas dépasser 450 Gig). Le gaspillage apparent de 50 Go d'espace sera corrigé après la migration des données.

2) partitionner le disque de destination avec la géométrie appropriée compte tenu de ses contraintes d'espace;

3) dd les données en utilisant le ou les périphériques de partition et non le périphérique de disque (c'est-à-dire, utiliser dd if=/dev/sda# of=/dev/sdb#pour chaque partition au lieu d'utiliser if=/dev/sda of=/dev/sdb). REMARQUE: sda et sdb ne sont que des exemples; REMARQUE IMPORTANTE: lorsque vous passez d'un périphérique de partition plus grand à un périphérique de partition plus petit, dd se plaindra de la tentative d'écriture de la publication à la fin du périphérique de bloc, ce n'est pas grave car les données du système de fichiers auraient été entièrement copiées avant d'atteindre ce point. Pour éviter un tel message d'erreur, vous pouvez spécifier la taille de la copie à l'aide de bs=et les count=paramètres pour correspondre à la taille du système de fichiers réduite, mais cela nécessitera un calcul (simple), mais s'il est mal fait, vous risquez vos données.

4) Après avoir défini les données, redimensionnez à nouveau le ou les systèmes de fichiers respectifs dans la ou les partitions de destination à l'aide de resize2fs. Cette fois, ne spécifiez pas la nouvelle taille du système de fichiers. Lorsqu'il est exécuté sans spécification de taille, resize2fs agrandit le système de fichiers afin qu'il occupe la taille maximale autorisée.Par conséquent, dans ce cas, le système de fichiers de 450 Gig se développera à nouveau pour occuper la partition entière de 500 Gig et aucun octet ne sera gaspillé. (L'approche «réduire plus que nécessaire» vous évite de spécifier accidentellement des tailles incorrectes et de risquer vos données. Notez que les unités GB vs GiB peuvent être délicates).

Remarque pour les opérations plus complexes: si vous avez un gestionnaire de démarrage que vous avez l'intention de copier, ce qui est très probablement le cas, vous pouvez dd les premiers Ko du disque en utilisant le périphérique de disque au lieu des périphériques de partition (comme dd if=/dev/sda of=/dev/sdb bs=4096 count=5), puis reconfigurez la géométrie dans / dev / sdb (qui contiendra temporairement une géométrie non valide pour le nouveau lecteur mais un gestionnaire de démarrage intact et valide). Enfin, utilisez les périphériques de partition comme décrit ci-dessus pour effectuer une partition à la fois. J'ai fait des opérations comme celle-ci plusieurs fois. Tout récemment, j'ai réussi une migration complexe lors de la mise à niveau d'un disque dur contenant un mélange d'installations MacOSX et Linux vers un SDD plus petit dans mon MacMini6,2. Dans ce cas, j'ai dû démarrer Linux à partir d'un disque externe, défini le gestionnaire de démarrage, exécuté gdisk pour corriger le GPT dans le nouveau disque et finalement défini chaque partition contenant les systèmes de fichiers juste rétrécis. (Notez que le schéma de partition GPT conserve deux copies de la table de partition, une au début et une à la fin du disque. gdisk se plaint beaucoup car il ne peut pas trouver la deuxième copie du PT et parce que les partitions dépassent la taille du disque, mais il corrige correctement le problème de copie du PT après avoir redéfini la géométrie du disque). C'était un cas beaucoup plus complexe, mais qui mérite d'être mentionné car il illustre que ce type d'opération est également parfaitement réalisable.

Bonne chance! ... et surtout n'oubliez pas de sauvegarder toutes les données importantes avant ce type d'opération. Une erreur et vous pouvez sûrement endommager irrémédiablement vos données.

Et juste au cas où je ne soulignerais pas assez: sauvegardez vos données avant la migration! :)

Si vous souhaitez installer une voiture dans un passage plus étroit de 20 cm que la voiture et que vous coupez les 20 cm de gauche de la voiture, la voiture fonctionnera-t-elle toujours? Probablement pas.

Si vous copiez un début de disque sur un autre disque et coupez court à la copie car le disque cible est plus petit, le résultat ne fonctionnera pas. Même s'il y aurait suffisamment d'espace pour contenir tous les fichiers sur le disque cible, couper après N octets depuis le début du disque ne vous donnera pas un système de fichiers fonctionnel.

Si le disque est divisé en partitions de style PC (GPT ou MBR), toutes les partitions qui tiennent entièrement sur la cible fonctionneront. Il y a une exception: avec les partitions MBR, si les partitions logiques ne sont pas numérotées dans l'ordre du disque, alors dès que la chaîne quitte la zone cible, les partitions ne seront plus répertoriées. (Si vous ne comprenez pas cela, c'est une raison de plus pour ne pas faire une copie partielle du disque.) Il serait beaucoup plus logique de copier les partitions que vous souhaitez conserver, au lieu de copier depuis le début et de vous retrouver avec ce qui vous convient . La partition partiellement copiée à la fin ne sera pas utilisable.

Si le disque ou une partition partielle est un volume physique LVM et que vous effectuez une copie partielle de ce volume physique, vous ne pouvez pas non plus être sûr d'obtenir des données utiles du résultat.

Si vous souhaitez copier uniquement certaines des données d'un disque volumineux vers un disque plus petit, créez des partitions sur le disque plus petit. Si vous souhaitez copier une partition sur une partition de même taille, vous pouvez le faire avec cat. Si vous souhaitez copier une partition sur une partition plus petite, créez un système de fichiers sur la partition cible et effectuez une copie au niveau du fichier avec quelque chose comme cp -aou pax -rw -pe -t.

Vous pouvez utiliser à la ddplace de catsi vous êtes masochiste. dda une étrange syntaxe et est généralement plus lent quecat si vous ne trouvez pas la bonne taille de tampon. Il n'y a pas de valeur optimale unique pour la taille de la mémoire tampon, cela dépend des caractéristiques de votre matériel. Si la taille est trop petite, vous ddperdrez du temps à effectuer de nombreux transferts minuscules. Si la taille est trop grande, vous ddperdrez du temps à lire entièrement un tampon avant de commencer à écrire le suivant. La taille optimale pour un transfert de disque à disque est généralement de quelques mégaoctets (1024 octets est ridiculement petit). catchoisira une taille décente sans effort de votre part.

J'aimerais partager mon expérience avec ce sujet, si cela s'avère utile à un autre lecteur. Récemment, j'ai utilisé DDRESCUE pour récupérer le premier tiers d'une partition NTFS à partir d'un disque dur défectueux, et j'ai réussi à reconstruire le segment récupéré de la partition sur un disque dur plus petit - sauvant ainsi les fichiers capturés (et perdant le reste). Voici les étapes que j'ai suivies en faisant cela (certainement une approche HACKSAW !!) ...

Le disque dur source était composé de 750 Go au format NTFS avec une table de fichiers MBR. Je ne l'avais utilisé que quelques fois pour sauvegarder des fichiers, donc la plupart des fichiers étaient au début du lecteur, d'une valeur d'environ 160 Go. Un membre de la famille a fait tomber le disque dur (monté à l'extérieur) sur le sol - il n'a jamais fonctionné correctement après cela! En utilisant ddrescue (minutieusement), j'ai pu récupérer une grande partie du début du lecteur. En raison des dommages physiques, il s'est arrêté très fréquemment tout au long du processus ...

J'avais un petit disque dur d'ordinateur portable disponible de 150 Go (monté en externe), sur lequel j'ai extrait les données ddrescue directement. Sinon, j'aurais pu extraire les données dans un fichier image, puis monté le fichier, mais j'ai pensé que l'écriture des données directement sur un disque dur était plus simple.

L'astuce clé du sauvetage consistait à modifier manuellement les données MBR et NTFS Boot Sector sur le disque dur de secours. Sans cela, le disque dur n'est reconnu par aucun système d'exploitation. Je n'ai pas pu trouver un programme approprié sous Linux pour le faire, alors je me suis tourné vers Windows. Il existe un package pratique nommé Windows Support Tools, qui n'est plus maintenu mais toujours utile (voir le lien ci-dessous)! L'outil que j'ai utilisé pour modifier la partition est Disk Probe. Assurez-vous de connaître la valeur du secteur final de votre disque dur (j'ai utilisé fdisk -l dans Ubuntu)

https://en.wikipedia.org/wiki/Windows_Support_Tools

En utilisant une bonne calculatrice et un peu de créativité, j'ai chargé et monté le disque dur dans Disk Probe dans Windows et édité les valeurs du secteur final. Dans le MBR, deux ensembles de valeurs ont dû être modifiés, à savoir a) le secteur final du disque dur et b) le secteur final de la partition NTFS. Dans le secteur de démarrage NTFS, la valeur Total Sectors de la partition a dû être modifiée. Dans chaque cas, la valeur numérique a été diminuée afin de correspondre à la "dimension" diminuée du petit disque dur (les secteurs finaux sont passés de 750 Go à 150 Go). Cliquez sur l'onglet Affichage pour modifier ces valeurs.

Voici une image de Disk Probe en action éditant les données du secteur de démarrage NTFS

Lors de la modification des champs susmentionnés, Windows a reconnu la partition comme une partition valide bien qu'endommagée. Je suis entré dans l'invite de commande et j'ai exécuté le programme Windows Chkdsk sur le disque dur endommagé (chdsk D :). C'était excitant de voir la partition reprendre vie, fichier par fichier! Le programme a reconstruit la table de partition et remappé avec succès tous les fichiers qui avaient été copiés sur le disque dur endommagé. Les fichiers hors de portée (non copiés) sont introuvables et sont donc supprimés.

La partie suivante dont je ne comprends pas la raison, car Windows a réussi à reconstruire le disque dur de 150 Go avec les fichiers inclus. Néanmoins, Windows ne pouvait pas nativement ouvrir la partition du disque dur pour l'affichage des fichiers (il y avait une erreur). Cependant Ubuntu à la rescousse! J'ai redémarré dans Ubuntu, monté le disque dur externe et sans problème, tous les fichiers récupérés sont apparus!

Espérons que cette méthode de scie à métaux pour récupérer des fichiers d'un grand disque dur sur un petit disque dur se révélera utile à une autre âme pauvre en plus de moi. À votre santé!

Vous devez d'abord réduire les partitions sur la source (ou supprimer ces limites).
Ensuite dd, vous devrez probablement réparer la table de partition à l'aide de gdisk /dev/sd<target>
et la séquence de touches pour réparer la table est que v r d w
je vous suggère de réduire les partitions un peu plus petites que nécessaire et après les étendre à la taille complète du disque cible.
(Cette réponse est basée sur mon expérience personnelle lors du clonage de mon disque dur vers un SSD plus petit)