Récupérer les données d'un SSD moribond avec ddrescue
La semaine dernière, un de mes clients – un musicien professionnel de la région – m'a amené son PC pour une mise à jour. La machine – un modeste Lenovo ThinkCentre avec un processeur Intel Core i3 – est équipée d'un système OpenSUSE Leap, et le client souhaite migrer vers une solution LTS basée sur Rocky Linux 9.
Lors de la sauvegarde initiale des données, je me suis retrouvé confronté à
quelques dysfonctionnements bizarres. J'ai eu droit à des blocages inopinés
avec rsync et scp. J'ai démarré une session de secours pour voir, mais le
problème persistait. Un coup de smartctl me confirmait que le disque SSD
était apparemment en train de me lâcher. Le problème, c'est que le client ne
disposait que d'une sauvegarde incomplète de ses données.
-
J'ai donc extrait le disque de la machine pour le remplacer par un disque neuf.
-
J'ai installé un système Rocky Linux 9 minimal dessus.
-
J'ai branché le SSD défectueux à un adaptateur USB et je l'ai relié au PC.
J'installe ddrescue fourni par le dépôt de paquets tiers EPEL sur le système
minimal :
Le disque SSD apparaît ici comme /dev/sdb avec quatre partitions. Les données
à récupérer se trouvent sur la partition /dev/sdb4 :
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 922.5G 0 part /
└─sda3 8:3 0 8G 0 part [SWAP]
sdb 8:16 0 238.5G 0 disk
├─sdb1 8:17 0 8M 0 part
├─sdb2 8:18 0 500M 0 part
├─sdb3 8:19 0 8G 0 part
└─sdb4 8:20 0 230G 0 part
sr0 11:0 1 1024M 0 rom
Je lance la récupération de la partition avec les options qui vont bien. Je vais me préparer un café en attendant que ça mouline. Au bout d'une vingtaine de minutes environ, j'obtiens le résultat suivant :
# ddrescue -f -n /dev/sdb4 rescue.img rescue.log
GNU ddrescue 1.28
Press Ctrl-C to interrupt
ipos: 246936 MB, non-trimmed: 24576 B, current rate: 47710 kB/s
opos: 246936 MB, non-scraped: 0 B, average rate: 70105 kB/s
non-tried: 4980 kB, bad-sector: 0 B, error rate: 0 B/s
rescued: 246931 MB, bad areas: 0, run time: 58m 42s
pct rescued: 99.99%, read errors: 2, remaining time: 1s
time since last successful read: 0s
Copying non-tried blocks... Pass 1 (forwards)
ipos: 137742 MB, non-trimmed: 24576 B, current rate: 47710 kB/s
opos: 137742 MB, non-scraped: 0 B, average rate: 70105 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 246936 MB, bad areas: 0, run time: 58m 42s
pct rescued: 99.99%, read errors: 2, remaining time: 1s
time since last successful read: 0s
Copying non-tried blocks... Pass 2 (backwards)
ipos: 144858 MB, non-trimmed: 0 B, current rate: 6283 kB/s
opos: 144858 MB, non-scraped: 0 B, average rate: 70033 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 246936 MB, bad areas: 0, run time: 58m 46s
pct rescued: 100.00%, read errors: 2, remaining time: 0s
time since last successful read: 0s
Trimming failed blocks... (forwards)
Finished
-
L'option
-fforce l'ouverture des fichiers ou périphériques en écriture. -
L'option
-névite les tentatives de relecture des secteurs défectueux, ce qui permet d'accélérer le processus. -
En langage tam-tam, le résultat affiché m'indique que j'ai récupéré la quasi-totalité des données.
L'avantage ici, c'est que ddrescue ne se bloque pas contrairement à rsync
ou scp. En contrepartie, il peut arriver que la restauration s'arrête. Dans
ce cas, il suffit de relancer l'opération pour les secteurs problématiques avec
les options suivantes :
-
L'option
-dutilise l'accès direct au disque. -
L'option
-r3tente de relire les secteurs défectueux jusqu'à trois fois.
Au terme de l'opération, je me retrouve avec un fichier image qui correspond à la taille de ma partition récupérée :
Pour accéder aux données, il suffit de monter l'image sur un répertoire local, et le tour est joué :
# mkdir -v /mnt/rescue
mkdir: created directory '/mnt/rescue'
# mount -v -o loop rescue.img /mnt/rescue/
mount: /dev/loop0 mounted on /mnt/rescue.
# ls /mnt/rescue/
bin dev home lib64 mnt proc run selinux sys usr
boot etc lib lost+found opt root sbin srv tmp var
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
