# Mit Netzwerk

```bash
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

<div class="ablauf" markdown>

**Erste Wahl:** Das Original **vorher stoppen**.

```bash
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.

```bash
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
```

</div>

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:

<div class="ablauf" markdown>

**1.** [Vom Quell-Snapshot lösen](loesen.md) — 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:

```bash
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:

```bash
qm set 9101 --onboot 1
```

</div>

!!! 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](../nachschlagen/speicher.md).