Synology volume crashed

synology volume crashed

En janvier il m’est arrivé un truc pas drôle du tout !

Un des HDD du nas faisait de temps en temps des siennes, mais rien de bien alarmant jusque là, quelques erreurs « reallocate sector count ».

Et pis un jour … CRACK !! Le disque complètement HS. Ca se met à sonner dans tous les sens, je me connecte, je me dis que ce n’est qu’un petit soucis passager (je venais de passer des semaines à me battre avec le volume raid du fixe qui a définitivement mourru), je clique donc sur réparer.

Ni une ni deux il m’envoie chier et le volume passe de « volume degraded » à « volume crashed ». Tiens j’avais pas eu encore ça, crashed. Un peu inquiet, mais je me dis c’est du solide, ca fait 4 ou 5 ans que je l’ai, et à part remplacer les disques qui meurent je n’ai pas eu beaucoup d’embrouilles avec le nas.

Pour pas tenter le diable et une faiblesse potentielle d’un autre disque, j’éteints tout. Une fois le nous 6To reçu, je charge le bidule, appuie sur power et attends. Longtemps.

Mais je sais qu’en mode degraded ça peut prendre vraiment beaucoup de temps à démarrer. Le lendemain toujours rien, de plus en plus inquiet je regarde ce qu’il se passe. Pas d’accès à l’interface web. Castagnette, j’irais en SSH. Ouf ça passe. Je branche un écran sur le port VGA et redémarre. Rien à l’écran à part le BIOS, et mon accès SSH qui me dit que j’ai pu rien de monté et/ou accessible.

A force d’acharnement, un 2ème disque se met à clignoter en jaune … ouuuuh pas bon ! Parce que un raid 5 avec un disque de moins ça va. Avec 2 disques de moins, ya pu rien !! Et impossible d’initialiser le vieux ou le neuf.

Bref, le deuxième disque semblait fonctionner encore, et après avoir attendu une réponse du servicedesk synology je me lance dans les commandes bizarres, dont la dernière qui a permis de tout réparer (mais elle fait flipper quand même) :

De mémoire avant il faut forcer le montage du volume en RW (c’est à dire faire un arrêt des services en mode debug pour pouvoir garder la main en SSH)

_NAS> fsck.ext4 -yvf -C0 /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
1.41.10-1922: recovering journal
Journal transaction 32135694 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? yes

Inode 54 was part of the orphaned inode list. FIXED.
Deleted inode 55 has zero dtime. Fix? yes

Inode 58 was part of the orphaned inode list. FIXED.
Inode 513294383 was part of the orphaned inode list. FIXED.
Inode 513294384 was part of the orphaned inode list. FIXED.
Inode 513294388 was part of the orphaned inode list. FIXED.
Inode 513294397 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -9249 -479135389 -(479150196–479150197) -(479150707–479150772) -479150774 -(479150788–479150852) -(479150854–479150922) -(479150924–479150987) -(479150989–479151052) -(479151054–479151117) -(479151119–479151264) -(479151739–479151775) -(479152273–479152350) -479152352 -(479152862–479152863) -(479153369–479153374) -(479153880–479153885) -(479154391–479154396) -(479154902–479154971) -(479154973–479155036) -(479155038–479155041) -(479155043–479155114) -(479155624–479155690) -(479155692–479155767) -(479155769–479155834) -(479155836–479155953) -(479155955–479155969) -(479155971–479155976) -(479155978–479156051) -(479156053–479156116) -(479156118–479156181) -(479156183–479156247) -(479156249–479156263) -479156265 -(479156330–479156343) -(479156345–479156347) -(479156349–479156350) -(479156353–479156357) -(479156359–479156362) -(479156365–479156406) -(479160320–479160613) -(479160615–479161151) -479161153 -(479161155–479161330) -(479161332–479161348) -(479161399–479161462) -(479161970–479161974) -(2084249418–2084249422) -2084249427 -(3143946240–3143948287) -(3144208384–3144210431) -(3144214528–3144216575) -(3144221696–3144222552) -(3144222720–3144224767) -(3144255488–3144286207) -(3144288256–3144297606)
Fix? yes

Free blocks count wrong for group #0 (125, counted=126).
Fix? yes

Free blocks count wrong for group #14622 (207, counted=2890).
Fix? yes

Free blocks count wrong for group #63606 (2730, counted=2736).
Fix? yes

Free blocks count wrong for group #95945 (1140, counted=3188).
Fix? yes

Free blocks count wrong for group #95953 (1435, counted=5531).
Fix? yes

Free blocks count wrong for group #95954 (653, counted=3558).
Fix? yes

Free blocks count wrong for group #95955 (1523, counted=32243).
Fix? yes

Free blocks count wrong for group #95956 (10130, counted=19481).
Fix? yes

Free blocks count wrong (603623449, counted=568996513).
Fix? yes

Inode bitmap differences: -55 -58 -(513294383–513294384) -513294388 -513294397
Fix? yes

Free inodes count wrong for group #0 (8134, counted=8137).
Fix? yes

Free inodes count wrong for group #62658 (7949, counted=7953).
Fix? yes

Free inodes count wrong (910910945, counted=910899492).
Fix? yes
1.41.10-1922: ***** FILE SYSTEM WAS MODIFIED *****

3622620 inodes used (0.40%, out of 914522112)
53612 non-contiguous files (1.5%)
763 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 3605955/16142/55
3089090911 blocks used (84.45%, out of 3658087424)
0 bad blocks
633 large files

2543334 regular files
1063661 directories
4 character device files
0 block device files
2 fifos
5076 links
15588 symbolic links (431 fast symbolic links)
21 sockets
————
3627686 files
_NAS>

Une fois ceci fait, toujours rien d’accessible. Je me résous à redémarrer à nouveau, et partir pour aller ailleurs. 1h ou 1h30 plus tard je reçois la notification pour me dire qu’il est repassé en mode dégradé. Je me connecte, il detecte des modifications faites hors interface et propose de les réparer, je dis oui. Attends, attends, attends, puis finalement quelques jours plus tard toute cette histoire était dernière nous.

Pour le moment je ne crois pas avoir détecté une perte de fichiers quelconque 🙂