[Shr] Crash Volume Et R

[cayou2000]

Bonjour,

Je poste mon "aventure" qui pourrait servir à d'autre si jamais pareille chose leur arrive:

Petit état des lieux du matos:

DS2411+ en DSM4.2 sur onduleur

un volume SHR (raid ) avec 5 Seagate green ST2000DL003 2to

un volume Basic avec 1 Seagate desktop ST4000DM000 4to (backup des données importantes: tout sauf le dossier video en fait)

Voilà un mois, j'ai le disque 3 qui s'est déconnecté (il disparait mais les données sont toujours dessus).

Du coup volume dégradé. Ca m'est déjà arrivé et j'ai donc entamé une reconstruction du volume, ce qui dure dans les 24h de souvenir.

18h plus tard, le disque 2 lâche à son tour. Du coup volume crashé et il est passé en lecture seule avec impossibilité de voir certaines données (dossiers disparus) et certains fichiers font soit 0 octets soit ne sont plus lisibles.

je maille synology qui me poste ce qui suit:

Hi We found there are many file system errors in volume1, the file system was too bad.

file system in volume1 :

Jan 14 00:40:00 kernel: [68281.470739] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550705

Jan 14 00:40:01 kernel: [68281.927567] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550707

Jan 14 00:40:01 kernel: [68282.453404] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550709

Jan 14 00:40:02 kernel: [68283.157373] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550711

Jan 14 00:40:03 kernel: [68283.847340] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550715

Jan 14 00:40:03 kernel: [68284.354395] EXT4-fs error (device dm-0): ext4_lookup:1196: inode #16418052: comm synolocalbkp: deleted inode referenced: 68550717

So volume 1 was mounted as read only.

rootfs / rootfs rw 0 0

/dev/root / ext4 rw,relatime,user_xattr,barrier=1,journal_checksum,data=ordered 0 0

/proc /proc proc rw,relatime 0 0

/tmp /tmp tmpfs rw,relatime 0 0

none /dev/pts devpts rw,relatime,gid=4,mode=620 0 0

/sys /sys sysfs rw,relatime 0 0

/proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0

/dev/vg1/lv /volume1 ext4 ro,

relatime,user_xattr,synoacl,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0

/dev/md5 /volume3 ext4 rw,relatime,user_xattr,barrier=0,journal_checksum,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group 0 0

none /proc/fs/nfsd nfsd rw,relatime 0 0

Please backup important data at first priority then use health disk to create a new volume and restore data. Do NOT reboot or schedule power off (in Control Panel > Hardware) system until backup finished. You may face to some data can't backup, in our suggestion, please backup as possible as you can.
You can refer this pdf to do backup and recovery plan or use other protocol like FTP, Samba protocol to copy files.
http://download.synology.com/download/marketing/tutorials/Synology_Disaster_Recovery_Deployment_Guide.pdf
For file system error, it is different to RAID protection and is necessary to recreate the volume to obtain new file system to ensure data integrity, else it may likely to cause more data lost if continue using. As a concern to your data, we suggest that you could make important backup to data asap.
There are some possible reasons to cause file system error :
(1) bad disk or bad disk before. Although it was replaced, it did cause file system error.
(2) improper shutdown
(3) non-Synology third party software.
(4) the volume was created in previous DSM and degraded before. (fixed in DSM 4.1-2647)
To sum up above description, your step is:
(1) Backup data and delete volume 1.
(2) check disk health to create volume 1
(3) use health disks to create new volumes in latest DSM version
(4) restore data.
If you would like to try a command repair, please enable the telnet function in DS, then telnet to your DS with the user root and the admin's password, then run the following commands to repair the file system, you may take your own risk to process this. Before you do this, we still recommend you make backup for your important data first:
syno_poweroff_task
vgchange -ay
fsck.ext4 -pvf -C 0 /dev/vg1/lv
(when you perform syno_poweroff_task, it only allows to access through Telnet/SSH)
If -pvf can't work, please use -yvf instead. After the command fsck.ext4 is completed, please reboot your DS and check the result. If the result is still not good, we will suggest this:
1. Backup the important data as soon as possible
2. Delete the volume 1 and recreate the volume, then restore data backed up
Sincerely,
Cynthia Chang.

Technical Support

2014/1/14 >

Hi,Both files are attached,

Regarding the hard drive as far as I Remenber it is always the second or the third HDD that disappeared.

I'm currently making a backup of the nas to see what I can save.

I you have any information about how to solve this.

regards,

2014/1/14 Synology Technical Support <support@synology.com>

Hi
Thank you for the inquiry.

Does it happen in the same disk slot or randomly?

Can you access data at this moment?

