# Verwerfen und aufräumen ## Verwerfen Taste ++x++ in der Übersicht oder in der Detailansicht: ![Sicherheitsabfrage vor dem Verwerfen](../bilder/recovery-verwerfen.svg) Oder auf der Kommandozeile: ```bash pvesnap-recovery destroy 9101 pvesnap-recovery destroy 9101 -y # ohne Rückfrage ``` `destroy` räumt vollständig auf:
**1.** Maschine stoppen **2.** Gast samt aller Klone entfernen **3.** Austauschlaufwerke freigeben (der **Inhalt bleibt** — sie gehören zu keiner Maschine) **4.** Den **Schutz der Quell-Snapshots wieder aufheben** **5.** Eintrag aus der Merkliste nehmen
--- ### Schritt 4 ist der wichtige !!! info "Warum der Snapshot-Schutz wieder weg muss" Ceph verlangt für einen Klon, dass der Quell-Snapshot geschützt ist (`rbd snap protect`), und Proxmox setzt das beim Klonen selbst. Bliebe der Schutz stehen, könnte die [Vorhaltezeit](../sichern/vorhaltezeit.md) diesen Snapshot später nicht mehr löschen — im Protokoll stünde dann immer wieder: ``` snapshot is protected ``` Solange eine Wiederherstellung existiert, ist ihr Quell-Snapshot also **bewusst** unlöschbar. Danach nicht mehr. --- ### Was `destroy` nicht anfasst !!! success "Nur Maschinen mit dem Tag `pvesnap-recovery`" Eine von Hand angelegte VM lässt sich damit nicht versehentlich löschen — auch dann nicht, wenn sie zufällig eine VMID hat, die einmal einer Wiederherstellung gehörte. **Austauschlaufwerke bleiben.** Sie gehören zu keiner Maschine; ihr Inhalt überlebt jede Wiederherstellung. Sie werden nur wieder als `frei` markiert. **Das Original bleibt.** Selbstverständlich — `destroy` fasst ausschließlich die Wiederherstellung an. --- ## `cleanup` Wird eine Wiederherstellung in der **Proxmox-Oberfläche** entfernt statt mit `destroy`, bleibt etwas liegen. Je nachdem, wie gründlich Proxmox dabei war, zwei verschiedene Dinge — deshalb sucht `cleanup` in **zwei Durchgängen**. 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 pvesnap-recovery cleanup --all # auch Datenträger ohne Elternteil pvesnap-recovery cleanup -y # ohne Rückfrage ``` --- ### Durchgang 1: Datenträger ohne Gast Gesucht wird nach Datenträgern der Form `vm--disk-N`, zu deren VMID es **keine Konfigurationsdatei** unter `/etc/pve/nodes/*/` mehr gibt. !!! info "Bewusst nicht über `/cluster/resources`" Ein Gast auf einem abgemeldeten Node taucht dort unter Umständen nicht auf — und dann würden die Platten einer **lebenden** Maschine als verwaist gelten. Die Konfigurationsdateien im Cluster-Dateisystem sind die verlässlichere Quelle. 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. --- ## Aufräumen prüfen ```bash pvesnap-recovery list # sind noch welche eingetragen? qm list | grep -i recovery # laufen noch welche? rbd -p ls | grep -E 'vm-9[0-9]{3}-' # liegen noch Klone herum? rbd -p snap ls vm-101-disk-0 # steht noch ein Schutz? ``` Bei der letzten Ausgabe steht in der Spalte `PROTECTED` ein `yes`, solange ein Snapshot geschützt ist. Ohne zugehörigen Klon ist das ein Fall für `cleanup`. --- ## Vor der Deinstallation `uninstall.sh` warnt, wenn noch Wiederherstellungen offen sind. Der Grund ist derselbe: !!! warning "Erst verwerfen, dann deinstallieren" Nach dem Entfernen von pvesnap gibt es kein `destroy` und kein `cleanup` mehr. Die Klone müsste man dann von Hand aufspüren, und den Snapshot-Schutz von Hand lösen: ```bash rbd -p snap unprotect vm-101-disk-0@auto-stuendlich-20260809-100000 ``` Mit Werkzeug ist das ein Tastendruck. Ohne eine Stunde Sucherei.