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.

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

Und nu?

#ratlos

Oh, auch ein fsch.ext auf /volume1 bringt den gleichen Fehler.
@Diogenes wat is das? ext4 auf mirror?
@mc fsck selbst kennt Synology nicht, nur fsck.ext4, aber die 4 fehlte in meinen Trööts.
@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