If you can access data, we suggest backup important data. Please send us a copy of your (1) kernel log and (2) system log, the instructions have been mentioned in below. The Kernel log is a technical log file which can give us more technical information about your system[Kernel log]

1. Log into the DiskStation Manager as admin.
2. The URL will look similar to http://192.168.xx.xx:5000/webman/index.cgi
3. Add ?diagnose=debug to the URL so that- http://192.168.xx.xx:5000/webman/index.cgi?diagnose=debug
4. Press Enter to save the debug.dat file
5. If there is no pop up window to save debug file, please check the browser plugin or antivirus software that may block.
[system log] after DSM 4.1
Please go Main Menu > System logs > General, click save > HTML, it will save a html file.

Sincerely,
Cynthia Chang.

Technical Support

En gros, elle me demande de leur envoyer des fichiers log puis me conseille de sauvegarder les données et de surtout pas redemarrer en essayant des instructions en telnet.

Bon, je suis jamais allé jusqu'au bout des instructions et j'ai du redémarrer après avoir sauvé ce qui pouvait l’être car le syno a planté sur une des taches de sauvegarde (premier plantage depuis que j'ai des syno avec redémarrage à la barbare).

Au redémarrage, le syno me propose une réorganisation de raid au prochain redémarrage puisque mes disques "en panne" sont réapparu bien sur.

Redémarrage et quelques heures plus tard (1h par To annoncés), je peux de nouveau accéder à tout mes dossiers mais le volume et toujours craché en lecture seule avec les deux disques marqués "en panne". Par contre tout mes fichiers sont sauvegardables et ont l'air intacts.

Du coup, j'ai commandé deux disques 4to supplémentairement pour tout sauvegarder et j'ai pris un DS214se pour me faire un backup externe en local (et tester la beta DSM5.0 au passage).

J'ai sorti les deux disques incriminés pour les tester sous roadkill et 0 erreurs.

Par contre impossible de supprimer le volume car les services des packages sont dessus et il tournait en boucle (arrêt des package, suppression volume, retour à volume dégradé)

J'ai donc mélangé les disques pour le forcer à casser le raid et j'ai pu le supprimer puis le recréer.

Là je suis en cours de restauration.

Donc tout est bien qui fini bien, mais je m'explique difficilement comment j'ai pu avoir accès à toutes mes données avec deux disques "en panne".

La seule explication que je vois c'est que comme j'avais encore plus de 25% d'espace libre en fait un des disque était "vide" et donc même avec seulement trois disques ça marchait quand même.

Bref, tout ça pour dire comme ça été dit plein de fois, le raid c'est pas une sauvegarde et maintenant je vais quand même tout sauvegarder (le SHR de 5 disques 2t) en local (2 disque de 4to en basic) + sur un syno chez moi (1 disque de 4to en basic ) et les dossier important en plus sur un syno chez Maman (un SHR de 3 disques 500go).

Pour ce qui est du DS214se je lui ai mis directement un des disques de 4to qui me servait de sauvegarde (volume basic avec un répertoire de backup) et après installation du DSM le volume s'est monté (avec le même nom de volume: volume 2) et fonctionne très bien (pas de formatage)

Voilà toujours très content de synology pour leur réactivité et leur matos (je pense que mon problème de déconnexion vient des disques car ça m'est aussi arrivé sur le ds411+II que j'avais avant (problème de temps de réponse trop long?)

A plus

[spaceman]

Bonjour,

Merci pour ce retour. Celà m'a permis de connaître la fonction "magique" pour arreter tous les services d'un coup .

J'ai aussi eu des déboires avec un WD green. Ils ont des problèmes sur le parkage des têtes, ce qui vieilli prématurément le disque .

J'ai donc remplacé le disque défectueux et un autre, par 2 disques plus gros. En faisant 1 par 1 bien sûr

Une fois le volume reconstruit ça m'a proposé d'étendre le volume.

Mais à chaque fois ça s'arrêtait. j'ai trouvé ça comme messages dans /var/log/messages :

Feb 15 14:50:44 volumehandler.cgi: space_expand_unallocated.c:82 [info] Success Dump map file

Feb 15 14:50:52 kernel: [ 445.993912] EXT4-fs warning (device dm-0): ext4_resize_begin:32: There are errors in the filesystem, so online resizing is not allowed

Feb 15 14:50:52 kernel: [ 445.993917]

Feb 15 14:50:52 volumehandler.cgi: (fs_vol_expand.c)SYNOFSExpand(103):Failed to '/sbin/resize2fs -fpF /dev/vg1/lv > /dev/null 2>&1', WEXITSTATUS® = 1

Feb 15 14:50:52 volumehandler.cgi: volume_manage_with_temp_dev.c:105 Failed to expand file system on /dev/vg1/lv

Feb 15 14:50:52 volumehandler.cgi: volume_lib.cpp:957 Failed to expand file system on /dev/vg1/lv

Feb 15 14:50:52 volumehandler.cgi: volumehandler.cpp:1453 failed to expand unallocated file system: /volume1

J'ai demandé un "Nettoyage des données", mais ça n'a rien fait j'ai toujours le même message "There are errors in the filesystem"

Du coup je me suis lancé dans une tentative de réparation du "file system" en utilisant le wiki suivant :

http://forum.synology.com/wiki/index.php/How_to_give_your_disks_and_files_a_health_check_and_repair_basic_faults

le check m'a repéré des erreurs mais le dernier point de la procédure (point 11), ne marche pas. car ça me répond toujours "/dev/vg1/lv is in used".

Donc je viens de lancer les commandes du support que tu nous a fais suivre .

syno_poweroff_task
vgchange -ay
fsck.ext4 -pvf -C 0 /dev/vg1/lv

C'est en cours (20%). J'espère que ça va marcher

Merci en tout cas, de tes informations.

Si ça a marché "je vous dis quoi" .

@+

DS1513+

DSM 4.3-3827

WD40EFRX+WD30EFRX+HD204UI+WD4EFRX

[spaceman]

AAARRRGGGGGG,

ça s'est arrêté . voici ce que ça m'a écrit :

syno>fsck.ext4 -pvf -C 0 /dev/vg1/lv

Deleted inode 207093775 has zero dtime. FIXED.

1.41.12-1337: Inodes that were part of a corrupted orphan linked list found.

1.41.12-1337: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

(i.e., without -a or -p options)

Bon ben je continue sur mes déboires. Ca va finir en formatage je sens.

Mais du coup le NAS sera indisponible pendant plusieurs jours, le temps de la restauration des données.

@+

[spaceman]

Suite :

J'ai relancer le check sans le p (j'aurai du ajouter le y pour m'éviter de taper les Y à chaques fois). Voici ce que ça a donné :

> fsck.ext4 -vf -C 0 /dev/vg1/lv

e2fsck 1.42.6 (21-Sep-2012)

Pass 1: Checking inodes, blocks, and sizes

Inodes that were part of a corrupted orphan linked list found. Fix<y>? yes

Inode 207093796 was part of the orphaned inode list. FIXED.

Inode 207093818 was part of the orphaned inode list. FIXED.

Inode 207093823 was part of the orphaned inode list. FIXED.

Inode 207093830 was part of the orphaned inode list. FIXED.

Inode 207093857 was part of the orphaned inode list. FIXED.

Inode 207093864 was part of the orphaned inode list. FIXED.

Inode 207093891 was part of the orphaned inode list. FIXED.

Inode 207093918 was part of the orphaned inode list. FIXED.

Inode 207093920 was part of the orphaned inode list. FIXED.

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

/lost+found not found. Create<y>? yes

Pass 4: Checking reference counts

Pass 5: Checking group summary information

Block bitmap differences: -828376981 -828376988 -828391433 -(828391436--828391437) -828391447 -828391449 -(828391453--828391455)

Fix<y>? yes

Free blocks count wrong for group #25280 (30798, counted=30808).

Fix<y>? yes

Free blocks count wrong (265841176, counted=265841186).

Fix<y>? yes

Inode bitmap differences: -207093775 -207093796 -207093818 -207093823 -207093830 -207093857 -207093864 -207093891 -207093918 -207093920

Fix<y>? yes

Free inodes count wrong for group #25280 (7859, counted=7869).

Fix<y>? yes

Directories count wrong for group #25280 (29, counted=19).

Fix<y>? yes

Free inodes count wrong (425310842, counted=425310852).

Fix<y>? yes

1.41.12-1337: ***** FILE SYSTEM WAS MODIFIED *****

1131900 inodes used (0.27%, out of 426442752)

20597 non-contiguous files (1.8%)

250 non-contiguous directories (0.0%)

# of inodes with ind/dind/tind blocks: 0/0/0

Extent depth histogram: 1126197/4328/21

1439922654 blocks used (84.42%, out of 1705763840)

0 bad blocks

447 large files

986501 regular files

144044 directories

0 character device files

0 block device files

2 fifos

192 links

1322 symbolic links (1321 fast symbolic links)

21 sockets

------------

1132082 files

je reboote le syno.

Une fois redémarré, je vérifie que tous les services sont arrêtés.

Et je retente une extension du volume via le menu Gérer => ....... Suspens ........ CA A MARCHE

Bon ben maintenant, il n'y a plus qu'a vérifier les données :-)

En tout cas c'est bien pratique ce fsck.ext4