Unveränderliche Snappshots Löschen

[Toby-ch]

Hallo zusammen

Ich habe eine RS1221+ mit Insgesamt 3 Volumen
Volumen 1 ( 4x16T HDD)
Volumen 2 (3x8TB SSD)
Volumen 3 (1x1TB SSD)

Nun möchte ich um Volumen 2 zu entfernen die Daten auf die HDD verschieben. leider erhalte ich immer die Fehlermeldung:

Gibt es irgend einen weg via CLI diese Unveränderlichen Snappshots zu löschen ?
Weil ich muss dies SSDs in ein anderes Nas umbauen und die Daten müssen weg.

Besten Dank für eure Hillfe

 

[Fusion]

Immutable snapshots ausschalten, Zeit abwarten, oder...

Daten nur kopieren und nicht verschieben, oder...

Immutable snapshots direkt deaktivieren und dann Ordner verschieben.
In den Metadaten 'worm_lock=true' auf 'worm_lock=false' ändern.
Bsp. Schnappschüsse
/volume1/@sharesnap/@homes@
Metadaten dazu
/volume1/@sharesnap/@homes@.meta

Eventuell muss man die Read Only Schnappschüsse noch schreibbar schalten
'btrfs property set -ts GMT-07-2024.08.14-04.00.01 ro false'


Ref, freigegebene Ordner löschen
synoshare --del TRUE <share-name>

 

[synfor]

Statt des gemeinsamen Ordners nur deren Daten verschieben. Alternativ die Daten kopieren. Danach die RS herunterfahren, die SSDs ausbauen und extern löschen.

 

[DaveR]

Schnappschüsse
/volume1/@sharesnap/@homes@
Metadaten dazu
/volume1/@sharesnap/@homes@.meta

Is your homes folder encrypted or volume1 encrypted?

Mine are not encrypted and I have:

Schnappschüsse
/volume1/@sharesnap/homes

Metadaten dazu
/volume1/@sharesnap/@homes.meta

 

[Fusion]

Yes, you are correct. The example was from the only system where I had homes encrypted.
For non encrypted shares there is only the leading @ in the names.

 

[Toby-ch]

Statt des gemeinsamen Ordners nur deren Daten verschieben. Alternativ die Daten kopieren. Danach die RS herunterfahren, die SSDs ausbauen und extern löschen.

Ja auch eine Möglichkeit.
Mein erster Gedanke war Ordner auf der Volumen 2 belassen SSD raus und direkt in die Neue SYNO rein aber ich bezweifle das dies gut geht ?

 

[Toby-ch]

Immutable snapshots direkt deaktivieren und dann Ordner verschieben.
In den Metadaten 'worm_lock=true' auf 'worm_lock=false' ändern.

Die Volume2/@sharesnap/@Ablage.meta habe ich bearbeitet die Snapshot sind nun nicht mehr gelockt.

Aber löschen geht jedenfalls so nicht:

Da erscheint dann:

Den comand:
'btrfs property set -ts GMT-07-2024.08.14-04.00.01 ro false' gibt es nicht oder muss dies als Parameter in die .meta Datei ?

Jedoch konnte der Verschiebe Vorgang gestartet werden

 

[Fusion]

Der Befehl zum Aufheben von read-only muss natürlich an deine Snapshotnamen angepasst werden, also den Zeitstempel.
'btrfs property set -ts "Name" ro false'

 

[TheImproof]

Leider funktioniert diese Lösung nicht mehr

Die Metadaten ändern auf worm_lock=false funktioniert zwar, der Snapshot lässt sich aber dennoch nicht löschen. Klar, weil die Schnappschüsse Read Only sind, aber btrfs set property führt (auch mit root) nur zu einer Fehlermeldung:

'btrfs property set -ts /volume1/\@sharesnap/docker/GMT+02-2025.05.07-00.00.02/ ro false'
ERROR: failed to set flags for /volume1/@sharesnap/docker/GMT+02-2025.05.07-00.00.02/: Operation not permitted

Ich hab auch mal versucht in den Metadaten den Timestamp worm_lock_end zu ändern, z.B. auf 1 min in der Zukunft. Läuft die Zeit dann ab, wird auch automatisch worm_lock auf false gesetzt und im DSM sieht es so aus, als wäre der Snapshot nicht mehr gesperrt. Löschen geht aber trotzdem nicht, da der Ordner auf Read Only bleibt.

Kurios: Startet man das NAS neu, sind alle Änderungen an den Metadaten wieder zurückgesetzt, egal ob nur worm_lock geändert wurde oder auch worm_lock_end und dieser Timestamp dann tatsächlich abgelaufen ist. Also wird das wohl noch irgendwo anders zusätzlich gespeichert und darauf zurückgegriffen.

 

[geimist]

Auch wenn es im gewünschten Szenario verständlicherweise unschön zu ertragen ist: Ich finde es beruhigend, dass man es nicht so leicht umgehen kann.

 

[TheImproof]

Da stimm ich dir voll und ganz zu! Wird wahrscheinlich irgendwo direkt im Kernel abgefangen, dass man da selbst mit root nichts ändern kann.

Ich bin jedenfalls froh, dass ich nur 7 Tage eingestellt hatte, das lässt sich abwarten

 

[NSFH]

Hat schon mal jemand versucht einfach der Syno ein Datum in der Zukunft zu geben (NTP aus oder keine Internetverbindung!)?

 

[TheImproof]

Das wird nicht funktionieren, wie hier beschrieben: https://kb.synology.com/de-de/DSM/tutorial/WriteOnce_retention_period_longer_than_specified