Volume schreibgeschützt, HDDs aber normal - Datenrettung wie?

[maxblank]

Ich habe allerlei Tests durchgeführt und sehr viele Fehlermeldungen im Speicher-Manager erhalten, die ich im Ernstfall nie sehen möchte.

Allerdings ist es mir nicht gelungen den Fehlerstatus von @knilch mit "Volume ist schreibgeschützt" zu provozieren.

Ich würde folgendes Vorgehen nach den Tests vorschlagen.

Folgendes notieren:
df -h
mount | grep volume2

Danach folgende Befehle in der Console als Root ausführen:
btrfs scrub start /volume2
btrfs scrub status /volume2 (Status prüfen und Beendigung abwarten)

synospace --stop-all-spaces (Status im Speicher-Manager prüfen und notieren, falls anders lautend)
synospace --start-all-spaces (Status im Speicher-Manager nochmals prüfen)

 

[geheim5000]

War/Ist ein Cache Laufwerk vorhanden?
Ich hatte exakt den gleichen Fehler durch ein abgestürztes Cache Laufwerk.

hatte damals auch paar Sachen probiert, und letztendlich neu aufgesetzt (Dank Backup wars nur zeit intensiv)

 

[knilch]

Nein, nein! Es ist an MIR, EUCH zu danken!
Also: DANKE!

Nun zu "den Befehlen", und deren Auswirkung.
Ich habe davor das System neu gestartet.





/dev/mapper/cachedev_0 wird als mountpoint ausgegeben, ist nach synospace --stop-all-services jedoch umounted (?).

 

[Benares]

Probier mal in diesem Zustand ein

btrfs check /dev/mapper/cachedev_0

gefolgt von

btrfs check --repair /dev/mapper/cachedev_0

wenn ersteres einen Fehler bringt.

Edit: wenn letzteres klappt, dann

synospace --start-all-spaces

und schauen, was passiert.

Sorry, ich bin jetzt erstmal 3 Wochen weg, Südindien wartet. Helft ihm bitte soweit es geht.

 

[knilch]

Scheint also tatsächlich nicht mountet.

 

[Benares]

Mist. Was gibt's denn alles unter /dev/mapper? (ls -als /dev/mapper)

Bei mir gibt's da

root@DS1522:~# ls -als /dev/mapper
total 0
0 drwxr-xr-x  2 root root      180 Feb  4 12:36 .
0 drwxr-xr-x 12 root root    14160 Feb  4 12:38 ..
0 brw-------  1 root root 248,   4 Feb  4 12:36 cachedev_0
0 brw-------  1 root root 248,   5 Feb  4 12:36 cachedev_1
0 crw-------  1 root root  10, 236 Feb  4 12:36 control
0 brw-------  1 root root 248,   2 Feb  4 12:36 vg1-syno_vg_reserved_area
0 brw-------  1 root root 248,   3 Feb  4 12:36 vg1-volume_1
0 brw-------  1 root root 248,   0 Feb  4 12:36 vg2-syno_vg_reserved_area
0 brw-------  1 root root 248,   1 Feb  4 12:36 vg2-volume_2

 

[knilch]

Habe neu gestartet, Volume 2 war also wieder da aber RO.
Dann....

 

[Benares]

Boah, da bin jetzt auch überfragt, warum das verschwindet.
Sorry muss jetzt ins Bett, muss morgen früh raus. Die Kollegen werden dir sicher weiterhelfen.

 

[knilch]

Vielen Dank für Deine Mühen !


Bestimmt haben die anderen noch Ideen.
Aber alles zu seiner Zeit. Muss jetzt auch in die Heia.

 

[maxblank]

synospace --stop-all-services jedoch umounted (?).

Sinn und Zweck. Was hat dann der nächste Befehl gebracht? Was stand im Speicher-Manager?

 

[knilch]

Sinn und Zweck. Was hat dann der nächste Befehl gebracht? Was stand im Speicher-Manager?

