proxmox-snapshot-service/handbuch/docs/wiederherstellen/netzwerk.md

Mit Netzwerk

pvesnap-recovery recover 101 auto-stuendlich-20260809-100000 --newid 9101

Der Ernstfall: Die Maschine soll nicht nur untersucht, sondern wieder in Betrieb genommen werden.

Dabei bleibt alles erhalten, was die Maschine ausmacht:

• SMBIOS-UUID und vmgenid
• MAC-Adressen aller Netzwerkkarten
• bei Containern der Hostname

Für alles im Netz ist sie damit dieselbe Maschine — inklusive Lizenzbindungen, AD-Mitgliedschaft und DHCP-Reservierungen. Genau das will man im Ernstfall.

---

Genau deshalb ist sie gefährlich

!!! danger "Zwei Maschinen, eine Identität"

Dieselbe MAC und dieselbe IP zweimal im selben Netz geben Chaos: ARP-Tabellen
schlagen um, Verbindungen brechen sporadisch ab, ein Verzeichnisdienst
bekommt widersprüchliche Anmeldungen, und die Datenbank wird von zwei Seiten
beschrieben.

Und das Unangenehme daran: Es fällt nicht sofort auf. Es fällt eine halbe
Stunde später auf, wenn niemand mehr weiß, was zuletzt geändert wurde.

pvesnap-recovery prüft deshalb vorher, ob das Original noch läuft — und lässt sich in dem Fall nicht beiläufig durchwinken:

Situation	Verhalten
ncurses-Oberfläche	Zusammenfassung nur mit ++j++, danach eine zweite Rückfrage, die den Grund beim Namen nennt
recover … im Terminal	das Wort ja muss ausgeschrieben werden — ++j++ reicht nicht
recover … -y	wird abgewiesen (Exit-Code 2)
recover … --force	läuft durch — die bewusste Entscheidung

!!! quote "Warum -y nicht reicht"

`-y` heißt „keine Routinefragen", nicht „frag mich auch dann nicht, wenn es
weh tut". Ein Skript, das mit `-y` läuft, soll nicht versehentlich eine
zweite Domänencontroller-Identität ins Netz stellen.

Wer es wirklich will, schreibt `--force` — und hat es dann bewusst getan.

---

Der sichere Weg

Erste Wahl: Das Original vorher stoppen.

qm stop 101
pvesnap-recovery recover 101 --newid 9101

Zweite Wahl: Mit abgeklemmter Leitung starten und die Karte erst zuschalten, wenn klar ist, dass die Luft rein ist.

pvesnap-recovery recover 101 --newid 9101 --net down
# ... in der Konsole prüfen, ob es die richtige Maschine ist ...
qm set 9101 --net0 virtio=BC:24:11:00:65:40,bridge=vmbr0

Der zweite Weg hat einen praktischen Vorteil: Man sieht der Maschine über die noVNC-Konsole an, ob es wirklich der richtige Stand ist — bevor sie irgendjemand im Netz erreicht.

---

Die drei Netzwerkzustände

--net
none	keine Netzwerkkarte. Die Maschine hat gar kein Netz. Vorgabe bei live.
down	Karte vorhanden, Leitung abgeklemmt (link_down=1). Der Gast sieht seine Karte, aber nichts kommt durch.
on	voll am Netz, mit den MAC-Adressen des Originals. Vorgabe bei recover.

Der Unterschied zwischen none und down ist wichtiger, als er aussieht:

!!! info "Mit geladenem Arbeitsspeicher wird aus none automatisch down"

Ein gespeicherter RAM-Zustand lässt sich nur in eine Maschine mit **exakt
derselben Geräteausstattung** laden. Eine entfernte Netzwerkkarte wäre eine
Änderung — das Laden würde scheitern.

Deshalb bleibt die Karte in diesem Fall vorhanden und wird stattdessen
abgeklemmt. In der Zusammenfassung steht dazu ein Hinweis; man muss also
nicht selbst daran denken.

---

Was danach zu tun ist

Eine Wiederherstellung, die dauerhaft bleiben soll, ist noch nicht fertig:

1. Vom Quell-Snapshot lösen — sonst hängt sie für immer daran, und die Vorhaltezeit kommt an den Snapshots des Originals nicht mehr vorbei

2. Den Tag pvesnap-recovery entfernen, wenn sie zur regulären Maschine werden soll:

qm set 9101 --tags produktion,datenbank

3. Aus der Merkliste nehmen — nach dem Entfernen des Tags taucht sie in pvesnap-recovery list ohnehin nicht mehr als lebend auf

4. onboot wieder setzen, falls sie beim Hostneustart hochkommen soll:

qm set 9101 --onboot 1

!!! warning "Schritt 1 ist keine Kür"

Solange die Maschine ein Linked Clone ist, kann der Quell-Snapshot nicht
gelöscht werden — und das Original muss mitsamt seiner Platte bestehen
bleiben. Im Protokoll des Dienstes stünde dauerhaft
`snapshot is protected`.

Siehe [Vom Snapshot lösen](loesen.md).

!!! note "onboot und startup werden bewusst weggelassen"

Eine frisch angelegte Wiederherstellung soll nicht beim nächsten
Hostneustart von selbst hochkommen — schon gar nicht eine mit den
MAC-Adressen einer noch laufenden Maschine. Wer sie behält, setzt das selbst.

---

Und das Original?

Wenn die Wiederherstellung übernimmt, will das Original meistens weg. Aber nicht sofort:

!!! danger "Erst lösen, dann löschen"

Solange die Wiederherstellung ein Linked Clone ist, hängt sie an den
Datenträgern des Originals. Das Original zu löschen, würde die
Wiederherstellung mitnehmen.

Reihenfolge:

1. `pvesnap-recovery flatten 9101` — abwarten, bis es durch ist
2. prüfen: Die Detailansicht muss *„eigenständig — hängt an keinem Snapshot"*
   zeigen
3. erst dann das Original entfernen

Auf LVM-thin entfällt das — dort sind die Klone von sich aus unabhängig. Siehe Speicherarten.