BTRFS-Fehler schreibt Logs voll - Synology nicht mehr erreichbar

[plang.pl]

Das könnte die Ursache sein. Einem RAID gefällt ein Stromausfall nicht sonderlich gut. Deshalb hat man eigentlich eine USV. Wobei normalerweise wäre der Fehler da meiner Ansinscht nach ein anderer. Denn die DS spannt das RAID ja nicht via btrfs auf.

 

[synfor]

Der Cache ist doch schon längst deaktiviert oder? Wieso liefert der dann jetzt noch Fehler?

 

[adahmen]

Tja - eigentlich hat das ganze Haus eine "USV" (auf Basis eines Victron Multiplus + 14,4 kWh Akku). Aber hieran musste der Elektriker arbeiten und hat dann aus versehen (denn er selber hat auch eine Synology und kennt das Problem) den Umschalter vom Akku auf Netz ausgelöst und nicht bedacht, dass dann schlagartig das Haus keinen Strom mehr hat :-( War ihm selber peinlich.

Zudem war die Synology viele Jahre hinter einer APC-USV. Aber hier hatte ich vor einigen Monaten das Problem, dass die 720+ spontan immer mal wieder einfach neu gestartet hat (ohne jegliche Hinweise im Log). Und hier wollte ich die APC ausschliessen und habe die 720+ direkt an den Strom gehängt. Ob das nun letztendlich damit zusammenhing - keine Ahnung. Aber ich hatte keinen spontanen Neustart mehr.

Kann man denn mit den Angaben der BTRFS Fehlermeldung einen Pfad ausmachen?

@Benares - Was deutet denn auf den Cache hin?

 

[Benares]

Was deutet denn auf den Cache hin?

Na ja, dass in deinen Ausgaben von #37 halt ständig cachedev_x auftaucht.
Wenn du ein Backup hast, setz die Kiste doch einfach neu auf, bevor du jetzt noch länger damit rumeierst. Dein BTRFS scheint halt einen irreparablen Schaden zu haben, was immer auch der Grund dafür war.
Solchen DSen sind manchmal doch ziemliche "Sensibelchen", trotz hochgelobten Filesystemen wie BTRFS etc. Ich kann mich nicht daran erinnern, dass mein Windows-PC durch irgendwelche Stromausfälle mal irgendwelchen Schaden genommen hätte, ganze ohne USV und Raid.

 

[adahmen]

Okay ... sind das nicht einfach nur die Namen der beiden Platten? So habe ich den Eintrag interpretiert?

Sollte ich den SSD-Cache einfach nochmal aktivieren?

 

[Benares]

Wenn du dir den Screenshot aus #1 anschaust, nach was klingt cachedev_x dann eher?
Ich weiß nicht, wie Synology den Cache einbindet, aber ich weiß, dass es nur ein Spezialfällen etwas bringt und ich das sicherlich nie nutzen werde.

 

[adahmen]

Das klingt schon sehr danach - das würde ich auch sagen.

Aber wenn ich mir die Ausgabe hier anschaue, dann macht das doch absolut keinen Sinn, oder?

sudo btrfs fi show

Label: '2021.09.24-10:26:18 v41890'  uuid: 3fd61fb7-7b0d-45d0-9439-91f7394da96e
    Total devices 1 FS bytes used 3.68TiB
    devid    1 size 5.45TiB used 3.72TiB path /dev/mapper/cachedev_0

Label: '2021.09.16-16:30:32 v41890'  uuid: 2db3f6fc-5623-47de-917d-9928693254d3
    Total devices 1 FS bytes used 2.52TiB
    devid    1 size 3.63TiB used 3.51TiB path /dev/mapper/cachedev_1

Denn hier wären dann die beiden Caches den beiden Platten zugeordnet - und das war nicht der Fall. Denn der Cache kann nur zu einem Volume angelegt werden - und bei mir war es Volume 1.
Das würde dann gegen Deine Theorie sprechen.

 

[synfor]

Du hast 2 Caches, je einen pro Volumen. Abgesehen davon, kann man seit DSM 7.1 eine SSD Cache Group für mehrere Volumen nutzen.

 

[adahmen]

Hhhmmmm, sehr seltsam - denn aktuell ist kein Cache eingerichtet und dennoch soll ich einen Cache haben?

Wie schaut der BTRFS-Befehl (sudo btrfs fi show) denn bei jemandem aus, der keinen SSD-Cache in seiner Synology hat? Kann das von Euch mal jemand posten?

 

[Benares]

Hab grad mal auf meiner DS1522+ geschaut. Ich hatte dort nie einen Cache konfiguriert.
Trotzdem heißt lt. "mount" das Device von /volume1 /dev/mapper/cachedev_1 und von /volume2 (NVME-SSD als Volume) /dev/mapper/cachedev_0. Das ist mir noch nie aufgefallen. Da hängt wohl treibertechnisch gleich die Cache-Unterstützung mit drin, auch wenn kein Cache konfiguriert ist.

{code]
root@DS1522:~# sudo btrfs fi show
Label: none uuid: 4ece7ee5-9679-4325-98a9-31dda2dbcb36
Total devices 1 FS bytes used 244.00KiB
devid 1 size 927.01GiB used 4.07GiB path /dev/mapper/cachedev_0

Label: '2022.11.21-10:13:13 v42962' uuid: 666e5098-1703-4209-a38c-5488a7cd0180
Total devices 1 FS bytes used 5.96TiB
devid 1 size 25.45TiB used 6.00TiB path /dev/mapper/cachedev_1
[/code]

 

[adahmen]

So, nochmal Update von meiner Seite.
Ich habe gestern den Speicher um 16 GB auf 18 GB wieder erhöht. Der Speicherriegel wurde erkannt und der Speichertest (diese Nacht) war erfolgreich.
Gerade eben habe ich den SSD-Cache wieder aktiviert. Auch das ohne Probleme.
Das System ist wieder rasend schnell und füllig zu bedienen.

Und: Ich habe nochmal in var/log/messages geschaut.
Die letzte BTRFS Fehlermeldung war heute so gegen 11 Uhr. Seitdem ist Ruhe - keine Fehler mehr im Log.
Es gab bisher auch zwischendurch mal einige Stunden ohne Fehlermeldung ... aber meines Wissens noch keine 8 Stunden.
Mal schauen - noch traue ich dem Braten nicht.

Sollten die Fehler bleiben, werde ich in ca. 2 Wochen wohl neu aufsetzen. Aber erstmal geht's in Urlaub

 

[maxblank]

Dann genieß den Urlaub

 

[adahmen]

So, dann melde ich mich mal wieder zurück (auch wenn der Urlaub nur 2 Wochen war).

Ich werde die Synology nun neu aufsetzen - die Frage ist aber noch wie genau

2 Effekte habe ich noch in den letzten Tagen gehabt:

1. Zum einen hat die 720+ einen spontanen Neustart hingelegt :-( das hatte ich vor einigen Monaten schonmal und damals keinen Hinweis in irgendeinem Log gefunden. Ich habe die Synology daraufhin von der USV weg direkt an den Strom gehängt (um die USV auszuschliessen). Danach war monatelang Ruhe - bis Vorgestern :-(
Kann das auch mit einem korrupten FileSystem zu tun haben?

2. Ich habe gestern ein komplettes Backup (bis auf einen Ordner, der nicht auf die USB-Platte passt) gestartet (läuft auch immer noch). Einige Stunden nach dem Starten des Backup habe ich dann eine Mail mit folgendem Inhalt bekommen:
----
Auf Laufwerk 1 von DS720+ wurde ein UNC-Fehler erkannt. Auch wenn das System jetzt ordnungsgemäß funktioniert, empfehlen wir Ihnen, Ihre Daten zu sichern, um die Datenintegrität zu gewährleisten. Gehen Sie auch zu Speicher-Manager > HDD/SSD > HDD/SSD > Integritätsstatus > S.M.A.R.T., führen Sie den Erweiterten Test aus und sehen Sie sich das Testergebnis für empfohlene Maßnahmen an.
----
Auch hier die Frage: Ist das die Folge des korrupten FileSystems oder hat die Platte nun auch ein Problem?


Aus den ganzen Gründen überlege ich nun, ob ich nicht direkt 2 neue Platten kaufen sollte um dann neu aufzusetzen.
Eine der beiden Platten ist (diejenige mit dem UNC-Fehler) ist 2 Jahre alt - die andere Platte ist (vermutlich) 7 Jahre alt.
Ist das zu empfehlen bzw. notwendig?


Auch wenn die 720+ meine fünfte oder sechste Synology ist, musste ich bisher ein laufendes System noch keinmal neu aufsetzen.
Insofern meine vierte Frage:
Spiele ich das Backup schon beim Neuaufsetzen ein oder installiere und konfigurieren ist erstmal das System neu und spiele dann das Backup über USB ein? Wird hierdurch die komplette Systemeinstellung (User, Rechte, Aufgaben, ...) sowie die Daten und Pakete übernommen?
Gibt es sonst noch einen Tipp, den ich beachten sollte, könnte?

 

[Benie]

Beim Versionierten Backup mit Hyperbackup kannst Du außer den Daten auch die Pakete mitsichern, die Konfig wird automatisch mitgesichert.

Das DSM mußt Du erstmal neu aufsetzten und Hyperbackup installieren. Dann kannst Du mit Hyperbackup das Backup inkl. Konfiguration und Pakete wiederherstellen und die DS müßte laufen wie vorher. Ggf Mußt Du das eine oder andere Paket Reparieren bzw. neu installieren.

 

[adahmen]

So, die neuen Platten (habe mich entschieden neue Platten zu kaufen) sind drin und ich spiele gerade die Sicherung zurück - das wird noch einige Stunden dauern.

Aber leider stelle ich erst gerade fest, dass meine "Docker-Welt" scheinbar nicht teil von HyperBackup ist.
Das Problem sind nicht die Daten - der Ordner ist natürlich Teil der Sicherung ... aber alle Container-Einstellungen. Das war mir leider nicht bewusst. Leider sind wirklich essenzielle Container dabei (wie Bitwarden).

Wäre es eigentlich möglich, dass ich "einfach" das System nochmal mit den alten Platten (die ich ja nur ausgebaut habe) hochfahre und die entsprechenden Container-Einstellungen sichere?
Nach der Sicherung dann wieder die neuen Platten rein und die Container-Einstellungen importiere?

 

[ctrlaltdelete]

ja, das funktioniert.

 

[adahmen]

Puhhhh .....

Muss man dabei auch irgendwas achten? Oder einfach alte Platten rein und starten?
Oder meldet sich dann der Migrations-Assistent?

 

[ctrlaltdelete]

Nein, alle HDDs rein und starten.

 

[adahmen]

Okay - krass - hätte ich nicht gedacht.
Gibt es also nichts in einem nicht-flüchtigen Speicherbereich, den ich durch den Einbau der neuen Platten und das Neuaufsetzen so verändert habe, dass es ein Starten mit den alten Platten verhindert?

Woran macht denn die Synology fest, dass der Migrationsassistent startet? Ist das dann genau umgekehrt? Ist auf den Platten gespeichert in welcher Hardware man gelaufen ist?

 

[ctrlaltdelete]

Ja, DSM läuft nur auf den HDDs.