duffyduckandClaude Opus 5
59e7224297
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht: erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen, dahinter der Nachschlagteil. Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten: keine Schriften vom CDN (font: false), Volltextsuche mit deutschem Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe Netz - dann nuetzt eine Doku im Internet nichts. handbuch/bauen.sh baut handbuch/site/ handbuch/bauen.sh ansehen Vorschau auf 127.0.0.1:8000 install.sh nimmt das gebaute Handbuch mit nach /usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor. Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm ueberein, sind reproduzierbar und enthalten keine echten Daten. Die Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md. Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange, das mit dem eingebauten Austauschlaufwerk weggefallen ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
180 lines
6.6 KiB
Markdown
180 lines
6.6 KiB
Markdown
# 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](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).
|