Merkwürdiges Problme: Snapper führt drei "writable copies" - keine davon lässt sich entfernen!

Deutsch (German) Installation/Administration
1

Hallo!

Leider hatte ich das Problem, dass Snapper alte Snapshots nach den Regeln aus dem “root”-Profil anscheinend eine Weile einfach nicht mehr regelmäßig gelöscht hat.

Da es mittlerweile fast tausend Snapshots waren, habe ich einen Aktuellen erzeugt und darauf nach Reboot einen Rollback als Ausgangspunkt gemacht.

Danach habe ich über Snapper (!delete von-bis") alle ältere Snapshots gelöscht. Hat zwar eine Weile gedauert, aber ok… _OO_/

Dabei ließen sich zwei Snapshots leider nicht entfernen - sie sind beide als “writable” gekennzeichnet und schon ein bzw. zwei Jahre alt.

Hier die Snapshot Liste:

# sudo snapper list: 

# │ Typ    │ Vorher # │ Datum                        │ Benutzer │ Bereinigen │ Beschreibung            │ Benutzerdaten
───────┼────────┼──────────┼──────────────────────────────┼──────────┼────────────┼─────────────────────────┼──────────────
    0  │ single │          │                              │ root     │            │ current                 │
11624  │ single │          │ Sa 30 Mär 2024 03:53:09 CET  │ root     │ number     │ writable copy of #11620 │
20240  │ single │          │ Do 24 Apr 2025 19:20:50 CEST │ root     │ number     │ writable copy of #20235 │
28270  │ single │          │ Mi 18 Mär 2026 16:31:48 CET  │ root     │            │ Reparatur               │
28271  │ post   │    28269 │ Mi 18 Mär 2026 16:32:41 CET  │ root     │ number     │                         │
28273* │ single │          │ Mi 18 Mär 2026 16:37:40 CET  │ root     │            │ writable copy of #28270 │
28274  │ single │          │ Mi 18 Mär 2026 17:00:01 CET  │ root     │ timeline   │ timeline                │
28275  │ pre    │          │ Mi 18 Mär 2026 17:10:36 CET  │ root     │ number     │ yast snapper            │
28276  │ post   │    28275 │ Mi 18 Mär 2026 17:11:44 CET  │ root     │ number     │                         │
28277  │ pre    │          │ Mi 18 Mär 2026 17:42:43 CET  │ root     │ number     │ zypp(zypper)            │ important=no
28278  │ post   │    28277 │ Mi 18 Mär 2026 17:42:43 CET  │ root     │ number     │                         │ important=no

Was lassen sich die beiden alten Snapshots denn nun entfernen?

Auch der Versuch mit der Yast-GUI ergibt:

“Löschen des Schnappschusses ist fehlgeschlagen”:
org.freedesktop.DBus.Error.Failed; caused by 3 sender=:1.237 -> dest=:1.238 serial=17 reply_serial=14 path=; interface=; member= error_name=error.delete_snapshot_failed

Weiß jemand weiter und kann helfen?

Danke!
jhhh

2

manuell , ein administrativer Konflikt zwischen der Snapper-Verwaltung und dem aktuellen Mount-Status der Btrfs-Subvolumes. Durch manuelles Löschen der Subvolumes über die btrfs-Befehlszeile lässt sich die Blockade fast immer lösen:

zur Identifikation

sudo btrfs subvolume get-default /

auch

sudo btrfs subvolume list /

manuell löschen:

sudo btrfs subvolume delete -c  /.snapshots/NUMMER_DES_SNAPSHOTS/snapshot

verzeichnis löschen

sudo rm -rf /.snapshots/NUMMER_DES_SNAPSHOTS

hierbei sicherstellen dass zwischen / und . kein Leerzeichen ist…

3

Danke!

Das habe ich gemacht und es hat auch funktioniert.

Und dann schmerzlich herausgefunden, wie das Problem entstanden war und wieso ich mehrere “writeable” aktivierte Snapshots vorhanden waren. Der Fehler lässt sich in Zukunft leicht vermeiden:

Meine externe Festplatte für Backups wurde beschädigt und ich habe für die Speicherung der Daten aus der Datenrettung auf die Schnelle einen Ordner “/Datenrettung” angelegt, weil ich auf der Root-Partition am meisten Platz hatte. Außerdem brauchte ich sowieso Root-Rechte im Ordner…

Tage später habe ich aus diesem Ordner ein BTRFS Subvolume “/Arbeitsordner” gemacht und den dann erst mal als Ersatz für die dynamische Datenablage anstelle der externen Festplatte verwendet.
Dieses Subvolume wurde natürlich in allen folgenden Snapshots ausgeschlossen.

Ein paar Wochen später musste ich einen Reroll nachdem ich daran gescheitert war, ROCM in Tumbleweed zum Laufen zu kriegen.

Nur lagen die aktiven genutzten Daten aus dem Arbeitsordner jetzt nicht mehr im aktuellen Snapshot (dem nach dem Reroll!), sondern in dem älteren Snapshot, der die Daten aus dem Subvolume bereitstellt.

So wurden zwei Snapshots aktiv genutzt. Die Daten aus dem Arbeitsordner Subvolume, sind beim Löschen aller alten Snaphostes jetzt natürlich ebenfalls entfernt worden!

Zum Glück habe ich Backups - also kein ernstes Problem.

Meine Lehre daraus:

Keine zusätzlichen Arbeitsordner in “/” ablegen, nie die Backups aller Subvolumes unter “/” nie vernachlässigen und für Arbeits-Ordner in denen viele unterschiedliche Daten abgelegt, aber dann zum Teil auch wieder gelöscht werden, ganz auf Btrfs (oder wenigstens auf Snapshots) verzichten!

Lösung war natürlich, einfach die Root-Partiton um zwei Drittel zu verkleinern, im freien Bereich eine ext4 Partition zu erstellen und diese in der Zukunft als dynamischen Arbeits-Ordner zu verwenden!

Nun läuft es glatt!

Cheers,
jhhh