dd en cours d'exécution après la fin du périphérique d'entrée

Aug 18 2020

J'essaye d'utiliser ddpour cloner un disque dur que j'ai réparé. J'essaie de ddcopier les données du lecteur en morceaux de 10 Go, mais il transfère plus de données que le lecteur ne devrait en contenir. Le lecteur lui-même fonctionne et la partition qui s'y trouve peut être montée.

En utilisant, df -hj'ai obtenu que la taille du lecteur soit de 1000204886016 octets (lecteur de 1 To).

J'ai d'abord essayé:

sudo dd if=/dev/sdb of=/dev/sdd status=progress

Cependant, cela a ralenti à une analyse après environ 300 Go, et a finalement échoué en raison d'une erreur de lecture. J'ai décidé d'essayer de le copier en morceaux de 10 Go. J'ai calculé que la lecture de 10 Go avec une taille de bloc de 128 ko nécessite la copie de 78125 blocs.

Pour ce faire, j'utilise:

sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=n

ddsignalait que 10240000000 octets étaient transférés à chaque fois. Pour calculer la valeur de recherche pour chaque itération, j'ai agrégé les octets transférés et soustrait 1 Go pour m'assurer qu'il y avait un certain chevauchement. La séquence résultante est:

seek=0
seek=9240000000
seek=18480000000
seek=27720000000
seek=36960000000
...
seek=1071840000000

J'ai écrit ceux-ci dans un script shell avec des commandes dd discrètes et je l'ai exécuté. J'ai laissé la dernière itération libre pour copier autant de données que nécessaire.

sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=0
sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=9240000000
sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=18480000000
sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=27720000000
sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress oflag=seek_bytes seek=36960000000
    ...
sudo dd if=/dev/sdb of=/dev/sdd bs=128k status=progress oflag=seek_bytes seek=1071840000000

Il aurait dû courir bien au-delà de la fin du lecteur par cette dernière itération, mais il a continué. Le clone monte, mais est clairement corrompu et il manque des données.

  1. Y a-t-il quelque chose qui ne va pas avec mes calculs ou les arguments avec lesquels j'ai utilisé dd?
  2. Existe-t-il un meilleur moyen pour moi d'écrire une commande «dd» pour extraire les données par blocs de 10 Go?

Réponses

3 thatotherguy Aug 18 2020 at 02:31

Le problème est que vous supposez qu'il seekprend une valeur d'octet, alors qu'en réalité il prend un nombre de blocs. Vous devez utiliser seek=0, 78125, 156250, etc.

Cependant, vous pouvez beaucoup le simplifier en vous débarrassant de dd:

split -b 10G < /dev/sdd
3 roaima Aug 18 2020 at 06:36

J'essaye d'utiliser dd pour cloner un disque dur que j'ai réparé

Ne fais pas ça.

Utilisez à la ddrescueplace, qui résiste bien aux blocs illisibles et aux autres erreurs multimédias.

2 alphasierra Aug 21 2020 at 03:06

J'ai découvert que la raison pour laquelle ma solution avait échoué était de mal comprendre ce que faisait l'indicateur de recherche. Il ne faisait que déplacer l'emplacement d'écriture sur le lecteur de sortie. Le script copiait donc sans cesse les 10 premiers Go sur la sortie. Il n'atteindrait jamais la fin de l'appareil.

Pour décaler l'entrée, l'indicateur de saut doit également être utilisé:

sudo dd if=/dev/sdb of=/dev/sdd bs=128k count=78125 status=progress skip=n seek=n

Le réglage oflag=seek_byteset iflag=skip_bytespermettra au calcul d'être fait en octets plutôt qu'en blocs.

Cependant, les options présentées par roaima (utilisez ddrescue) et cet autre guy ( split -b 10G < /dev/sdd) sont un meilleur moyen de récupérer des disques endommagés et d'effectuer des transferts segmentés respectivement.