Vorab: Mein Wissen, was die Linux Befehle und Linux Wissen betrifft ist begrenzt. Aber macht hier ein Neuaufsetzen mit Restore der Daten nicht mehr Sinn? Auch was den zeitlichen Aufwand betrifft und was jetzt alles schon probiert wurde? Ist nur eine Frage, keine Empfehlung.
Und mal aus reiner Neugier: Es wurde in den Beiträgen von Cache Device gesprochen: Sind hier die NVME als Cache gemeint, oder ist das linuxseitig was anderes? Wenn das NVME Cache ist, bringt uns das eigentlich wieder zu dem Punkt, dass der Synology Cache mehr Risiko wie Nutzen bringt, oder?
Ja, ich vermute auch, dass da noch ein Fehler im BTRFS ist.
Aber ich krieg kein btrfs check zum laufen, da nach dem Beenden aller Spaces kein Mountpoint mehr da ist.
Die wichtigsten Daten sind alle durch rotierendes, externes Backup gesichert.
Aber: Bevor ich kein volles (!) Backup habe, will ich nicht weitermachen.
Die ca. 8 TB an "sonstigen Daten" möchte ich nicht einfach so aufgeben und hoffe auf eine Reparatur des Volumes.
Aktuell warte ich auf das NEUE Laufwerk für eine Vollsicherung, nachdem das letzte "neu" aber zerstört/defekt ankam.
Murphy lässt auch hier grüßen..
Heute Abend werde ich zunächst den Syno-Support einschalten.
Mal sehn.
Der Device-Mapper (/dev/mapper/...) ist m.W. nochmal eine Ebene oberhalb des LVM. Tipp mal "mount" ein. Da siehst du, das auch der Container Manager den nutzt, um die Shares nochmal in seinen Bereich einzubinden. Und für Cache setzt Synology ihn wohl auch ein, selbst wenn man keinen nutzt. Auf meiner alten DS415+ heißen die Volume-Devices auch schon cachdev-irgendwas.
Ich verstehe die Zusammenhänge halt gerne.
Echt? Meine letzten Versuche endetet immer mit "Fehler, ist noch gemontet". Muss ich nochmal probieren, wenn ich in knapp 3 Wochen wieder zu Hause bin.
Entschuldigt bitte meine vielen Tippfehler in der Zeit, hab halt dicke Finger auf dem kleinen Handy
Ich habe es zumindest so in Erinnerung. Kann aber auch sein, dass ich mich irre. Will ich nicht ausschließen. Werde bei Gelegenheit das Ganze nochmals verifizieren.
Edit: Es ist so, wie ich es oben bei den Befehlen geschrieben habe und der BTRFS Check Scrub des Volume findet gemountet statt. Anbei der Beleg dazu.
Wir müssen aufpassen, dass wir vom gleichen Thema sprechen. Ich rede vom Scrub und @Benares vom Check.
Edit: btrfs check geht tatsächlich nur bei nicht gemountetem Filesystem:
Und bei nicht gemountetem Filesystem findet er keine Mount-Punkte, die untersucht werden können - irgendwie logisch.
Auch ein "btrfs check /dev/sda" kann gar nicht erst ausgeführt werden.
"............. was nach dem Stop der Spaces noch unter /dev/vg-irgendwas zu finden ist ...."
Sceenshot von #43 in der Mitte zeigte das es bereits:
nix!
Na sowas!
Habe vorgestern ein Ticket bei Synology eröffnet, woraufhin mir eine KI die erste Antwort gesendet hat.
In dieser Antwort war ein Hinweis auf eine "Reparaturoption" im Speichermanager, die ich offensichtlich übersehen hatte:
Das wollte ich Euch natürlich nicht vorenthalten.
Aktuell versuche ich mit FileStation meine Daten auf eine externe 12TB zu sichern.
Versuch 4 läuft gerade. Drei mal wurde die externe HDD zuvor ebenfalls "schreibgeschützt" und die DS war nicht mehr erreichbar. Mmmmmmh..
Update:
Bald ist alles gesichert dank ssh und dem Midnight Commander.
Wie ist es denn da mit Konfigurationsdaten, die NICHT durch Hyperbackup gesichert werden?
Zum Beispiel von Paketen wie syncthing und tvheadend, die aus der Community-Quelle installiert wurden.
Wenn ich /volume2/@appdata betrachte, sehe dort u. a. die config.xml von Syncthing.
Meint ihr es reicht, diese Daten zu sichern, um z. B. ein tvheadend später schneller wieder ans Laufen zu kriegen?