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>
5.4 KiB
Damit arbeiten
++enter++ auf einer Maschine in der Übersicht öffnet die Detailansicht. Das ist der Bildschirm, auf dem man im Ernstfall die meiste Zeit verbringt:
| Taste | |
|---|---|
| ++s++ | starten |
| ++h++ | herunterfahren |
| ++e++ | Austauschlaufwerk auswerfen / einklinken |
| ++v++ | Austauschlaufwerke verwalten |
| ++p++ | SPICE und USB |
| ++f++ | vom Quell-Snapshot lösen |
| ++x++ | verwerfen |
| ++q++ | zurück |
An die Konsole kommen
In der Detailansicht steht die fertige Adresse:
https://10.20.0.11:8006/?console=kvm&novnc=1&vmid=9101&node=pve1&resize=off&cmd=
Dasselbe liefert pvesnap-recovery console 9101. Es ist die ganz normale
noVNC-Konsole von Proxmox — die Maschine taucht auch in der Weboberfläche auf,
markiert mit dem Tag pvesnap-recovery.
Bei Containern geht zusätzlich pct enter 9101 auf dem Host.
!!! info "Warum eine IP-Adresse und kein Name?"
Vorne steht bewusst die **IP** des Nodes, nicht sein Name: Auf dem
Proxmox-Host löst der Name auf, am Arbeitsplatz meist nicht. Sie kommt aus
`/etc/pve/.members`.
Der Node hinter `node=` bleibt der Name — so erwartet Proxmox ihn.
Für SPICE und USB-Weiterleitung siehe Dongle und USB.
Was man drinnen tut
Die Maschine ist voll beschreibbar. Alles, was man an einer echten Maschine täte, geht auch hier — nur eben ohne Netz.
Der typische Ablauf für eine Datenbank:
1. Im Gast prüfen, ob der Dienst läuft — mit geladenem Arbeitsspeicher ist er bereits offen
2. Dump schreiben, auf das Austauschlaufwerk:
pg_dump -Fc kunden > /media/DUMPS/kunden.dump
3. Im Gast aushängen (umount, unter Windows „Auswerfen")
4. In pvesnap ++e++ — Laufwerk auswerfen
5. ++v++ ++enter++ — Commander auf das Laufwerk, Dump abholen
6. ++x++ — Maschine verwerfen
Schritt 3 ist der, den man vergisst. Mehr dazu unter Austauschlaufwerke.
Herunterfahren
Taste ++h++ fährt sauber herunter — und schaltet nicht von selbst hart ab.
Weigert sich der Gast, kommt eine Wahl:
| Im Gast selbst herunterfahren | pvesnap wartet und meldet, wenn sie aus ist |
| Hart ausschalten | wie Stecker ziehen, mit ausdrücklicher Bestätigung |
| Abbrechen | läuft weiter |
!!! quote "Warum nicht einfach nach 60 Sekunden abschalten?"
Weil ein stilles Abschalten nach Zeitablauf ein Stromausfall mit Ansage
wäre — und genau der Grund, warum ein Dateisystem hinterher unsauber ist.
Wenn man gerade dabei ist, aus einer Maschine konsistente Daten zu holen,
ist das die falsche Voreinstellung.
Beim Warten zeigt pvesnap, was zu tun ist, und verfolgt den Zustand:
Bitte jetzt IM GAST herunterfahren.
Windows Start -> Ein/Aus -> Herunterfahren
Linux poweroff bzw. shutdown -h now
Zustand: running seit 1:23
++q++ bricht das Warten ab — die Maschine läuft dann weiter.
Neu starten
Ein Neustart wird nötig, wenn sich die Grafikkarte ändert — also beim Ein- oder Ausschalten von SPICE. Dann kommt dieselbe Wahl:
| Ich fahre im Gast herunter | pvesnap wartet, startet danach selbst wieder — der verlässliche Weg |
| Proxmox herunterfahren lassen (ACPI) | klappt bei Linux, bei Windows oft nicht |
| Gar nicht | später selbst; die Änderung greift beim nächsten Start |
!!! warning "ACPI und Windows"
Bei Linux funktioniert der ACPI-Aus-Knopf zuverlässig. Windows blockt ihn
gern: Dort hält eine Anwendung den Vorgang auf, oder der Shutdown Event
Tracker fragt nach einem Grund und wartet auf eine Eingabe, die nie kommt.
Wer im Gast selbst herunterfährt, umgeht das. Deshalb steht dieser Weg an
erster Stelle.
!!! danger "Ein Neustart im Gast hilft nicht"
Dabei setzt sich nur die Maschine zurück — der QEMU-Prozess läuft weiter,
mit der alten Grafikkarte. Es braucht wirklich den Umweg über „aus und
wieder an".
Der geladene Arbeitsspeicher ist danach weg
!!! danger "Endgültig"
Proxmox gibt den kopierten Arbeitsspeicher schon beim **ersten** Start
wieder frei. Ein zweiter Start bootet also kalt — offene Programme und
ungespeicherte Daten sind dann verloren.
pvesnap warnt vorher ausdrücklich, wenn eine Maschine mit geladenem
Arbeitsspeicher neu starten soll:
Wer den warmen Zustand braucht, erledigt seine Arbeit also vor dem ersten
Neustart — oder verzichtet gleich mit --no-resume darauf und bootet kalt.
Starten und Stoppen von außen
pvesnap-recovery start 9101
pvesnap-recovery stop 9101
pvesnap-recovery list
pvesnap-recovery console 9101
list zeigt dieselbe Tabelle wie die Übersicht:
Maschine Zustand Node Herkunft Modus
VM 9101 running pve1 VM 101 @ auto-stuendlich-20260809-… live
VM 9102 stopped pve2 VM 105 @ auto-taeglich-20260809-02… recover
Steht in der Spalte Zustand ein weg, wurde die Maschine außerhalb von
pvesnap entfernt — dann hilft cleanup.