RAID SHR - VOLUME PLANTE !

[Aerrow]

 Bonjour à tous !

Je poste ma contribution pour ceux qui auraient eu les mêmes problèmes que moi :

Situation : Suite à une coupure de courant, le volume de mon NAS était planté. Le RAID --> OK, Les Disques Durs --> OK
Je me retrouve donc avec un NAS fonctionnel, mais avec un volume planté sans d'autre symptômes.... 😪 

Je décide donc de chercher une solution car je suis sûr que mon volume doit toujours exister qqpart et mes données aussi ! (un peu plus de 3To ... une grande partie de ma vie numérique !)

La solution qui a fonctionné pour moi ne nécessite pas d'enlever les disques du NAS, tout se fait via la console SSH du NAS SYNOLOGY.
Et les commandes sont relativement simples. J'espère que que ça marchera pour ceux qui sont dans le même cas que moi c'est à dire "Volume Planté" sans d'autres soucis de RAID ou de Disque Durs

1 - Accès au NAS en SSH via Putty

On met l'@Ip du NAS, on clique sur open et une fenêtre s'ouvre.
Si vous ne l'avez jamais fait auparavant il faut accepter le certificat.

Si ça ne fonctionne pas ,vérifiez d'avoir activer le SSH dans Synology :

login : admin et password = "celui que vous avez mis dans votre installation"
Vous vous retrouvez avec ce prompt :
admin@NAS:/$

2 - Passer en root :

admin@NAS:/$ sudo -i
Password : "le même que admin"
root@NAS:/#
 

3 - Check des  "Physical Volume", "Virtual Volume" et "Logical Volume" :

Ci-dessous les différents PV de mon NAS en RAID SHR. 
(partitions en /dev/mdx correspond à un raid) 

 

Et ci-dessous LE VOLUME_1 celui qui est l'objet de toutes mes attentions !

=> mon volume existe bien... 😲 

Ci-dessous les différents LV de mon Volume1 (vg1) en RAID SHR
Celui qui m'intéresse plus particulièrement est /dev/vg1/volume_1 qui contient mes données !

 

4 - Check des partitions montées:

ici la partition de mon volume1 qui s'appelle /dev/vg1/volume_1 n'est pas montée, et lorsque j'essaie de la monter j'obtiens une erreur :

root@NAS:/#  mount /dev/vg1/volume_1 volume1/
mount: wrong fs type, bad option, bad superblock on /dev/vg1/volume_1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
 

root@NAS:/# dmesg  #lecture des logs voir ce que ça raconte un peu...
[...]
[10326.262985] EXT4-fs (dm-1): barriers disabled
[10326.692626] JBD2: journal transaction 8136159 on dm-1-8 is corrupt.
[10326.699377] EXT4-fs (dm-1): error loading journal

Après avoir fait quelques recherches, des erreurs existent sur le système de fichier de mon volume,
il convient d'essayer de le réparer...

 

5 - J'ai trouver cette commande qui a sauvée mon volume : 
root@NAS:/# fsck.ext4 -f /dev/vg1/volume_1
e2fsck 1.42.6 (21-Sep-2012)
1.42.6-5644: recovering journal
Journal transaction 8136159 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (583993748, counted=583994298). #erreurs trouvées sur le système de fichier, propose de réparer...#
Fix<y>? yes #je dis ''yes '' bien évidemment !#
Free inodes count wrong (303818467, counted=303818628).
Fix<y>? yes #je dis ''yes '' bien évidemment !#
1.42.6-5644: ***** FILE SYSTEM WAS MODIFIED *****
1.42.6-5644: 202876/304021504 files (1.1% non-contiguous), 632091718/1216086016 blocks
 

6 - Vérification finie, j'essaie de monter mon volume...
root@NAS:/# mount /dev/vg1/volume_1 volume1/
 => et là magie !! mon volume se monte et je peux accéder à ce dernier via les lecteurs réseaux que j'avais sous windows 😁 

=> pour le moment les partages sont invisibles sous le FileStation depuis l'interface Web de Synology, je décide donc de tout sauvegarder avant de redémarrer le NAS pour voir s'il reboot avec toutes les applications et partages correctement actif...)

 

