Datenrettung von SHR2

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

lexi_

Benutzer
Registriert
09. Aug. 2025
Beiträge
10
Reaktionspunkte
5
Punkte
3
Hallo zusammen,

sorry, falls ich was falsch mache - hier ist mein erster Besuch in diesem Forum.

Ich habe ein DS918+ und hatte dort ein SHR2 mit 4 Platten drin.

Das SHR2 ist "abgestürzt" und konnte von dem Synology nciht wieder aufgebaut werden. (also: erst einmal vier neue Platten gekauft und das Backup von Hyperbackup eingespielt... aber:)

Jetzt fehlen mir die Files, die nach dem letzten Hyperbackup auf das SHR2 kopiert wurden.

Ich baue die Platten also in meinen Linux-Server und konnte das RAiD6 und die vgs/lvms sehen.... aber egal, was ich sonst mounte... keine Daten?

Das ursprüngliche Problem schien zu sein, dass es ein Problem mit dem RAID6 gab, das ich unter Linux beheben konnte. Wie komme ich jetzt an meine Daten?

Der Output von vgs:
WARNING: Couldn't find device with uuid dhUOx9-2vtR-hMRU-IFVb-x6aa-YW5E-Qo3U2q.
WARNING: PV /dev/md126 in VG vg1 is using an old PV header, modify the VG to update.
WARNING: PV /dev/md127 in VG vg1 is using an old PV header, modify the VG to update.
WARNING: VG vg1 is missing PV dhUOx9-2vtR-hMRU-IFVb-x6aa-YW5E-Qo3U2q (last written to /dev/md4).
VG #PV #LV #SN Attr VSize VFree
vg1 3 2 0 wz-pn- 14.53t 572.00m


Der Output vom lvs:
WARNING: Couldn't find device with uuid dhUOx9-2vtR-hMRU-IFVb-x6aa-YW5E-Qo3U2q.
WARNING: PV /dev/md126 in VG vg1 is using an old PV header, modify the VG to update.
WARNING: PV /dev/md127 in VG vg1 is using an old PV header, modify the VG to update.
WARNING: VG vg1 is missing PV dhUOx9-2vtR-hMRU-IFVb-x6aa-YW5E-Qo3U2q (last written to /dev/md4).
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
syno_vg_reserved_area vg1 -wi-a----- 12.00m
volume_1 vg1 -wi-a---p- 14.53t


Wenn ich volume_1 mounte, scheint da aber kein Filesystem drin zu sein... Kann mir jemand helfen?
 
Ich hab noch herausgefunden, dass zwischen dem /dev/vg1/volume_1 und den btrfs noch mit dmsetup ein (propriatäres) Cachelayer eingemountet wird, vom dem ich leider nur den Namen flashsynno gefunden habe.
 
Es gibt ein C‘t Special „Desinfect 2024/2025“ mit dem Aritel „Daten vom NAS kratzen“ …

Vlt. helfen die dort enthaltenen Imfos
 
  • Like
Reaktionen: lexi_
Mit der Anleitung von Syno kam ich damals (war ein Test, für den Ernstfall wenn was ausfällt) mal bis zum btrfs.
Dann hat sich rausgestellt, dass man dort ziemlich limitiert ist, auf die Version die von der jeweiligen Syno verwendet wird. Evt. lässt sich das mit den richtigen Options dann auch richtig mounten, damals war das Konklusio eher in die Richtung, nimm einen USB Stick und boote das richtige "alte" Linux.

Hast du ext4 oder btrfs?

Das ist der alte Post von damals, da findet sich dazwischen immer wieder was zu den Mount Befehlen und dann auch zu kompatiblen DS<->Linux Distributionen.

https://www.synology-forum.de/threads/btrfs-volume-am-pc-auslesen.109614/
 
  • Like
Reaktionen: lexi_
Es geht um btrfs.

Es stellt sich heraus, dass das btrfs wegen eines Stromaufalls einen Fehler hatte (System konnte nicht sauber runterfahren)

Ich konnte die Platten in einem Linux-PC mounten und mir das Delta zum letzten Backup mit
btrfs restore ...
retten.

Danke für Eure Hilfen!
 
System konnte nicht sauber runterfahren

Super, dass der restore geklappt hat!
Die Frage ist, ob das auch in der Syno geklappt hätte, wenn die Platten drin geblieben wären.

Jedenfalls überleg dir für die Zukunft eine USV anzuschaffen. In der Theorie sollte ja meistens nix sein, aber wie man sieht, kann dann doch mal was korrupt werden.

Gerade nochmal nachgelesen, btrfs ist da tatsächlich weniger robust als ext4.
 
  • Like
Reaktionen: ctrlaltdelete
Lässt sich aber ganz gut reparieren, wenn man es "gemounted" bekommt.
 
Guter Gedanke - mit meinen aktuellen Erfahrungen würde ich das RAID in dem Synology lassen und dort versuchen es zu reparieren. Aber wegen der Bussiness Continuity war kein Rahmen für Experimente. Daher zuerst neue Platten und Backup einspielen, während man woanders versucht das Delta aus dem Platten zu kratzen.

Das mit der USV hatte ich mir auch gedacht. Schien aber wohl NOCH anders gewesen zu sein (Stand heute). Das Synology hatte noch auf pings reagiert, aber kein Web und kein SSH oder sonst was gezeigt. So konnte das NAS nicht kontrolliert runtergefahren werden. Da hat dann jemand den Stecker gezogen. Das war die Ursache. Da hätte auch keine USV geholfen.
 
  • Like
Reaktionen: ctrlaltdelete
Und dazu noch die Backup Strategie überdenken.
Weiß ja nicht wie oft du sicherst. Aber die Abstände sollten so gewählt sien das man nen Verlust zwischen 2 Sicherungen verkraften kann.
 
Evtl. Snapshot & Replication sinnvoll einsetzen.
 
  • Like
Reaktionen: metalworker
Und dazu noch die Backup Strategie überdenken.
Weiß ja nicht wie oft du sicherst. Aber die Abstände sollten so gewählt sien das man nen Verlust zwischen 2 Sicherungen verkraften kann.
Ich sichere täglich (IIRC geht's nicht öfter mit HyperBackup) - gibt's da eine bessere Lösung?
 
Das klingt gut - kann man daraus externe Backups mit minutengenauer Auflösung machen?
 
Zuletzt bearbeitet von einem Moderator:
@ctrlaltdelete ok, danke für die Klarstellung. Ich habe kein zweites Synology, wohin ich Daten replizieren könnte. Das wäre dann ggf zu überlegen. Daher verwendete ich bisher HyperBackup. Dann muss ich mal überlegen, was ich in Zukunft mache
 
  • Like
Reaktionen: ctrlaltdelete

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat