Tiggr Posted May 24, 2022 Share #1 Posted May 24, 2022 (edited) Hallo zusammen, Ich habe leider ein Problem, und hoffe hier auf eure Hilfe. Kurz zum Aufbau und aktuellem Status SHR-1 mit 5 (vor dem Stress 4) WD Red + HDDs : 3x 3TB und 2x 4TB (eine der 3TB Platten ist derzeit nicht eigebunden s.u.) ---> Volume 1 , EXT4 , 7 TB (Kein aktuelles Backup..... Shame on me) ---> Volume 3 , BTRFS, 260 GB (Backup 2 Tage alt) ---> Volume 4, BTRFS, 62 GB (Backup 2 Tage alt) Nach dem Update auf DSM 7.0 welches mehrere Tage Problemlos lief, baute ich gestern eine weitere 4TB Platte ein und fügte sie meinem SHR-1 hinzu. Bei ca. 75 % steig dann eine der 3TB Platten aus, mit stauts "Abgestürzt" die Volumes liefen alle noch, und das Raid hat sich trotz Status (Fehlerhaft) weiter erweitert, kurz vor Ende, ist die Kiste dann gänzlich eingefroren, und hat irgendwann nicht mal mehr auf pings reagiert. Nach einem Neustart lief die Speichererweiterung einfach weiter, jedoch jedoch nun war neben der Festplatte auch mein größtes Volume (1) "Abgestürzt". Sowie die beiden anderen Volumes auf dem selben SHR-1 Speicherpool in ReadOnly gegangen. Ich habe die Raid- Erweiterung dann zuende laufen lassen. Die Defekte Platte habe ich ausgetauscht(Auch wenn sie gar nicht so defekt scheint) Jedoch bleibt mein größtes Volume (und da es Medien sind, fehlt hier leider ein aktuelles Backup) weg, und ich möchte ungern den Raid reparieren mit der neuen Platte, und dabei eventuell die noch vorhandenen Daten des Volume überschreiben und es endgültig zerstören. Daher würde ich bevor ich das Raid repariere gerne das Volume wieder eingehängt bekommen. Um sicherzugehen das ich nichts weiter beschädige. Anbei ein Paar Infos aus der Konsole: cat /etc/fstab: none /proc proc defaults 0 0 /dev/root / ext4 defaults 1 1 /dev/mapper/cachedev_0 /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,relatime,ro,nodev 0 0 /dev/mapper/cachedev_1 /volume3 btrfs auto_reclaim_space,ssd,synoacl,relatime,nodev 0 0 /dev/mapper/cachedev_2 /volume4 btrfs auto_reclaim_space,ssd,synoacl,relatime,nodev 0 0 lvdisplay: Using logical volume(s) on command line. --- Logical volume --- LV Path /dev/vg1/syno_vg_reserved_area LV Name syno_vg_reserved_area VG Name vg1 LV UUID HOyuTp-ozYw-WG4X-M1vA-WqQW-tRIm-CUoU8h LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 12.00 MiB Current LE 3 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 249:0 --- Logical volume --- LV Path /dev/vg1/volume_1 LV Name volume_1 VG Name vg1 LV UUID o1PTXF-fKVl-9mKe-TFpF-lAd7-0TE4-8qgHGM LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 7.84 TiB Current LE 2055680 Segments 16 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 249:1 --- Logical volume --- LV Path /dev/vg1/volume_3 LV Name volume_3 VG Name vg1 LV UUID 4xFm7L-rVxD-w2Fc-GLQb-Hde5-9mLi-RX5vOa LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 275.00 GiB Current LE 70400 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 249:2 --- Logical volume --- LV Path /dev/vg1/volume_4 LV Name volume_4 VG Name vg1 LV UUID W6q8V3-wRjS-7pG6-Ww94-6oLm-vl3H-PCq2eR LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 64.00 GiB Current LE 16384 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 249:3 vgdisplay: Using volume group(s) on command line. --- Volume group --- VG Name vg1 System ID Format lvm2 Metadata Areas 4 Metadata Sequence No 55 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 3 Max PV 0 Cur PV 4 Act PV 4 VG Size 8.17 TiB PE Size 4.00 MiB Total PE 2142630 Alloc PE / Size 2142467 / 8.17 TiB Free PE / Size 163 / 652.00 MiB VG UUID NyGatF-b85O-Ceg3-MuPY-sOTW-S2bo-P3ODO5 --- Logical volume --- LV Path /dev/vg1/syno_vg_reserved_area LV Name syno_vg_reserved_area VG Name vg1 LV UUID HOyuTp-ozYw-WG4X-M1vA-WqQW-tRIm-CUoU8h LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 12.00 MiB Current LE 3 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 249:0 --- Logical volume --- LV Path /dev/vg1/volume_1 LV Name volume_1 VG Name vg1 LV UUID o1PTXF-fKVl-9mKe-TFpF-lAd7-0TE4-8qgHGM LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 7.84 TiB Current LE 2055680 Segments 16 Allocation inherit Read ahead sectors auto - currently set to 1024 Block device 249:1 --- Logical volume --- LV Path /dev/vg1/volume_3 LV Name volume_3 VG Name vg1 LV UUID 4xFm7L-rVxD-w2Fc-GLQb-Hde5-9mLi-RX5vOa LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 275.00 GiB Current LE 70400 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 249:2 --- Logical volume --- LV Path /dev/vg1/volume_4 LV Name volume_4 VG Name vg1 LV UUID W6q8V3-wRjS-7pG6-Ww94-6oLm-vl3H-PCq2eR LV Write Access read/write LV Creation host, time , LV Status available # open 1 LV Size 64.00 GiB Current LE 16384 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 768 Block device 249:3 --- Physical volumes --- PV Name /dev/md2 PV UUID aWjDFY-eyNx-uzPD-oqBO-5Gym-54Qr-zzkxUZ PV Status allocatable Total PE / Free PE 175270 / 0 PV Name /dev/md3 PV UUID J2CWXO-UmYK-duLr-3Rii-QcCe-nIoZ-aphBcL PV Status allocatable Total PE / Free PE 178888 / 0 PV Name /dev/md4 PV UUID 9xHJQ8-dK65-2lvJ-ekUz-0ezd-lFGD-pDsgZx PV Status allocatable Total PE / Free PE 1073085 / 0 PV Name /dev/md5 PV UUID GQwpPp-1c3c-4MSR-WvaB-2vEc-tMS6-n9GZvL PV Status allocatable Total PE / Free PE 715387 / 163 LVM Backup vor der Speichererweiterung: :~$ ls -al /etc/lvm/backup/ total 16 drwxr-xr-x 2 root root 4096 May 23 17:55 . drwxr-xr-x 5 root root 4096 May 23 17:44 .. -rw-r--r-- 1 root root 5723 May 23 17:53 vg1 Ich bin Dankbar für jede Hilfe. Schönen Abend noch Steven PS: Ja ich weis, es geht genau das Volume flöten von dem ich kein Backup habe welch Ironie Edited May 24, 2022 by Tiggr Quote Link to comment Share on other sites More sharing options...
IG-88 Posted May 24, 2022 Share #2 Posted May 24, 2022 ls /dev/sd* um mal zu sehen welche platten da sind und was drauf ist danach würde man mit mdadm --examine weiter machen um zu sehen in welchen zustand die raids sind, u.a. gibt es da "event" idealerweise ist der bei allen gleich, eine platte die eine kleinere zahl hat könnte man unter datenverlust wieder in ein raid "zwingen" (je event sind das in der regel 64k verlust), das hat dann natürlich auswirkungen auf files oder das dateisystem aber man kann dann häufig die meisten daten sichern, schwierig wird es wenn man genau wissen will was dann defekt ist das es während des raid erweiterns passiert ist hatte ich noch nicht, wenn du mit englisch klar kommst mach einen neuen tread in "DSM Post-Installation" auf und schau das du flyride dazu einlädst, der hat bei solchen sachen reichlich erfahrung es gibt von ihm auch etliche threads mit recovery die man sich als beispiel ansehen kann z.b. https://xpenology.com/forum/topic/59547-volume-crashed-after-reboot/ generell muss man neben dem zustand feststellen auch etwas in richtung ursachenforschung unternehmen, denn wenn es ram probleme oder das netzteil sind kann dir das beim recovery versuch alles noch schlimmer werden wenn dann wieder etwas versagt das bisher ging man sollte also die log's ansehen ob man herausfinden kann was beim raid erweitern schief ging genrell ist ein SHR aus einem oder mehreren mdadm raids aufgebaut die mit LVM2 zusammengefügt sind wenn du bisger 3 3 3 4 TB platten hattest war das ein raid5 mit 3 TB auf jeder platte und der platz davon war als lvm2 zur verfügung, beim erweitern mit der zweiten 4TB hätte dsm versucht das vorhandene raid5 mit 3TB zu erweitern und mit den 2x1TB die auf den 4TB disks übrig wären hätte es ein raid1 mit 2x1TB gebildet und das mit lvm2 den platz (1TB nutzbar) hinzugefügt md0 und md1 sind "uninteressant" das ist dsm system und linux swap als raid1 auf jeder platte, alles ab md2 ist wichtig Quote Link to comment Share on other sites More sharing options...
Tiggr Posted May 25, 2022 Author Share #3 Posted May 25, 2022 flyride habe ich dreister weise gestern abend noch direkt angeschrieben ls /dev/sd* /dev/sda /dev/sda6 /dev/sdb1 /dev/sdb7 /dev/sdc2 /dev/sdc8 /dev/sdd2 /dev/sdd8 /dev/sdf5 /dev/sdf9 /dev/sda1 /dev/sda7 /dev/sdb2 /dev/sdb8 /dev/sdc5 /dev/sdc9 /dev/sdd5 /dev/sdf /dev/sdf6 /dev/sdq /dev/sda2 /dev/sda8 /dev/sdb5 /dev/sdc /dev/sdc6 /dev/sdd /dev/sdd6 /dev/sdf1 /dev/sdf7 /dev/sdq1 /dev/sda5 /dev/sdb /dev/sdb6 /dev/sdc1 /dev/sdc7 /dev/sdd1 /dev/sdd7 /dev/sdf2 /dev/sdf8 Quote Link to comment Share on other sites More sharing options...
Tiggr Posted May 25, 2022 Author Share #4 Posted May 25, 2022 Nochmal in English: Quote Link to comment Share on other sites More sharing options...
flyride Posted May 25, 2022 Share #5 Posted May 25, 2022 Recovered by running fsck.ext4 against the volume1 device, and then manual mount of the volume. The SHR subarrays are in a degraded state with removed (not missing) members. The removed members are not aligned to a single faulty disk. All data should be offloaded, volumes and storage pools deleted, and then build a new SHR or RAID5. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.