# Eine Maschine einrichten ```bash pvesnap-recovery ``` Dann ++n++ in der Übersicht. Der Assistent fragt nacheinander nach Gast und Snapshot — dieselben Auswahlfenster wie im [Explorer](../holen/explorer.md#1-welcher-gast) — und landet dann in der Optionsmaske. --- ## Die Optionsmaske ![Die Optionsmaske](../bilder/recovery-optionen.svg) 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](transfer.md) — ohne die Maske zu verlassen | | ++f10++ | anlegen | | ++q++ | abbrechen | ### Betriebsart ![Die Wahl der Betriebsart](../bilder/recovery-betriebsart.svg) | | | |---|---| | **live** | abgeschottet, ohne Netzwerk. Zum Hineinschauen. | | **recovery** | mit Netzwerk und gleicher Identität. Siehe [Mit Netzwerk](netzwerk.md). | ### 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](transfer.md), mehrere möglich | | **SPICE-Anzeige** | nein | zusätzlich zu noVNC, nötig für [USB](dongle.md) | | **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: ![Austauschlaufwerke auswählen](../bilder/transfer-auswahl.svg) ++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](transfer.md#host-oder-gast-nie-beides). Fehlt noch eins, führt ++v++ direkt in die Verwaltung und wieder zurück. --- ## Die Zusammenfassung ++f10++ zeigt, was passieren wird — **bevor** etwas passiert: ![Das Vorhaben prüfen](../bilder/recovery-vorhaben.svg) 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](netzwerk.md) | 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 ```bash 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 ` | VMID der neuen Maschine (Vorgabe: nächste freie) | | `--node ` | 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 ` | Austauschlaufwerk anhängen (mehrfach möglich) | | `--spice` | SPICE-Anzeige (`vga: qxl`), zusätzlich zu noVNC | | `--usb ` | so viele USB-Weiterleitungen über SPICE (schaltet `--spice` mit ein) | | `--iso ` | Abbild als CD einlegen, z. B. `local:iso/virtio-win.iso` | | `--memory `, `--cores ` | abweichende Ausstattung (nicht mit `--resume`) | | `--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 1. **Klone** aller Datenträger des Snapshots (`PVE::Storage::vdisk_clone`) 2. eine **Konfigurationsdatei** unter `/etc/pve/nodes//qemu-server/.conf` 3. der **Tag** `pvesnap-recovery` an der neuen Maschine 4. 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.