proxmox-snapshot-service/handbuch/docs/wiederherstellen/index.md

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
++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).