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>
6.7 KiB
Wiederherstellen
Manchmal reicht es nicht, einzelne Dateien herauszukopieren.
Eine Datenbank liegt im Snapshot als Haufen halbfertiger Dateien — brauchbar wird sie erst, wenn der Datenbankserver läuft und selbst einen Dump schreibt. Eine Warenwirtschaft prüft beim Start ihre Lizenz. Ein Verzeichnisdienst ist ohne laufende Maschine überhaupt nicht zu befragen.
pvesnap-recovery startet den Snapshot deshalb als eigenständige Maschine —
ohne das Original anzufassen.
Zwei Betriebsarten
| live | recovery | |
|---|---|---|
| Netzwerk | keins | volles Netz |
| Identität | bleibt (UUID, MACs, Hostname) | bleibt (UUID, MACs, Hostname) |
| Wofür | hineinschauen, Dump ziehen, Daten holen | die Maschine wirklich wieder in Betrieb nehmen |
| Risiko | keins — sie kann nichts erreichen | hoch, solange das Original läuft |
Der Unterschied ist ausschließlich das Netzwerk — und die Zahl der Sicherheitsabfragen. An den Datenträgern ändert der Modus nichts; beide klonen gleich.
live ist der Normalfall. Die Maschine ist vollständig abgeschottet: Sie kann
nichts erreichen und niemanden stören, auch wenn sie dieselbe IP-Adresse
konfiguriert hat wie das noch laufende Original. Daten kommen über ein
Austauschlaufwerk heraus.
recovery ist der Ernstfall — und gefährlich, solange das Original läuft.
Details unter Mit Netzwerk.
Warum das schnell geht
Die Datenträger werden nicht kopiert, sondern geklont. Auf Ceph/RBD, ZFS und LVM-thin ist das ein Copy-on-Write-Klon: fertig in Sekunden, egal wie groß die Platte ist, und anfangs ohne zusätzlichen Platzbedarf.
Klon ~1 s egal ob 32 GB oder 2 TB
Start Sekunden mit RAM-Zustand sofort im laufenden Zustand
Arbeiten ab jetzt voll beschreibbar
Eine 32-GB-Platte war im Test nach 0,8 Sekunden geklont.
Dafür wird PVE::Storage::vdisk_clone benutzt — dieselbe Funktion, die auch
Proxmox selbst für Klone verwendet, samt Cluster-Sperre auf dem Storage. Es
wird nichts nachgebaut, was Proxmox schon kann.
!!! info "Kein „Live-Restore"— besser"
Beim Live-Restore eines Backup-Servers liegt die Sicherung auf einem anderen
Medium: Die VM startet zwar sofort, holt die Blöcke aber im Hintergrund
übers Netz nach und läuft bis dahin gebremst.
Hier wird **gar nichts nachgeladen**. Der Klon liegt im selben Pool und ist
aus Sicht des Gastes von Sekunde eins an vollständig — bei voller
Geschwindigkeit. Bei einer 2-TB-VM wird also nicht stundenlang kopiert und
dann gestartet; gearbeitet wird ab der ersten Sekunde.
!!! warning "Nicht auf jedem Storage"
Auf Datei-Storages (`dir`, `nfs`, `cifs`) geht das nicht — aus einem
qcow2-internen Snapshot lässt sich kein Klon ziehen. Für diese Storages
bleibt der Weg über den [Explorer](../holen/explorer.md).
Was welches Storage kann, steht unter
[Speicherarten](../nachschlagen/speicher.md).
Der Arbeitsspeicher kommt mit
Enthält der Snapshot den Arbeitsspeicher (vmstate = yes in der Gruppe), wird
er mitgenommen. Die Maschine bootet dann nicht, sondern läuft genau dort
weiter, wo sie beim Snapshot stand:
- kein Crash-Recovery, kein
fsck, kein Journal-Rollback - Datenbanken sind bereits offen und konsistent
- die Uhr im Gast steht auf dem Snapshot-Zeitpunkt
Im Test war das gut zu sehen: Die Konsole zeigte 10:38 — die Uhrzeit des Snapshots — während auf dem Host längst 11:24 war.
Damit das klappt, muss die Geräteausstattung exakt zum gespeicherten Zustand
passen. pvesnap-recovery sorgt selbst dafür:
vmgenid, smbios1 |
bleiben erhalten — fehlen sie, bricht das Laden mit Unknown savevm section or instance 'vmgenid' ab |
runningmachine, runningcpu |
werden aus dem Snapshot übernommen |
| Netzwerkkarte | bleibt vorhanden, wird aber abgeklemmt (link_down=1) statt entfernt |
| Austauschlaufwerke | werden erst nach dem Fortsetzen angesteckt (Hotplug) — der Gast wacht in einem Zustand auf, in dem es die Platte noch nicht gab |
!!! note "Ein Detail, das Proxmox nicht selbst meldet"
Schlägt das Laden des Arbeitsspeichers fehl, quittiert Proxmox den Start
trotzdem mit `TASK OK` und lässt die Maschine angehalten stehen.
`pvesnap-recovery` liest das Task-Protokoll mit, setzt die Maschine fort und
sagt deutlich, wenn statt des RAM-Standes kalt gebootet wurde.
Mit --no-resume lässt sich der Arbeitsspeicher bewusst weglassen — etwa, wenn
SPICE gebraucht wird, das sich damit ausschließt.
Der übliche Ablauf
1. Austauschlaufwerk vorbereiten — vorher, in Ruhe
2. Maschine einrichten — Snapshot wählen, Optionen prüfen, anlegen
3. Damit arbeiten — noVNC-Konsole, Dump ziehen, Laufwerk auswerfen
4. Verwerfen — oder dauerhaft übernehmen
Bedient wird alles entweder über die ncurses-Oberfläche:
pvesnap-recovery
… oder direkt über Parameter:
pvesnap-recovery live 101 # neuester Snapshot, abgeschottet
pvesnap-recovery live 101 auto-stuendlich-20260809-100000
pvesnap-recovery recover 101 --newid 9101 # mit Netzwerk
pvesnap-recovery list
pvesnap-recovery destroy 9101
Vollständig unter Alle Befehle.
Was in der Übersicht steht
| Spalte | |
|---|---|
| Maschine | die neue VMID |
| Zustand | running, stopped — oder weg, wenn sie außerhalb von pvesnap entfernt wurde |
| Node | auf welchem Cluster-Knoten sie läuft |
| Herkunft | Original-VMID und Snapshot, aus dem sie stammt |
| Modus | live oder recover |
| Taste | |
|---|---|
| ++enter++ | Detailansicht |
| ++n++ | neue Wiederherstellung |
| ++s++ / ++h++ | starten / herunterfahren |
| ++x++ | verwerfen |
| ++v++ | Austauschlaufwerke |
| ++c++ | aufräumen — Reste und verwaiste Snapshot-Sperren |
| ++r++ | Liste neu einlesen |
| ++q++ | Ende |
!!! tip "Wiederhergestellte Maschinen tragen einen Tag"
Jede von `pvesnap-recovery` angelegte Maschine bekommt in Proxmox den Tag
**`pvesnap-recovery`**. Daran erkennt man sie in der Weboberfläche — und
daran erkennt `destroy`, dass es sie anfassen darf. Eine von Hand angelegte
VM lässt sich damit nicht versehentlich löschen.
Der Tag ist auch der Grund, warum
`exclude_tags = nosnap, pvesnap-recovery` in jede `all`-Gruppe gehört, siehe
[Auswahl](../sichern/auswahl.md#ausschlusse).