# 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.

![Übersicht der Wiederherstellungen](../bilder/recovery-uebersicht.svg)

---

## 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](transfer.md) heraus.

`recovery` ist der Ernstfall — und gefährlich, solange das Original läuft.
Details unter [Mit Netzwerk](netzwerk.md).

---

## 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](dongle.md) gebraucht wird, das sich damit ausschließt.

---

## Der übliche Ablauf

<div class="ablauf" markdown>

**1.** [Austauschlaufwerk vorbereiten](transfer.md) — *vorher*, in Ruhe

**2.** [Maschine einrichten](einrichten.md) — Snapshot wählen, Optionen prüfen, anlegen

**3.** [Damit arbeiten](arbeiten.md) — noVNC-Konsole, Dump ziehen, Laufwerk auswerfen

**4.** [Verwerfen](verwerfen.md) — oder [dauerhaft übernehmen](loesen.md)

</div>

Bedient wird alles entweder über die ncurses-Oberfläche:

```bash
pvesnap-recovery
```

… oder direkt über Parameter:

```bash
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](../nachschlagen/befehle.md#pvesnap-recovery).

---

## 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](arbeiten.md) |
| ++n++ | [neue Wiederherstellung](einrichten.md) |
| ++s++ / ++h++ | starten / herunterfahren |
| ++x++ | [verwerfen](verwerfen.md) |
| ++v++ | [Austauschlaufwerke](transfer.md) |
| ++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).