Explorer: Transfer-Laufwerke auf F2; cleanup findet verwaiste Snapshot-Sperren

Zwei Luecken, die seit dem Umbau offenstanden.

1. Transfer-Laufwerke waren aus dem Explorer nicht erreichbar

F2 zeigte nur die Dateisysteme des Snapshots. Jetzt stehen die
Transfer-Laufwerke in derselben Liste - aus Sicht des Bedieners ist es
dieselbe Frage ("wo soll ich hinschauen?"), und der Weg ueber
pvesnap-recovery entfaellt.

Das gewaehlte Laufwerk landet im rechten Fenster, links bleibt der
Snapshot. Damit laesst sich direkt aus einem Snapshot auf das
Austauschmedium kopieren, das anschliessend in die wiederhergestellte
Maschine wandert - ohne Zwischenlager auf dem Host.

Ausgehaengt wird beim Verlassen, und zwar nur, was wir selbst eingehaengt
haben: ein Laufwerk, das schon vorher am Host hing, gehoert jemand
anderem. Das finally faengt auch Absturz und Strg-C ab - bliebe es
eingehaengt, gaelte es spaeter als belegt.

2. cleanup fand geschuetzte Snapshots ohne Klon nicht

Loescht jemand eine Wiederherstellung in der Proxmox-Oberflaeche, raeumt
Proxmox den Klon durchaus mit ab - aber nicht den Schutz seines
Quell-Snapshots (rbd snap protect, den setzt es beim Klonen selbst).
Zurueck bleibt ein geschuetzter Snapshot ohne Klon: die Vorhaltezeit
scheitert an ihm jede Nacht mit "snapshot is protected", und
find_orphans() findet prinzipiell nichts, weil es den Datentraeger, nach
dem es sucht, wirklich nicht mehr gibt. Dasselbe entsteht nach einem von
Hand ausgefuehrten rbd flatten.

find_stale_protections() sucht deshalb direkt nach der Ursache: jeder
geschuetzte Snapshot, an dem kein Klon haengt. Ein solcher Schutz hat
keinen Zweck - er existiert einzig dafuer, dass ein Klon seine Grundlage
behaelt. Geloest wird nur der Schutz, geloescht wird nichts. Vor jedem
Loesen wird ein zweites Mal nachgesehen, ob inzwischen doch ein Klon
daran haengt.

cleanup laeuft damit in zwei Durchgaengen und liegt neu auch in der
Oberflaeche auf Taste c - man sucht sonst lange nach einem Befehl, den
man nur im Notfall braucht.

Getestet gegen die Kulisse der Handbuch-Werkstatt: die rbd-Attrappe
kennt jetzt snap ls und children und enthaelt beide Zustaende
nebeneinander - ein geschuetzter Snapshot mit Klon (muss in Ruhe
gelassen werden) und einer ohne (muss gefunden werden).

Handbuch und README nachgezogen, zwei Bildschirmfotos dazu.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

handbuch/docs/wiederherstellen/verwerfen.md

@@ -71,11 +71,14 @@ Wiederherstellung an.
 ## `cleanup`
 
 Wird eine Wiederherstellung in der **Proxmox-Oberfläche** entfernt statt mit
-`destroy`, bleibt etwas liegen:
+`destroy`, bleibt etwas liegen. Je nachdem, wie gründlich Proxmox dabei war,
+zwei verschiedene Dinge — deshalb sucht `cleanup` in **zwei Durchgängen**.
 
-* der Klon selbst kann übrigbleiben
-* der Quell-Snapshot bleibt **geschützt** — die Vorhaltezeit scheitert dann
-  dauerhaft
+Taste ++c++ in der Übersicht:
+
+![Der Aufräum-Bildschirm](../bilder/recovery-aufraeumen.svg)
+
+Oder auf der Kommandozeile:
 
 ```bash
 pvesnap-recovery cleanup          # zeigt Gefundenes, fragt, räumt auf
@@ -83,10 +86,12 @@ pvesnap-recovery cleanup --all    # auch Datenträger ohne Elternteil
 pvesnap-recovery cleanup -y       # ohne Rückfrage
 ```
 
-### Wonach gesucht wird
+---
 
-Nach Datenträgern der Form `vm-<id>-disk-N`, zu deren VMID es **keine
-Konfigurationsdatei** unter `/etc/pve/nodes/*/` mehr gibt.
+### Durchgang 1: Datenträger ohne Gast
+
+Gesucht wird nach Datenträgern der Form `vm-<id>-disk-N`, zu deren VMID es
+**keine Konfigurationsdatei** unter `/etc/pve/nodes/*/` mehr gibt.
 
 !!! info "Bewusst nicht über `/cluster/resources`"
 
@@ -104,10 +109,52 @@ Zwei weitere Vorsichtsmaßnahmen:
 | **Ohne Elternteil** wird nichts von selbst entfernt | dafür braucht es `--all` |
 | **Der Schutz eines Snapshots wird nur gelöst**, wenn wirklich kein Klon mehr daran hängt | sonst würde ein noch lebender Klon seine Grundlage verlieren |
 
+---
+
+### Durchgang 2: Geschützte Snapshots ohne Klon
+
+Der Fall, den der erste Durchgang **prinzipiell nicht finden kann**.
+
+Löscht jemand die Wiederherstellung in der Proxmox-Oberfläche, räumt Proxmox
+den Klon durchaus mit ab — aber nicht den Schutz seines Quell-Snapshots. Den
+setzt es beim Klonen selbst (`rbd snap protect`, RBD verlangt ihn), und niemand
+nimmt ihn wieder weg.
+
+Zurück bleibt ein geschützter Snapshot ohne Klon:
+
+!!! danger "Und danach scheitert die Vorhaltezeit für immer"
+
+    ```
+    TASK ERROR: rbd snapshot 'auto-taeglich-20260809-023000' is protected from removal
+    ```
+
+    Jede Nacht aufs Neue, an derselben Stelle. Nach einem liegengebliebenen
+    Datenträger sucht man dabei vergeblich — der ist ja tatsächlich weg.
+
+Derselbe Zustand entsteht nach einem von Hand ausgeführten `rbd flatten`: Der
+Klon hängt danach an nichts mehr, der Schutz steht aber weiter.
+
+Gesucht wird deshalb direkt nach der Ursache: **jeder geschützte Snapshot, an
+dem kein Klon hängt.** Ein solcher Schutz hat keinen Zweck — er existiert
+einzig dafür, dass ein Klon seine Grundlage behält.
+
+!!! success "Gelöst wird nur der Schutz, gelöscht wird nichts"
+
+    Die Snapshots bleiben stehen. Danach darf die Vorhaltezeit sie wieder
+    wegräumen, wenn sie alt genug sind — mehr passiert nicht.
+
+    Vor jedem Lösen wird ein zweites Mal nachgesehen, ob inzwischen doch ein
+    Klon daran hängt. Zwischen Suchen und Aufräumen kann jemand eine neue
+    Wiederherstellung angelegt haben; der bekommt man nicht die Grundlage unter
+    den Füßen weg.
+
+---
+
 ### Wann man es braucht
 
 * Jemand hat eine Wiederherstellung in der Weboberfläche gelöscht
 * Ein `destroy` ist mittendrin abgebrochen (Host neu gestartet, Netz weg)
+* Es wurde von Hand geflattet
 * Im Protokoll des Dienstes taucht wiederholt `snapshot is protected` auf
 
 Der letzte Fall ist der häufigste — und der, den man sonst lange sucht.