Ci-dessus mon volume apparaît bien dans la table de montage... 
/dev/mapper/vg1-volume_1 est une redirection de /dev/vg1/volume_1 (en gros c'est la même chose, mais nous utilisons la deuxième écriture pour nos commandes...)

Maintenant j'attends deux heures le temps de copier toutes les données de mon NAS que je souhaite ABSOLUMENT conserver avant de tenter un reboot !

 

  edit : ... deux heures plus tard ...

je lance le redémarrage de mon NAS ....

...

...

Tout fonctionne de façon nominal !

(OpenVPN, PLEX, PARTAGE SMB, DOWNLOAD MANAGER, ANTIVIRUS...)

/!\ Ne pas réinstaller d'application avant le reboot (genre plex) sinon la conf des bibliothèque sera vierge et il faudra bidouiller pour la retrouver !

 

 

 

Voilà j'espère ne pas vous avoir perdu dans mes explications et que ça vous aidera à résoudre vos soucis !

#--|Aerrow|--#
 

 

[maxou56]

Bonjour, @Aerrow

Un onduleur t'aurais permis d'évité d'avoir des sueurs froides 😅. Ainsi qu'une sauvegarde.

Tous ce termine bien 😀.

[Aerrow]

il y a 1 minute, maxou56 a dit :

Bonjour, @Aerrow

Un onduleur t'aurais permis d'évité d'avoir des sueurs froides 😅. Ainsi qu'une sauvegarde.

Tous ce termine bien 😀.

Merci pour ce conseil ! en fait c'était plus pour partager mon retour ! 🤪

[Mic13710]

Merci pour le retour, mais inutile de le répéter sur tous les sujets de volume planté du forum. Je déplace dans la section tutoriels et je supprime dans les sujets concernés.

[PC-Services]

voici une autre procédure dans le cas ou votre volume n'est pas de en EXT4 mais BTFRS

dans le cas EXT4  nous avions l’outil:  e2fsck

Pour le BTRFS c'est simple c'est : btrfs check

Le SHR de Synology correspond à une couche raid (mdadm avec  # cat /proc/mdstat) et une couche de LVM2. (vous trouverez sur le web plus d'infos à leurs sujet et ce n'est pas le sujet du post ici)

Voici déjà quelques commandes pour afficher les status du système

Pour voir l'état de ses volumes nous avons:

#lvdisplay -v

#pvdisplay

# vgdisplay -v

# lvs

# lvm vgscan

# lvm pvscan

# lvm lvmdiskscan

Pour connaitre le status de ses raid:

# cat /proc/mdstat

pour voire le type de ses disques physiques ou virtuels (raid) :

# cat /etc/fstab

pour voire ses points de montages de fichiers systèmes:

# df

après toutes ces commandes, vous devriez avoir une vue d'ensemble de votre problème.

 

vient ensuite la tentative de réparation et  remontage dans DSM de mon volume qui n'a pas aboutie car apparemment DSM utilise un kernel avec sa propre version de btrfs et donc certain outils ne fonctionnent pas de manière attendue.

# btrfs check --init-extent-tree /dev/vg1000/lv

pour un volume en EXT4 ce sera: # e2fsck -pvf -C 0 /dev/vg1000/lv

# btrfs rescue super-recover /dev/vg1000/lv

et il y en a plein d'autres dépendant du cas de rupture voire https://www.suse.com/support/kb/doc/?id=000018769: ou le WIKI sur le BTRFS.

je ne m'attarderai donc pas à ces dernières qui n'ont pu résoudre mon cas.

Il semblerait (pas testé ici) que j’aurai pu aussi, si j'avais un autre Synology, démarrer ce second Syno., installer DSM, ne pas créer de volume, éteindre, brancher mes 4 disques du syno1 en problème

et normalement ces derniers devraient êtres remontés correctement.

Mais vu que je n'ai pas de second syno libre pour cette manip, voici

ce qui a marché pour moi :

# vgchange -ay        il permet de réactiver le groupe de volume

puis j'ai pu remonter mon volume planté en lecture seule et sans son fichier cache système, donc juste pour pouvoir rattraper mes données :

# mount -o recovery,ro /dev/vg1000/lv /volume2      ou ici vg1000 est le device mappé pour mon volume lv que je monte dans un dossier volume2

ensuite il ne reste plus qu'à (c'est un euphémisme ici avec 6To) copier mes données sur un autre volume du nas.

dans mon cas mon volume 1 n'étant pas suffisant j'ai créé un dossier \volume1\MOUNTNFS\volume2 que j'ai monté en NFS sur un dossier d'un autre NAS ici   <<ip du nas 2>>/shareFolders/volume2.

Pour pouvoir suivre et éviter un problème d'interruption de copie entre les deux (je sais que certain vont me dire qu'il n'était pas nécéssaire de faire un montage nfs du coup)

au lieux d'utiliser la commande CP j'ai utiliser rsync en mode de suivi  (-v) et progression (--progress) en gardant les paramètres de permission et une copie recursive (-a) et compression de transfert de données (-z)

ce qui donne pour moi

# rsync -avz --progress  --exclude='/@*/' /volume2/ /volume1/NOUNTNFS/volume2/    ou ici    --exclude='/@*/'  permet d'éviter un copie des snapshots de réplications qui grossieraient inutilement la quantitées de données copiées.

 

Toutes ces commandes doivent être faites en privilège root et donc soit vous rajouter sudo devant chacune ce qui vous demanderas à chaque fois votre mot de passe administrateur du nas

ou alors dès votre entrée en ssh tapez la commande sudo -i pour rester en root durant toute la cession.

J'ai choisi RSYNC au lieu de CP ou BTFRS RECOVER pour faciliter le transfer (compression, copie incrémentale au cas ou la connection serait perdue, et BTRFS RECOVER ne fonctionnait pas pour je ne sais quelle raison voire a cause du kernel synology)

Voilà, mes données sont en train d'être copiées et il va faloir plusieurs jours pour qu'il termine le job.

Restera ensuite à supprimer le volume en panne depuis DSM et de le refaire pour rebasculer tout mes dossiers à nouveau avec rsync depuis le NAS de secours ver mon syno.

Malheureusement cette procédure ne permet pas de retrouver son volume initiale en état ainsi que tout ses dossiers partagés dans DSM et elle demande beaucoup plus de temps et du matériel supplémentaire par rapport à la procédure du post initial pour un Raid en EXT4.

Apparemment il n'y en aurait pas du moins avec les outils et version du btrfs installé par Synology de possibilité de restaurer complètement un volume btrfs planté.