Handbuch auf MkDocs-Basis, mit Bildschirmfotos aus dem Programm
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>
This commit is contained in:
duffyduck
co-authored by
Claude Opus 5
Claude Opus 5
parent
c484596702
commit
59e7224297
@@ -0,0 +1,167 @@
|
||||
# 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).
|
||||
Reference in New Issue
Block a user