[HELP] Le déménagement de la mort pour mon DS1515+

[ambrius]

Bonjour à tous,

Je découvre la communauté à l'occasion d'une problématique que j'ai, classique... Cela dit j'espère que vous pourrez m'aider. J'ai toute ma vie numérique qui clignote en orange en ce moment...

Je viens de déménager. Heureux possesseur d'un DS1515+ avec une extension DX513, le redémarrage ne s'est pas passé comme prévu...
Ma configuration :

DSM 6.0.2 update 9

DS1515+ : HDD \ SSD \ SSD \ HDD \ HDD

DX513 : HDD \ HDD \ vide \ vide \ vide

tous les HDD sont des WDC 6To RED et les deux SSD des 850 EVO 1To le tout est formaté en BTRFS, avec un système SHR-1 (un RAID5 pour les HDD et un RAID1 pour le cache SSD RW)

Au premier redémarrage le cable SATA semblait mal connecté.

Puis c'est reparti mais avec une demande de migration, déjà étrange.

Après plusieurs essais et en désespoir de cause j'ai fait une migration du DSM en clean install de la partition système au lieu de migration, j'ai perdu ma configuration, mes applis et tous mes paramétrages (bon j'aimerais bien les récupérer, mais au pire ca c'est quelques heures de travail, si vus savez comment faire je suis preneur)

surtout j'ai mon RAID qui est en statut en panne j'ai essayé de supprimer mon cache SSD (j'ai alors brièvement la lumière STATUS qui revient au vert) puis refus de démontage du cache SSD et retour du jaune clignotant...
Aucun de mes disques ne sont en panne, aucune interversion de l'ordre des disques. Pour être un peu tech quand même je sans que le cache ssd vide pose problème.

J'ai deux LUN fichier avec toutes mes photos de famille depuis toujours et ma vie numérique sur le volume1 (que je n'ai jamais supprimé dans DSM, je précise après vous avoir relaté la connerie de "migration" en clean install).
Je suis clairement en panique, j'ai perdu toute ma vie numérique et tous mes souvenirs !!

Je ne connais pas l'univers RAID, ni les commandes, j'ai besoin d'aide.

Merci à la communauté si vous pouvez m'aider.

David

Je vous mets le résultat de cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 

md2 : active raid1 sdb1[0] sdc1[1]

      976757952 blocks super 1.2 [2/2] [UU]

      

md4 : active raid5 sdd5[0] sdgb5[4] sda5[3] sdga5[2] sde5[1]

      23422765824 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]

      

md1 : active raid1 sda2[0] sdd2[1] sde2[2]

      2097088 blocks [5/3] [UUU__]

      

md0 : active raid1 sda1[0] sdd1[1] sde1[2]

      2490176 blocks [5/3] [UUU__]

      

unused devices: <none>

 

[gaetan.cambier]

md2 est clean et contient normalement ton volume 1

md4 est clean aussi et contient ton volume 2

c'est déjà bien partit ...

il y a 32 minutes, ambrius a dit :

surtout j'ai mon RAID qui est en statut en panne

çà c'est pas cohérent avec ce que je vois, tu peux nous mettre la capture d'écran

Bon, lance les commandes suivantes et revoit nous le résultat (çà ne modifie rien sur le nas --> aucun risque) :

pvs
vgs
lvs
mount

 

Modifié le 11 février 2017 par gaetan.cambier

[ambrius]

Merci Gaetan, tu me redonnes un peu de baume au coeur !
Alors tout d'abord la capture, jointe et voici les résultats des commandes

pvs (j’ai dû la lancer en root)

  PV         VG     Fmt  Attr PSize  PFree

  /dev/md4   vg1000 lvm2 a--  21.81t    0 

 

vgs (idem)

  VG     #PV #LV #SN Attr   VSize  VFree

 

  vg1000   1   1   0 wz--n- 21.81t    0

 

lvs (idem)

  LV   VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

 

  lv   vg1000 -wi-ao---- 21.81t    

 

mount

/dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered)

none on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=8208964k,nr_inodes=2052241,mode=755)

none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

none on /proc type proc (rw,nosuid,nodev,noexec,relatime)

none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

/tmp on /tmp type tmpfs (rw,relatime)

/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)

/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)

none on /sys/fs/cgroup type tmpfs (rw,relatime,size=4k,mode=755)

cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)

cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)

cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct)

cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory)

cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices)

cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer)

cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio)

