duffyduckandClaude Opus 5
d9d9345d03
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>
194 lines
5.9 KiB
Markdown
194 lines
5.9 KiB
Markdown
# Verwerfen und aufräumen
|
|
|
|
## Verwerfen
|
|
|
|
Taste ++x++ in der Übersicht oder in der Detailansicht:
|
|
|
|
|
|
|
|
Oder auf der Kommandozeile:
|
|
|
|
```bash
|
|
pvesnap-recovery destroy 9101
|
|
pvesnap-recovery destroy 9101 -y # ohne Rückfrage
|
|
```
|
|
|
|
`destroy` räumt vollständig auf:
|
|
|
|
<div class="ablauf" markdown>
|
|
|
|
**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
|
|
|
|
</div>
|
|
|
|
---
|
|
|
|
### 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:
|
|
|
|
|
|
|
|
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-<id>-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 <pool> ls | grep -E 'vm-9[0-9]{3}-' # liegen noch Klone herum?
|
|
rbd -p <pool> 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 <pool> snap unprotect vm-101-disk-0@auto-stuendlich-20260809-100000
|
|
```
|
|
|
|
Mit Werkzeug ist das ein Tastendruck. Ohne eine Stunde Sucherei.
|