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>
181 lines
6.7 KiB
Markdown
181 lines
6.7 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) |
|
|
| ++c++ | [aufräumen](verwerfen.md#cleanup) — 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).
|