Katastrophe - Speicherpool abgestürzt und nicht reparierbar

privileguan · August 13, 2024

Hallo,

ich bin ziemlich verzweifelt und hoffe, dass evtl. hier jemand noch eine Idee hat. Folgende Ausgangssituation:

- Server mit DSM 6.2 und 7 HDDs (6x 20TB und 1x 18TB), die über das Mainboard sowie über einen SATA Controller angeschlossen sind

- 1 Speicherpool und 1 Volume, SHR2, BTRFS

- 1 zusätzliche 24 TB HDD hatte ich vor 3 Tagen an den SATA Controller gehängt und das System erweitert

- nach wenigstens 48h Konsistenzprüfung - also denke ich fast fertig - ging der Server aus (keine Ahnung warum, aber ich hatte das Problem in 2023 schon 2x); im Protokoll steht dann nur "System started up from improper shutdown" -> bisher danach aber keine Probleme

- nun kommt nach Neustart immer die Meldung "das System hat einen oder mehrere abgestürzte Speicherplätze erkannt. Bitte prüfen Sie, ob die folgenden Erweiterungseinheiten und Festplatten richtig angeschlossen sind und normal funktionieren: [Aufführung ALLER 8 HDDs]

- nach dem 1. Neustart hat er die laufende Konsistenzprüfung noch ohne Fehler beendet (ca. 1/2 h)

- bei Volume zeigt er abgestürzt an und bei Speicherpool auch

- die Größe des angezeigten Speicherpools wird angegeben mit der Größe VOR Erweiterung

- nach Neustart ohne die neue 24TB HDD keine Änderung

- nach Wiederanschließen und Neustart mit der 24 TB HDD steht bei dieser plötzlich "Systempartitonierung fehlgeschlagen" und ich könnte einen neuen Pool mit dieser erstellen

- SMART-Werte scheinen bei allen HDD ok zu sein, die schnellen SMART-Tests laufen ohne weiteres durch

Folgendes habe ich probiert:

https://xpenology.com/forum/topic/43754-volume-abgestürzt-was-tun/

https://xpenology.com/forum/topic/14337-volume-crash-after-4-months-of-stability

https://www.vsam.pro/crashed-synology-volume-and-how-to-restore-ds415-play/

Bei den Reparaturversuchen endet es dann immer in der Meldung "Couldn't open file system"...

privileguan · August 13, 2024

root@server:~# lvdisplay
Couldn't find device with uuid ufLIYb-jQyL-oOBJ-MRFL-uf6O-nHfP-OC3muX.
--- Logical volume ---
LV Path /dev/vg1/syno_vg_reserved_area
LV Name syno_vg_reserved_area
VG Name vg1
LV UUID fDF1KC-Ur4B-OFXD-r3jb-f01v-cpdW-3Pa23h
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 1536
Block device 253:0

--- Logical volume ---
LV Path /dev/vg1/volume_1
LV Name volume_1
VG Name vg1
LV UUID UqMgFq-lz0F-Lc8h-EDud-Sfhr-Ucpc-cnMWJL
LV Write Access read/write
LV Creation host, time ,
LV Status NOT available
LV Size 89.11 TiB
Current LE 23359488
Segments 9
Allocation inherit
Read ahead sectors auto

IG-88 · August 13, 2024

also mal so grundlegend müsste man erst die raid's rekonstruieren bzw. zum laufen bringen und dann die richtige anordung in dem lvm rekonstuieren

wenn du initial mit 6x 20TB und 1x 18TB als shr2 begonnen hast dann war es

7 x 18TB als raid6 + 6 x 2TB als raid6

90TB + 8 TB bzw. muss man ja in "echten TB rechnen wenn man deine zahl unten mit 89.11TiB sieht

also 7 x 16.37 als raid6 + 6 x 1.82 als raid6 (je zwei disks abziehen wegen der redundanz, das ergibt die nutzkapazität)

81.85TiB + 7.28 TiB = 89.13 TiB (ein paar kleine rundungsfehler aber man sieht die zahl stimmt mit dem lvm überein)

der lvm zustand ist also noch wie vor der erweiterng (was ja auch passt, wenn es beim raid erweitern schief geht passiert der folgende schritt nicht mehr bei dem dann das 3. neue raid volume zum lvm adiert würde)

das mit dem btrf wäre nebensache da das filesystem dann noch on top auf dem lvm kommt, filesystem ist also auch immer noch die alten 89,11 TiB

wenn du eine 24TB disk in dem szenario hinzufügst dann würden 16.37TiB dem ersten raid6 zugeschlagen und 1.82TiB dem zweiten raid hinzugefügt, der rest der platte (4TB von 24TB) wären ungenutzt geblieben

du suchst also den status von zwei mdadm raid's (es gibt da auch noch zwei raid1 mdadm raids für system und swap die kein lvm bilden und das DSM system darstellen)

