Bonjour,
Ca fait un paquet d’années que je fais mes backups vers un petit serveur dédié équipé d’un disque de 2 TB (Kimsufi offre spéciale décembre 2012). (lire ce que j’avais écrit à cette époque)
Le disque a déjà crashé une fois dans le passé, et il a été remplacé, ce qui m’a valu de tout réinstaller.
Grâce à une surveillance automatique des paramètres S.M.A.R.T. les signes avant-coureurs m’avaient permis de prendre mes dispositions.
Et maintenant, voilà qu’il y a de nouveau un bad-block.
D’expérience, si un block est illisible ça vaut la peine de réécrire à cet endroit sur le disque. Soit le contrôleur arrive à écrire à cet endroit qui redevient utilisable, soit il réalloue le bloc dans une réserve. Dans les deux cas le disque est à nouveau propre pour l’operating system.
J’avais plus de 100 GB de libre sur un autre serveur. Et par chance le bad block se trouve dans la petite partition Linux et non dans la grosse partition /home.
Voici comment j’ai procédé. L’autre serveur (l’un et l’autre se trouvent de part et d’autre de l’Atlantique) a pu accueillir les sauvegardes.
root@srv4:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 20026236 12384660 6601244 66% / devtmpfs 2009980 0 2009980 0% /dev tmpfs 2010508 0 2010508 0% /dev/shm tmpfs 2010508 9760 2000748 1% /run tmpfs 5120 0 5120 0% /run/lock tmpfs 2010508 0 2010508 0% /sys/fs/cgroup /dev/sda3 1902052484 937731384 867679412 52% /home
# fdisk /dev/sda Command (m for help): p Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: A811DA9B-19C7-46A3-BA18-8770041AD73C Device Start End Sectors Size Type /dev/sda1 40 2048 2009 1004.5K BIOS boot /dev/sda2 4096 40962047 40957952 19.5G Linux filesystem /dev/sda3 40962048 3905974271 3865012224 1.8T Linux filesystem /dev/sda4 3905974272 3907020799 1046528 511M Linux swap
Le bad block se trouvant dans la partition Linux, il faut impérativement booter sur un live-CD ou via le réseau. Chez OVH un environnement “rescue” est proposé. Je n’ai utilisé que le mode “command-line”.
Sauvons tout ce qu’il y a moyen, y compris la table de partition, la partition boot gpt, puis la partition /root linux.
root@rescue:~# dd if=/dev/sda bs=512 count=40| ssh user@srv3.dmmail.eu "cat > srv4.sda.0-40.dd.raw" 40+0 records in 40+0 records out 20480 bytes (20 kB) copied, 0.000505364 s, 40.5 MB/s user@srv3.dmmail.eu's password: root@rescue:~# dd if=/dev/sda bs=512 count=4096| ssh user@srv3.dmmail.eu "cat > srv4.sda.0-2048.dd.raw" 4096+0 records in 4096+0 records out 2097152 bytes (2.1 MB) copied, 5.57779 s, 376 kB/s root@rescue:~# dd if=/dev/sda1 bs=512 | ssh user@srv3.dmmail.eu "cat > srv4.sda1.dd.raw" 2009+0 records in 2009+0 records out 1028608 bytes (1.0 MB) copied, 5.66955 s, 181 kB/s root@rescue:~# dd if=/dev/sda2 bs=512 | ssh user@srv3.dmmail.eu "cat > srv4.sda2.dd.raw" i/o error
Arrêt prématuré: ce fichier dump est incomplet. Il faut recommencer, en passant outre les bad blocks. (option conv=noerror,sync de la commande dd)
root@rescue:~# dd if=/dev/sda2 bs=512 conv=noerror,sync| ssh user@srv3.dmmail.eu "cat > srv4.sda2.dd.raw"
Une copie supplémentaire qui permettra de retrouver quel est le fichier manquant (celui affecté par le bad block)
# find . -print |cpio -ocBv | ssh user@srv3.dmmail.eu "cat > srv4.sda2.cpio.raw"
Etonamment pas de message d’erreur. Il n’y a probablement aucun fichier impacté. Le file system ext4 a dû marquer ce bloc, mais je n’ai pas cherché.
Réécriture complète de tous les blocks de la partition en question, au moyen de l’utilitaire approprié
# badblocks -w /dev/sda2
A nouveau pas de message d’erreur
Récupération
# ssh user@srv3.dmmail.eu cat srv4.sda2.dd.raw| dd of=/dev/sda2
Test:
# mount /dev/sda2 /mnt
cd /mnt ; ls ; du -sh * ; cd / ; umount /mnt
tout est là
# fsck -pvcf /dev/sda2 fsck from util-linux 2.25.2 /dev/sda2: Updating bad block inode. 46964 inodes used (3.67%, out of 1281120) 86 non-contiguous files (0.2%) 63 non-contiguous directories (0.1%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 41031/81/1 3209273 blocks used (62.68%, out of 5119744) 0 bad blocks ^^^^^^^^^^^^^^^^^^ yeah ! 1 large file 37606 regular files 3338 directories 15 character device files 102 block device files 2 fifos 20 links 5864 symbolic links (5696 fast symbolic links) 28 sockets ------------ 46975 files
Le paramètre 197 Current_Pending_Sector est revenu à zéro.
# smartctl -a /dev/sda ... Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 136 136 054 Pre-fail Offline - 80 3 Spin_Up_Time 0x0007 100 100 024 Pre-fail Always - 486 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 7 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 145 145 020 Pre-fail Offline - 24 9 Power_On_Hours 0x0012 098 098 000 Old_age Always - 14717 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 7 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 604 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 604 194 Temperature_Celsius 0x0002 166 166 000 Old_age Always - 36 (Min/Max 16/47) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 ATA Error Count: 47 (device log contains only the most recent five errors) Error 47 occurred at disk power-on lifetime: 14714 hours (613 days + 2 hours) When the command that caused the error occurred, the device was active or idle.
…
J’espère juste qu’on est reparti pour un bail, et que le problème ne va pas ressurgir trop vite.
J’avais entretemps envisagé d’utiliser Amazon Cloud Drive pour m’affranchir des problèmes mécaniques, mais je me suis trouvé confronté à d’autres problèmes (manque d’accessibilité depuis un environnement Linux). Peut-être écrirai-je un article là-dessus mais rien n’est sûr.
J’ai donc renoncé à l’abonnement de test gratuit de 3 mois, après une demi-semaine.
Sur l’autre serveur j’ai ceci en réserve:
-rw-r--r-- 1 user user 2097152 Sep 10 17:00 srv4.sda.0-2048.dd.raw -rw-r--r-- 1 user user 20480 Sep 10 16:59 srv4.sda.0-40.dd.raw -rw-r--r-- 1 user user 1028608 Sep 10 17:01 srv4.sda1.dd.raw -rw-r--r-- 1 user user 1456424960 Sep 10 19:57 srv4.sda2.cpio.raw -rw-r--r-- 1 user user 20970471424 Sep 10 18:17 srv4.sda2.dd.raw