DiogenesMar 25

Tja, das Restore des #Synology-NAS lief heute früh immer noch. Heute abend wollte er auf einmal die Adresse des Backup-NAS, behauptet dann keinen Zugriff zu haben.
Auch erneute Restore-Versuche schlagen damit fehl.
Ich erreiche aber das Backup-NAS problemlos. Auch der Port 6281 geht durch.

In der Versionshistorie der erfolgreichen Backups sehe ich auch nicht die vermutlich defekten Dateien unter /volume1/@database/pgsql

Versuchtes Umbenennen des Verzeichnisses bringt einen I-O-Error.

Show threadDiogenesMar 25

fsck.ext sagt, es kann den Superblock nicht lesen. Auch tune2fs sagt "couldn't find valid filesystem superblock".

Und nu?

#ratlos

Show threadDiogenesMar 25
Oh, auch ein fsch.ext auf /volume1 bringt den gleichen Fehler.
Show threadmc
@Diogenes wat is das? ext4 auf mirror?
Mar 25 at 8:18pmWeb
Show threadDiogenesMar 25
@mc fsck selbst kennt Synology nicht, nur fsck.ext4, aber die 4 fehlte in meinen Trööts.
Show threadmcMar 26
@Diogenes fsck ist auch nur ein wrapper https://github.com/util-linux/util-linux/blob/master/disk-utils/fsck.c#L637 und damit ueberfluessig - fsck.ext4 ist fuer ein ext4 also richtig, fsck ruft dann nur unsichtbar fsck.ext4 auf.

der kaputte Superblock ist der (ein) Index für das Filesystem, da steht drin wo das Filesystem Daten lagert - ohne die Info findet der Computer nix.

Superblocks sind in meiner Erinnerung eigentlich redundant (Backup Superblocks).

Wenn du deiner Syno gesagt hast, dass es ein Spiegel (und kein Stripe) ist, dann sollte das ext4 zweimal existieren.

Dass ein Superblock durch Filesystem korruption kaputt geht, ist extrem selten, normalerweise würde ich das Problem in der Festplatte suchen:

Hast du einen Spiegel, kann es sein, dass der kaputte Superblock von Disk a auf Disk b noch okay ist.

Du kannst die Festplatten aus der Syno nehmen und an einen beliebigen Rechner anstecken - dort Linux booten und dann die Disk versuchen zu mounten.

Vor jedweden Versuch das zu fixen wuerde ich aber (und das ist eigentlich immer der Rat, wenn man das Problem hat) eine groessere freie Platte nehmen und die scheinlich kaputte Disk nochmal woanders hin spiegeln, entweder 1:1 auf die grosse Platte, oder als Abbilddatei in ein Filesystem auf die Platte (Stichwort dd, Parameter doppelt lesen, verstehen und doppelt kontrollieren, dass man sie nicht vertauscht hat). Dann kannst du auf der Abbild-datei operieren (den Tools ist es egal ob du da eine physische Platte oder eine Abbilddatei hast).

Und wiederum: Mit gespiegelten Platten hat man den Versuch zweimal.

Wenn du das noch nie gemacht hast, solltest du jemanden ueber die Schulter gucken lassen, vielleicht ist Platz bei der @lug_nuernberg im physischen Treffen für sowas, heute ist wohl nur virtuelles Treffen https://www.lug-noris.de/

Syno, SATA Adapter https://www.amazon.de/UGREEN-Festplatten-Dockingstation-unterst%C3%BCtzt-Offline-Klonen-Schwarz/dp/B0FPM32XNZ/, werkzeug, und ein (zur not grml von usb stick gebootetes) linux mitnehmen und los gehts. Zum spiegeln brauchst du eine platte mit zweiten adapter oder eine usb platte.

Und zu oben: mit Abbilddatei arbeiten ist nicht unbedingt besser, verringert aber im Zweifelsfall die Fehlerrate, weil eher klar ist was die (kaputte) physikalische disk ist und was das Abbild, auf dem du testen willst.

Und letztlich: fsck /volume1 sagt mir dass du auf dem gemounteten Volume arbeitest - fsck verweigert da viele Operationen auch einfach. In solchen Faellen fsck immer auf die nicht-gemountete Disk (oder eben zur Sicherheit: auf einem Abbild).
util-linux/disk-utils/fsck.c at master · util-linux/util-linux

Contribute to util-linux/util-linux development by creating an account on GitHub.

GitHub
Show threadDiogenesMar 27
@mc Ach je. Die Platten sind im Syno-eigenen Format gespiegelt. Dachte eigentlich, daß ich damit sicher bin, zusammen mit einem Backup des gesamten NAS auf ein anderes NAS zwei Häuser weiter. Doch wenn die Backup-Software auch beschädigt ist, hilft das nix.
Das übersteigt meine Fähigkeiten. Ich hoffe jetzt mal auf den Synology-Support.
Ansonsten muß ich wirklich mit zwei neuen Festplatten neu aufsetzen und hoffen, daß ein dann funktionierendes Hyperbackup alles zurückholt.
Show threadmcMar 27
@Diogenes google sagt SHR-1 ist auch nur md und lvm.

md ist trivial, lvm ... nicht mehr so.

theoretisch muesste man das lvm von /dev/sataXpX statt /dev/mdX rausziehen können. Bzw andersrum: du kannst md sagen dass dein spiegel grad halt nur aus entweder der A- oder der B-Platte besteht.

Kaputter Superblock ist aber halt... wie gesagt selten... Hattest du vielleicht Stromausfall oder so, dass das ding mitten im write verreckt ist? Selbst wenn die Daten grade im Cache lagen und Stromausfall kam, sollte das Filesystem nur inkonsistent, und nicht kaputt sein. Eventuell hat aber auch einfach die Hardware einen Schlag, dass der SATA Kontakt der Platte eher so meh ist.

Wenn du einfach ein Backup wiederherstellen kannst, wird das aber tatsaechlich das schnellste sein, alles andere ist Stunden an Frickelei, und wenns wirklich beide Platten erwischt hat (ein md liest von beiden Platten, der Fehler würde bei Inkonsistenz immer wieder mal anders aussehen??)

Aber auch: je laenger du auf eine defekte Disk schreibst (automatisch, wenn sie nicht RO gemountet ist), desto mehr Fehler schleichst du ins Filesystem rein.

Bild: volume1 liegt auf Volume Group vg1, vg1 zieht 15T von /dev/md2, /dev/md2 verteilt sich auf /dev/sda(1-4)p5

zu /volume1 legt die syno dann "nur" noch einen caching layer dazwischen, damit der Rost sich nicht die ganze Zeit drehen muss (und auch der Cache kann Probleme verursachen)