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>
7.1 KiB
Eine Maschine einrichten
pvesnap-recovery
Dann ++n++ in der Übersicht. Der Assistent fragt nacheinander nach Gast und Snapshot — dieselben Auswahlfenster wie im Explorer — und landet dann in der Optionsmaske.
Die Optionsmaske
Pfeiltasten bewegen sich, ++enter++ oder ++space++ ändert ein Feld. Unten steht zu jedem Feld eine Erklärung — man muss also nichts auswendig wissen.
| Taste | |
|---|---|
| ++enter++ ++space++ | Feld ändern |
| ++v++ | Austauschlaufwerke verwalten — ohne die Maske zu verlassen |
| ++f10++ | anlegen |
| ++q++ | abbrechen |
Betriebsart
| live | abgeschottet, ohne Netzwerk. Zum Hineinschauen. |
| recovery | mit Netzwerk und gleicher Identität. Siehe Mit Netzwerk. |
Die übrigen Felder
| Feld | Vorgabe | |
|---|---|---|
| Netzwerk | automatisch (nach Modus) | keine Karte / Karte ohne Leitung / am Netz — überschreibt die Vorgabe der Betriebsart |
| Arbeitsspeicher | wenn im Snapshot vorhanden | mit nein bootet die Maschine kalt |
| Transfer-Laufwerke | — | Austauschlaufwerke, mehrere möglich |
| SPICE-Anzeige | nein | zusätzlich zu noVNC, nötig für USB |
| USB-Weiterleitung | keine | Anzahl der Anschlüsse; schaltet SPICE mit ein |
| Neue VMID | nächste freie | |
| Node | der des Originals | bei lokalem Storage nicht änderbar |
| Danach starten | ja | mit nein nur einrichten |
Austauschlaufwerke auswählen
Auf dem Feld Transfer-Laufwerke öffnet ++enter++ die Mehrfachauswahl:
++space++ wählt aus, ++enter++ übernimmt. Belegte Laufwerke lassen sich nicht anhängen — sie sind entweder am Host eingehängt oder stecken schon in einer anderen Maschine. Warum das so streng ist, steht unter Austauschlaufwerke.
Fehlt noch eins, führt ++v++ direkt in die Verwaltung und wieder zurück.
Die Zusammenfassung
++f10++ zeigt, was passieren wird — bevor etwas passiert:
Hier lohnt sich das Lesen. Vier Arten von Zeilen stehen darin:
| Klone | welche Datenträger geklont werden, mit Größe |
Hinweise (-) |
was pvesnap von sich aus angepasst hat und warum |
| ACHTUNG | Dinge, die man wissen sollte, die aber in Ordnung sind |
| GEFAHR | Dinge, die so nicht gehen — siehe Mit Netzwerk |
Im Bild sind es drei Hinweise, die je einen Sachverhalt erklären:
Netzwerkkarte bleibt vorhanden, aber abgeklemmt (link_down): mit geladenem Arbeitsspeicher darf sich die Geräteausstattung nicht ändern.
Die Karte zu entfernen würde den gespeicherten RAM-Zustand unbrauchbar machen — also bleibt sie drin, und stattdessen wird die Leitung gekappt.
Proxmox gibt den kopierten Arbeitsspeicher nach dem ersten Start wieder frei — ein späterer Neustart bootet dann kalt.
Der warme Zustand ist einmalig. Wer ihn braucht, sollte gleich beim ersten Start damit arbeiten.
Mit ++j++ geht es los, mit ++n++ zurück.
Auf der Kommandozeile
pvesnap-recovery live 101 # neuester Snapshot
pvesnap-recovery live 101 auto-stuendlich-20260809-100000 # ein bestimmter
pvesnap-recovery live 101 --newid 9103 --transfer werkzeuge -y
Ohne Snapshot-Namen wird der neueste brauchbare genommen.
| Parameter | Bedeutung |
|---|---|
--newid <ID> |
VMID der neuen Maschine (Vorgabe: nächste freie) |
--node <name> |
auf welchem Node sie laufen soll |
--net none|down|on |
keine Karte / Karte ohne Leitung / voll am Netz |
--resume / --no-resume |
Arbeitsspeicher laden bzw. bewusst kalt starten |
--transfer <name> |
Austauschlaufwerk anhängen (mehrfach möglich) |
--spice |
SPICE-Anzeige (vga: qxl), zusätzlich zu noVNC |
--usb <n> |
so viele USB-Weiterleitungen über SPICE (schaltet --spice mit ein) |
--iso <volid> |
Abbild als CD einlegen, z. B. local:iso/virtio-win.iso |
--memory <MB>, --cores <n> |
abweichende Ausstattung (nicht mit --resume) |
--name <name> |
Name der neuen Maschine |
--keep-binds |
durchgereichte Host-Verzeichnisse des Originals übernehmen |
--no-start |
nur einrichten, nicht starten |
-y, --yes |
Routinefragen überspringen |
--force |
auch anlegen, wenn das Original noch läuft |
Ohne -y wird die Zusammenfassung angezeigt und nachgefragt. Ein Probelauf ist
das aber nicht — wer nur sehen will, was geschähe, bricht an der Rückfrage ab.
!!! danger "-y deckt --force nicht ab"
`-y` überspringt **Routinefragen**. Es winkt nicht durch, dass eine
Wiederherstellung mit Netzwerk startet, während das Original läuft — das
verlangt ausdrücklich `--force`. Siehe [Mit Netzwerk](netzwerk.md).
Was dabei angelegt wird
- Klone aller Datenträger des Snapshots (
PVE::Storage::vdisk_clone) - eine Konfigurationsdatei unter
/etc/pve/nodes/<node>/qemu-server/<id>.conf - der Tag
pvesnap-recoveryan der neuen Maschine - ein Eintrag in der Merkliste
/var/lib/pvesnap/recovery.json
Geht dabei etwas schief, wird alles wieder abgeräumt — es bleiben keine halben Klone liegen.
!!! info "Auf Ceph wird der Quell-Snapshot geschützt"
RBD verlangt für einen Klon, dass der Quell-Snapshot geschützt ist
(`rbd snap protect`); Proxmox setzt das beim Klonen selbst.
Solange die Wiederherstellung existiert, ist ihr Quell-Snapshot damit
**unlöschbar** — die [Vorhaltezeit](../sichern/vorhaltezeit.md) kommt an ihm
nicht vorbei. Beim [Verwerfen](verwerfen.md) wird der Schutz wieder
aufgehoben.
Das ist der Grund, eine Wiederherstellung nicht länger stehen zu lassen als
nötig — oder sie mit [`flatten`](loesen.md) zu lösen.
Was übernommen wird und was nicht
Übernommen: SMBIOS-UUID, vmgenid, MAC-Adressen, CPU- und
Speicherausstattung, Bootreihenfolge, alle Datenträger als Klone, bei Containern
der Hostname.
Weggelassen:
| warum | |
|---|---|
onboot, startup |
eine Wiederherstellung soll nicht beim nächsten Hostneustart von selbst hochkommen |
protection |
sie soll sich verwerfen lassen |
replicate |
sonst würde der Klon auf andere Nodes repliziert |
hookscript |
fremde Skripte laufen nicht ungefragt in der Kopie |
description, tags |
wird durch die eigenen ersetzt |
| durchgereichte Host-Verzeichnisse | nur mit --keep-binds |
parent, snaptime, snapstate |
gehören zum Snapshot, nicht zur Maschine |
!!! warning "--keep-binds mit Bedacht"
Reicht das Original ein Host-Verzeichnis in den Container durch, sieht die
Wiederherstellung mit `--keep-binds` **dieselben, echten Daten** — nicht
deren Stand vom Snapshot. Und sie kann hineinschreiben.
Ohne die Option bleibt das Verzeichnis weg; in der Zusammenfassung steht
dann, was weggelassen wurde.