OK.
Also nach "synospace --stop-all-spaces" hier der Speicher Manager:


Der Link "Onlline zusammenstellen" (blau) führt zu:

 

[Ronny1978]

Viel Erfolg. Hoffentlich klappt es.

 

[maxblank]

Genau und jetzt übernehmen klicken.
Ergebnis sollte dann wenige Sekunden später zu sehen sein.

 

[knilch]

YES! Das ist schon mal sehr hübsch


OK, Volume 2 ist wieder da und aktuell nicht read only.

ABER:
Ursache für RO ist weiterhin nicht klar.
Zustand des Volumes für mich unsicher.

"btrfs check" war ja bisher nicht möglich, da volume entweder noch mounted oder nach "synospace --stop-all-spaces" für btrfs check das ziel "/dev/mapper/cachedev_0" nicht mehr vorhanden.
data scrubbing ist aktuell aus. könnt ich manuell auslösen, um zu schauen, ob das volume wieder auf RO springt.

Was denkt ihr, wie ich weiter machen sollte?
Im Moment ist mir etwas mulmig, da Schreibzugriffe nicht ausgeschlossen sind und das Volume ja noch beschädigt sein könnte.

 

[maxblank]

Zuerst ein Backup mit Hyper Backup auf externen Datenträger erstellen, automatisieren und in engen Zeitabständen laufen lassen.
Wenn das erstellt wurde, über den Speicher-Manager die Datenbereinigung durchführen.

Deine Platten sind, bis auf eine, zwischen 5,5 und 6,5 Jahre bereits gelaufen. Diese 3 Platten würde ich erneuern und die alten Platten rotierend in externen Gehäusen als Backup nutzen. Du hast in deinem Fall gesehen, wie wichtig das ist und hätte dir einiges erleichtert.

Der Befehl „synospace --start-all-spaces“ hätte übrigens über die Console nichts anderes gemacht wie das „Online zusammenstellen“ per GUI, zumindest war das in meinen Tests der Fall.

 

[knilch]

Lieben Dank an Euch alle für die großartige Hilfe!!

Hyper Backup war noch down, so wie viele andere Services auch:


Klick ich was, muss ich erst die Syno Store Nutzungsbedingungen akzeptieren.
OK... mal für Hyper Backup probiert: funzt.

Plan ist nun:
Vollbackup, dann Scrubbing, bei Erfolg ein Neustart, bei dem sicherlich alle Services starten werden und dann wie empfohlen weiter mit HDD-Tausch.
Wollte eben loslegen mit der frischen 16 TB Ironwolf aber die kam defekt an. Wieder 2 Tage länger Ausfall. Wunderbar! :-/

 

[maxblank]

Falls du noch zwei weitere 16 TB Ironwolf Pro suchst, ich hätte noch 2 Stück für einen fairen Kurs mit gültiger Gewährleistung abzugeben.
Bei Interesse schreib mir eine PM.

 

[knilch]

00:00:07 Volume [2] has become read-only.

So ein Mist!
Was ist um / kurz vor 00:00:07 ??
Vor diesem Eintrag ist zumindest im Protokoll Center nichts spannendes zu sehen.

Naja, ich muss jetzt eh auf den Ersatz für die 16TB abwarten, damit ich die Daten dann mit Hyper Backup komplett sichern kann. Hoffentlich...

 

[maxblank]

Ich würde da den Synology Support zusätzlich einschalten.

 

[Benares]

Mmh, könnte sein, dass der Speichpool durch die bisherigen Maßnahmen zwar neu zusammengestellt und ein Fehler im Filesytem dadurch vorerst nur quittiert, aber nicht behoben wurde? Und nun wurde er halt wieder bemerkt?
Ich würde es nochmal mit einem Check/Repair versuch bei gestoppten Space. Man müsste halt noch das richtige Device dafür finden. Vermutlich wird nur das Device-Mapping beendet und man müsste eins hoch auf Ebene des LVM (/dev/vg...)