none on /proc/bus/usb type devtmpfs (rw,nosuid,noexec,relatime,size=8208964k,nr_inodes=2052241,mode=755)

none on /sys/kernel/debug type debugfs (rw,relatime)

securityfs on /sys/kernel/security type securityfs (rw,relatime)

 

none on /config type configfs (rw,relatime)

 

Un grand grand merci à vous  !!!

J'ajoute un élement qui me semblerait important, sachant quye je n'ai jamais eu de problème auparavant pour le faire, lorsque je veux démonter le cache, j'obtiens ceci.

[Einsteinium]

Hummmm

"Au premier redémarrage le cable SATA semblait mal connecté."

Voila ce qui à casé le raid 5, ne jamais faire d'extension de volume avec une extension, privilégié deux volumes c'est mieux.

Bon tu as de la chance, c'est normalement récupérable... écoute bien et suit ce que te dira gaetan, voir un autre pro du sujet qui passera par la, moi le shr je sèche  (cela m'intéresse pas en faites, j'aime bien mes raid à l'ancienne)

[ambrius]

Merci beaucoup.

Petite question, puisque j'y suis, et afin de ne pas reproduire la situation. (là c'est l'angoisse...)

Puisque j'ai deux emplacements dédiés à des SSD et deux disques de l'ensemble RAID5 sur l'extension, est il envisageable de les migrer vers le NAS (et eventuellement les 2 SSD vers l'extension mais c'est moins grave j'imagine si le cache plante suite à un problème de liaison...?)

Quoi qu'il en soit je ferai exactement comme l'indique Gaetan, tu l'imagines.

Je vous remercie.

C'est bien les NAS pour stocker sa vie mais quand ca plante c'est l'angoisse...

[Einsteinium]

Cela serais préférable de les avoirs dans la même unité effectivement, le raid est une tolérance à la panne certes, mais n'est pas une sauvegarde, c'est de la continuité de service.

Tu as de la place dans ton extension, fait y un volume de backup si tu ne veux pas de sauvegarde externe en attendant.

Sacré cache ssd, un seul disque suffit, car s'il plante, tu ne perd rien du tout, le cache s'arrête de lui même, je ne pense pas qu'il soit possible de le mettre en extension, vue qu'il dépend directement de la ram du synology, à voir en recherchant.

[ambrius]

Merci !

Oui il est clair qu'a minima, si la chance me sourit, je vais mettre en place un RAID0 de 2x8To sur l'extension pour sécuriser le volume initial dès la semaine prochaine et utiliser une sauvegarde cloud en plus (bon j'ai 10To quand même...).

Si tu as mieux à me conseiller (bande ou autre) et bien intégré à DSM, je suis bien évidemment preneur!

En attendant je reste "légèrement" stressé...

Merci Einsteinium

 

[gaetan.cambier]

il y a 6 minutes, Einsteinium a dit :

Sacré cache ssd, un seul disque suffit

pour le cache en écriture, syno impose un raid 1 de ssd ... autrement, tu est "limité" au cache en lecture

il y a 39 minutes, Einsteinium a dit :

moi le shr je sèche 

ce n'est qu'une couche de "lvm2" pour agréger les disque de taille diffferenter et comme peu de personne ne font de migration çà reste simple (bon, si on tombe sur un gars qui a migré 10 fois ses hdd, on pourrait gravement galérer )

Bon, pour en revenir au "problème" je pense tout simplement que le volume n'est pas monté vu que tout semble correct

2 commandes encore :

cat /etc/fstab
lvdisplay

après on passe aux choses sérieuses

 

 

[ambrius]

Voici les résultats Gaëtan

cat /etc/fstab

none /proc proc defaults 0 0

/dev/root / ext4 defaults 1 1

/dev/mapper/cachedev_0 /volume1 btrfs nospace_cache,synoacl 0 0

 

sudo lvdisplay

Password: 

  --- Logical volume ---

  LV Path                /dev/vg1000/lv

  LV Name                lv

  VG Name                vg1000

  LV UUID                zmStVY-6rZu-t5HL-JOR1-vuZ2-r8W3-4FTwVf

  LV Write Access        read/write

  LV Creation host, time , 

  LV Status              available

  # open                 1

  LV Size                21.81 TiB

  Current LE             5718448

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     1024

  Block device           253:0

 

[Einsteinium]

@gaetan.cambier Bon à savoir je le savais pas pour le cache, et on peut le mettre dans une extension ?

voila pourquoi j'aime mon bon vieux raid 

[gaetan.cambier]

par contre, on a un cache ssd pour nous emm*****

bon, on va voir se qu'il cache se petit ...

dmsetup info /dev/mapper/cachedev_0
dmsetup status /dev/mapper/cachedev_0

bon, il est tard, on verra le reste demain,... les données ne s’envoleront pas 

[ambrius]

Oui bien sûr :)
Merci à demain Gaëtan