11 hours ago, privileguan said:

- nach Wiederanschließen und Neustart mit der 24 TB HDD steht bei dieser plötzlich "Systempartitonierung fehlgeschlagen"

das wäre noch einigermaßen normal da eine hinzugefügte platte am anfang immer je eine system und swap raid1 partition bekommt die dem mdadm raid1 für system und swap hinzugefügt wird, das papssiert noch vor der raid erweiterung für die daten volumes und war bereits abgeschlossen als die sache später schief ging, das globale raid1 für system und swap vermissen nur eine raid platte und das wird gemeldet, stört nicht und kann man erst mal ignorieren, was dich interessiert ist der zustand der beiden mdadm raid6

also erst mal rausfinden was so los ist mit den mdadm raids (die sachen müssen in der regel als sudo ausgeführt werden)

cat /proc/mdstat
mdadm --examine --scan
mdadm --detail --scan --verbose

erst wen man hier bei den raid's klarheit hat und lesbare raid's hat (die notfalls auch degraded sein können) kann man mit dem lvm weiter machen

mal so als marschrichtung:

1. klären warum das system einfach so ausgegangen ist, wenn dir das beim raid recovery wieder passiert wird es unter umständen noch schlimmer (aber zumindest wird es nicht besser und man muss von vorn anfangen und verliert evtl. mehr daten)

2. für die raids gibt es einen zähler an dem man sehen kann welche disks welchen stand in sachen raid aktualität hat, ist eine disk "älter" als die anderen ist sie nicht gültig und gibt es keinen cahce/puffer der diese daten noch hat ...und sind mehr als zwei platten ungültig wird das raid nicht mehr von allein starten da shr2 gleich 2 dedundante platten bedeutet also raid6 und wenn diesem mdadm raid6 mehr als 2 platten "fehlen" hält es erst mal an und fragt nach der alles weiß und sich auskennt (sysop aka root user der alles richten kann und muss)

prizipiell kann man platten eines raid von hand zwingen zusammen zu laufen auch wenn sie nicht den gleichen stand haben aber das bedeutet immer das daten verlustig gegangen sind und das muss später das dateisystem ausbaden (datein mit fehlerhaften inhalten oder auch fehlerhafte strukturen im dateisystem)

wenn du hier im forum nach infos suchst dann bist du an den stellen gut aufgehoben wo flyride an der reperatur dran war, da gibts was zu sehen und zu lernen

gibt es etwas in /etc/lvm/backup/vg1 ?

Edited August 13, 2024 by IG-88

IG-88 · August 13, 2024

es gibt da auch ein oder zwei deutsche threads wo raids wiederhergestellt wurden aber do habe ich auf anhieb nichts parat

aber du kannst dir mal diese hier ansehen im ein gefühl dafür zu bekommen wie es weiter gehen würde

https://xpenology.com/forum/topic/59547-volume-crashed-after-reboot/

https://xpenology.com/forum/topic/63132-volume-lost/

https://xpenology.com/forum/topic/52941-degraded-volume-cant-replace-disk-volume-crashed-ext4-shr/

hier noch etwas das in deutsch war

https://xpenology.com/forum/topic/25841-volume-crahsed

https://xpenology.com/forum/topic/24767-asrock-j4105-itx-sata-controller-defekt/

Edited August 13, 2024 by IG-88

privileguan · August 14, 2024

Erstmal vielen Dank für die ausführliche Antwort. Ich habe nun einige Stunden mich in das Thema hineingelesen, auch die genannten Threads, und auch schon einiges probiert. Bisher hat nichts geklappt, wobei ich zugeben muss, dass es mir schwer fällt, da richtig durchzusteigen, insbesondere die angeführten Befehle auf meine Konfiguration zu beziehen.

Ich bin nun erstmal dabei, mittels UFS Explorer die Daten runterzuziehen, welche sich seit dem letzten Backup geändert haben bzw. dazugekommen sind (leider über 3 Monate her [ich Idiot]). Ich hoffe heute abend ist das durch und dann würde ich es gern weiter versuchen.

Die ganze Neukonfiguration (Surveillance, shared Folders, Docker, Smarthome usw.) wäre aber sehr aufwändig, so dass ich ungern einen neuen Speicherpool anlegen will. Wenn ich Pech habe, crasht auch noch ne Backup-Platte beim überspielen...

12 hours ago, IG-88 said:

1. klären warum das system einfach so ausgegangen ist, wenn dir das beim raid recovery wieder passiert wird es unter umständen noch schlimmer (aber zumindest wird es nicht besser und man muss von vorn anfangen und verliert evtl. mehr daten)

Das ist ein guter Punkt. Ich finde es nicht heraus. Das passierte bisher schon 2x, was nicht schön ist, aber bisher auch kein großes Problem. Ich habe jetzt prophylaktisch eine neue USV bestellt, ggf. hat die alte eine Macke. Das Netzteil sollte nach 48h Konsistenzprüfung mit einer zusätzlichen HDD nicht das Problem sein.

Sollte ich die neue 24 TB für das recovery eigentlich dranlassen oder lieber rausnehmen?

privileguan · August 16, 2024

Also ich bin immer noch am Daten sichern...und da hierbei unerwartet viele Dateien beschädigt und nicht wiederherstellbar sind, werde ich nicht weiter versuchen das RAID wieder zusammen zu bekommen, sondern die alten Backups neu kopieren.

Das ist super ärgerlich und ich muss sagen, damit hätte ich auch nicht gerechnet, dass mir sowas mit nem RAID6/SHR2 passieren kann...

Wie kann ich sowas zukünftig vermeiden? Hilft es den Schreibcache zu deaktivieren?

Was wäre eine bessere Backup Strategie? Habe mein Backup außerhalb meines Hauses auf 10 HDDs. Wenn mir davon jetzt beim überspielen eine hops geht, sind die Daten weg, weil ich auf den NAS-HDD ja dann schon einen neuen Speicherpool angelegt habe...

Um dieses Risiko zukünftig zu minimieren fällt mir folgendes ein:

1. ein weiteres Backup

2. ein weiteres Xpenology System worauf ich eine komplette Systemsicherung ziehe und diese per Hyperbackup dann wöchentlich aktuell halte. Das würde auch die Pakete usw. sichern

--> allerdings kein Spaß, die ca. 100 TiB per GBit LAN beim ersten Mal zu überspielen (das wird ja Wochen dauern und wer weiß, ob es in dieser Zeit einen Stromausfall oder Netzwerkfehler usw. gibt)

3. mehrere Speicherpools bzw. einen nicht zu erweiternden mit RAID1; mit den Paketen und den wichtigsten Programmen

Was wäre sinnvoll bzw. hat vllt. noch jemand eine andere Idee?

apejovic · August 23, 2024

Ich nutze eine DS214play und eine DS112 für Backups über Hyperbackup.

Eine USV ist am Produktiv-Xpenology angeschlossen und übermittelt ein Shutdown für die DS214play und DS112, falls es zum Stromausfall kommt.

Die erste Sicherung dauert natürlich lange. Die weiteren inkrementellen Backups sind im Schnitt zwischen 10min und 30min.

Die DS214play wird automatisch nur für die diesen Zeitraum eingeschaltet und beendet das Backup.

Notfalls wird es händisch eingeschaltet, falls deutlich mehr gesichert werden muss.

Wenn Du die Benachrichtigung per Email einrichtest, dann kannst Du sehen wie lange der Vorgang dauert und ob dieser erfolgreich war.

Täglich wird auf die DS214play gesichert. Einmal wöchentlich von der DS214play auf eine DS112.

Zusätzlich überlege ich jetzt zwei externe HDDs für 1x Monat zu nutzen im Wechsel.

Diese soll dann bei der Familie aufbewahrt werden.

Ich sichere aber wirklich nur die wichtigsten Daten wie z.b. Dokumente, Bilder und Videos.

Dafür benötige ich Aktuell eine 6TB HDD.

Den Rest an Daten kann ich immer wieder woanders bekommen. Dafür möchte ich nicht den wertvollen Speicherplatz der HDDs opfern.

privileguan · August 26, 2024

apejovic: vielen Dank für den Input; ich überlege immer noch hin und her, welche Variante bei den großen Datenmengen für mich am praktikabelsten ist, bzw. ob ich nicht auch ein anderes RAID verwenden sollte... SHR scheint ja nicht sonderlich widerstandsfähig zu sein - ich habe nun schon wieder ein Problem:

Nach Neuerstellung von Speicherpool und Volume mit SHR2 (BTRFS) hatte ich 16,4 TB Daten per USB wieder überspielt. Danach wollte ich per SMB weitere Daten übertragen, hatte aber dabei Geschwindigkeitsprobleme und konnte irgendwann den Server nicht mehr im Netzwerk erreichen. Habe dann auf die Reset-Taste gedrückt (es lief keine Dateioperation und der Schreibcache ist bei allen HDD deaktiviert).

Danach war der Server wieder erreichbar, allerdings das Volume abgestürzt. Der Speicherpool war diesmal in Ordnung und so dachte ich nach Konsistenzprüfung (über 48h) und Neustart läufts wieder...aber falsch gedacht.

Ich könnte jetzt das Volume wieder neu erstellen, müsste dann aber wieder die gerade eingerichteten Pakete wieder mühevoll einrichten.

Kann evtl. jemand sagen, ob ich möglichst einfach aus dieser Situation heraus eine Reparatur einleiten kann? Das RAID an sich sieht eigentlich gut aus; hier eine Auswahl an üblichen Abfragen (siehe putty log.txt)