sudo dmsetup info /dev/mapper/cachedev_0

Password: 

Name:              cachedev_0

State:             ACTIVE

Read Ahead:        16384

Tables present:    LIVE

Open count:        0

Event number:      0

Major, minor:      253, 1

Number of targets: 1

 

sudo dmsetup status /dev/mapper/cachedev_0

0 46845526016 flashcache-syno stats: 

    reads(283), writes(0)

    read hits(283), read hit percent(100)

    write hits(0) write hit percent(0)

    dirty write hits(0) dirty write hit percent(0)

    replacement(0), write replacement(0)

    write invalidates(0), read invalidates(0)

    pending enqueues(0), pending inval(0)

    metadata dirties(0), metadata cleans(0)

    metadata batch(0) metadata ssd writes(0)

    cleanings(0) fallow cleanings(0)

    no room(0) front merge(0) back merge(0)

    disk reads(0), disk writes(0) ssd reads(283) ssd writes(0)

    uncached reads(0), uncached writes(0), uncached IO requeue(0)

    disk read errors(0), disk write errors(0) ssd read errors(0) ssd write errors(0)

    uncached sequential reads(0), uncached sequential writes(0)

    pid_adds(0), pid_dels(0), pid_drops(0) pid_expiry(0)

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

    Read hit statistics:

    pending preread(0)

    match none read disk(0) busy in io(0) busy wait queue(0)

    match partial: total(0) 

    Write hit statistics: 

    busy inval(0)

    do pending write back(0)

    map skip_unaligned_io(0)

    dirty_writeback(0)

    cleanings_over_threshold(0)

    cleanings_total(0)

    preread_job_mem_count(0)

    num_uncached_write(0) num_write_cache(0) num_flush_bio(0)

    inval dirty writeback(0)

    write miss invalidate(0)

    map_inval(0) uncacheable_inval(0) do_pending_no_error_inval(0)

    pending enqueue inval (0) pending enqueue inval handled(0)

    disk flush start(0) disk flush done(0)

    dirty writeback start (0) dirty writeback done (0)

Modifié le 12 février 2017 par ambrius

[gaetan.cambier]

Rebonjour,

J'ai essayer de me renseigner sur le système de cache et ... je sais pas quel système est utilisé par syno 

Bref dans le doute, pour éviter toute connerie (car au final, on joue quand même avec tes données), je préfère que tu rentre un ticket au support officiel https://account.synology.com/support/support_form.php

à moins que quelqu'un d'autre ait le solution ... @Fenrir à tout hasard ?

Je répare assez souvent des raid, mais ce cache ssd m'embête et est vraiment pas courant sur le forum

[Fenrir]

Jamais regardé comment c'était monté chez syno, mais si c'est "juste" un cache lvm, le désactiver (lvconvert --uncache ...) voir le supprimer (lvremove ..) ne devrait avoir aucun impact sur les données s'il est vide (c'est le cas ici apparemment).

En quoi est il gênant ?

[ambrius]

Bonjour Fenrir, merci Gaëtan !

J'ai essayé de le démonter via DSM et impossible. Du coup il semblerait qu'il soit vide mais que le démontage ne soit pas possible (tout du moins via DSM GUI)

En effet je ne crois pas qu'il y ait eu de problème sur le RAID5 en tant que tel mais pour autant pas accessible (à mon très très humble avis, dès que le cache est démonté on devrait revoir le RAID5)

mais en effet je ne sais pas comment procéder

J'ai ouvert un ticket jeudi chez Syno avec un retour :

"

Bonjour

Merci d'avoir contacté notre support,

Si vous n'avez plus accès à vos données, alors nous pourrons tenter de remonter votre volume afin de récupérer vos données. Veuillez cependant noter qu'il s'agit d'une tentative et que nous ne pourrons absolument pas garantir la récupération des données, qui dépendra de l'état du système et de vos disques. Il est donc également possible que vos données soient perdues selon l'état.

Pour ce faire, nous aurons donc besoin d'un accès à distance afin d'opérer sur votre NAS.
Vous pourrez suivre ces étapes et nous envoyer les informations demandées:

1. Activer l'option "Accès à distance" dans DSM -> Centre d’assistance -> Services d’assistance
2. Il y aura une clé d'identification support que vous pourrez nous envoyer
3. activer le service ssh dans le panneau de configuration > terminal
4. Il nous faudra également un mot de passe temporaire pour le compte admin

Merci d'avance pour votre retour

je me suis executé le jeudi et ai fourni les infos.

Modifié le 13 février 2017 par ambrius

[ambrius]

Du coup quel serait la commande à tester pour démonter proprement le cache LVM via le terminal ?

Vous me conseillez d'attendre un retour du support de Syno ?

merci à vous deux

Modifié le 13 février 2017 par ambrius

[gaetan.cambier]

il y a une heure, Fenrir a dit :

si c'est "juste" un cache lvm

çà serait un cache lvm, on l'aurait vu dans les commande + haut normalement  (sauf problème évidemment)

donc, je suppose que c'est pas çà ... bref mystère ...

il y a une heure, Fenrir a dit :

En quoi est il gênant ?

ben, ne sachant pas comment fonctionne le cache ... j'aime pas faire des conneries 

et j'ai pas le matériel pour monter un syno de test avec cache SSD (si une âme charitable me fournis gracieusement le matériel, c promis, je test )

[Fenrir]

@gaetan.cambier : je ne pense pas que le cache soit gênant, mais tu as raison, mieux vaut se méfier (perso je ferais tout même un mount en ro, juste pour voir)

@ambrius Attends le retour de syno et profites du délai pour réfléchir à une solution de sauvegarde

Par exemple ton nas pour les data et le DX pour un premier niveau de sauvegardes

[gaetan.cambier]

bon : un mount en read only :

mount -o ro /dev/vg1000/lv /volume1

si tu as pas de message d'erreur, tu devrait avoir acces au donnée avec :

ls /volume1

(je pense que je dois pas m'attarder sur les commandes de base pour toi )

c vrai que c pas un grand risque ...

[ambrius]

sudo mount -o ro /dev/vg1000/lv /volume1

mount: /dev/vg1000/lv is already mounted or /volume1 busy

 

ps : pendant que j'y suis, cela m'a intrigué

 

ls /volume1/

 

@tmp

 

 

merci pour votre aide

forcément s'il lit le cache, il ne va pas trouver grand chose....

 

 

Modifié le 12 février 2017 par ambrius

[gaetan.cambier]

ok, on va essaye autre chose :

essaye toujours de le monter dans un dossier vide pour vérifier le contenu :

sudo mkdir /volume99
sudo mount -o ro /dev/vg1000/lv /volume99

si tu voit tes données, c bon 

 

[ambrius]

sudo mount -o ro /dev/vg1000/lv /volume99

mount: /dev/vg1000/lv is already mounted or /volume99 busy

 

bref vg1000/lv is already mounted...

j'ai créé volume99 avant bien entendu

[gaetan.cambier]

Ok, ca sera pour syno car je le vois pas dans la liste des mount ...
Probablement le cache ...

[Einsteinium]

C'est le cache qui bloque le volume effectivement, qui lui même ne se désactive pas, ne pouvant pas s'écrire sur le volume qui est en panne... le serpent ce mort la queue...

[ambrius]

Je vous tiens au courant de l'intervention du support Synology.

Une fois le cache démonté, en espérant que tout se passe bien, je ne remonterai pas de cache pour l'instant. Je vais faire en sorte de réintégrer les deux disques du RAID5 dans l'unité principale (avec votre soutien si vous en êtes d'accord), puis je verrai pour :

1/ mettre en place un backup sur l'extension et utiliser je pense HyperBackup sur mon Amazon Drive (Gaëtan je serai preneur des meilleurs paramétrages)

2/ voir si je peux relancer le cache à partir de l'extension, ensuite, mais cela ne doit plus être une priorité.

 

Bon en attendant tout cela reste hypothétique en attente de l'intervention du support, et je continue à serrer le postérieur...

Cela dit ce serait bien si Syno pouvait renseigner la stratégie utilisée pour leur cache, afin de comprendre ultérieurement comment résoudre cela, sachant que ce cache est un usage strandard, voir encouragé dans les réglages et la doc.

 

Merci à vous 3, je vous tiens au courant.

David