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,176 @@
|
||||
# Damit arbeiten
|
||||
|
||||
++enter++ auf einer Maschine in der Übersicht öffnet die Detailansicht. Das ist
|
||||
der Bildschirm, auf dem man im Ernstfall die meiste Zeit verbringt:
|
||||
|
||||
|
||||
|
||||
| Taste | |
|
||||
|---|---|
|
||||
| ++s++ | starten |
|
||||
| ++h++ | [herunterfahren](#herunterfahren) |
|
||||
| ++e++ | [Austauschlaufwerk auswerfen / einklinken](transfer.md#im-laufenden-betrieb-wechseln) |
|
||||
| ++v++ | [Austauschlaufwerke verwalten](transfer.md) |
|
||||
| ++p++ | [SPICE und USB](dongle.md#nachtraglich-umstellen) |
|
||||
| ++f++ | [vom Quell-Snapshot lösen](loesen.md) |
|
||||
| ++x++ | [verwerfen](verwerfen.md) |
|
||||
| ++q++ | zurück |
|
||||
|
||||
---
|
||||
|
||||
## An die Konsole kommen
|
||||
|
||||
In der Detailansicht steht die fertige Adresse:
|
||||
|
||||
```
|
||||
https://10.20.0.11:8006/?console=kvm&novnc=1&vmid=9101&node=pve1&resize=off&cmd=
|
||||
```
|
||||
|
||||
Dasselbe liefert `pvesnap-recovery console 9101`. Es ist die ganz normale
|
||||
noVNC-Konsole von Proxmox — die Maschine taucht auch in der Weboberfläche auf,
|
||||
markiert mit dem Tag `pvesnap-recovery`.
|
||||
|
||||
Bei Containern geht zusätzlich `pct enter 9101` auf dem Host.
|
||||
|
||||
!!! info "Warum eine IP-Adresse und kein Name?"
|
||||
|
||||
Vorne steht bewusst die **IP** des Nodes, nicht sein Name: Auf dem
|
||||
Proxmox-Host löst der Name auf, am Arbeitsplatz meist nicht. Sie kommt aus
|
||||
`/etc/pve/.members`.
|
||||
|
||||
Der Node hinter `node=` bleibt der Name — so erwartet Proxmox ihn.
|
||||
|
||||
Für SPICE und USB-Weiterleitung siehe [Dongle und USB](dongle.md).
|
||||
|
||||
---
|
||||
|
||||
## Was man drinnen tut
|
||||
|
||||
Die Maschine ist voll beschreibbar. Alles, was man an einer echten Maschine
|
||||
täte, geht auch hier — nur eben ohne Netz.
|
||||
|
||||
Der typische Ablauf für eine Datenbank:
|
||||
|
||||
<div class="ablauf" markdown>
|
||||
|
||||
**1.** Im Gast prüfen, ob der Dienst läuft — mit geladenem Arbeitsspeicher ist
|
||||
er bereits offen
|
||||
|
||||
**2.** Dump schreiben, auf das [Austauschlaufwerk](transfer.md):
|
||||
`pg_dump -Fc kunden > /media/DUMPS/kunden.dump`
|
||||
|
||||
**3.** Im Gast aushängen (`umount`, unter Windows „Auswerfen")
|
||||
|
||||
**4.** In pvesnap ++e++ — Laufwerk auswerfen
|
||||
|
||||
**5.** ++v++ ++enter++ — Commander auf das Laufwerk, Dump abholen
|
||||
|
||||
**6.** ++x++ — Maschine verwerfen
|
||||
|
||||
</div>
|
||||
|
||||
Schritt 3 ist der, den man vergisst. Mehr dazu unter
|
||||
[Austauschlaufwerke](transfer.md#im-laufenden-betrieb-wechseln).
|
||||
|
||||
---
|
||||
|
||||
## Herunterfahren
|
||||
|
||||
Taste ++h++ fährt **sauber** herunter — und schaltet nicht von selbst hart ab.
|
||||
|
||||
Weigert sich der Gast, kommt eine Wahl:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Im Gast selbst herunterfahren** | pvesnap wartet und meldet, wenn sie aus ist |
|
||||
| **Hart ausschalten** | wie Stecker ziehen, mit ausdrücklicher Bestätigung |
|
||||
| **Abbrechen** | läuft weiter |
|
||||
|
||||
!!! quote "Warum nicht einfach nach 60 Sekunden abschalten?"
|
||||
|
||||
Weil ein stilles Abschalten nach Zeitablauf ein Stromausfall mit Ansage
|
||||
wäre — und genau der Grund, warum ein Dateisystem hinterher unsauber ist.
|
||||
|
||||
Wenn man gerade dabei ist, aus einer Maschine konsistente Daten zu holen,
|
||||
ist das die falsche Voreinstellung.
|
||||
|
||||
Beim Warten zeigt pvesnap, was zu tun ist, und verfolgt den Zustand:
|
||||
|
||||
```
|
||||
Bitte jetzt IM GAST herunterfahren.
|
||||
|
||||
Windows Start -> Ein/Aus -> Herunterfahren
|
||||
Linux poweroff bzw. shutdown -h now
|
||||
|
||||
Zustand: running seit 1:23
|
||||
```
|
||||
|
||||
++q++ bricht das Warten ab — die Maschine läuft dann weiter.
|
||||
|
||||
---
|
||||
|
||||
## Neu starten
|
||||
|
||||
Ein Neustart wird nötig, wenn sich die [Grafikkarte ändert](dongle.md) — also
|
||||
beim Ein- oder Ausschalten von SPICE. Dann kommt dieselbe Wahl:
|
||||
|
||||
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Ich fahre im Gast herunter** | pvesnap wartet, startet danach selbst wieder — **der verlässliche Weg** |
|
||||
| **Proxmox herunterfahren lassen (ACPI)** | klappt bei Linux, bei Windows oft nicht |
|
||||
| **Gar nicht** | später selbst; die Änderung greift beim nächsten Start |
|
||||
|
||||
!!! warning "ACPI und Windows"
|
||||
|
||||
Bei Linux funktioniert der ACPI-Aus-Knopf zuverlässig. Windows blockt ihn
|
||||
gern: Dort hält eine Anwendung den Vorgang auf, oder der Shutdown Event
|
||||
Tracker fragt nach einem Grund und wartet auf eine Eingabe, die nie kommt.
|
||||
|
||||
Wer im Gast selbst herunterfährt, umgeht das. Deshalb steht dieser Weg an
|
||||
erster Stelle.
|
||||
|
||||
!!! danger "Ein Neustart *im* Gast hilft nicht"
|
||||
|
||||
Dabei setzt sich nur die Maschine zurück — der QEMU-Prozess läuft weiter,
|
||||
mit der alten Grafikkarte. Es braucht wirklich den Umweg über „aus und
|
||||
wieder an".
|
||||
|
||||
### Der geladene Arbeitsspeicher ist danach weg
|
||||
|
||||
!!! danger "Endgültig"
|
||||
|
||||
Proxmox gibt den kopierten Arbeitsspeicher schon beim **ersten** Start
|
||||
wieder frei. Ein zweiter Start bootet also kalt — offene Programme und
|
||||
ungespeicherte Daten sind dann verloren.
|
||||
|
||||
pvesnap warnt vorher ausdrücklich, wenn eine Maschine mit geladenem
|
||||
Arbeitsspeicher neu starten soll:
|
||||
|
||||
|
||||
|
||||
Wer den warmen Zustand braucht, erledigt seine Arbeit also **vor** dem ersten
|
||||
Neustart — oder verzichtet gleich mit `--no-resume` darauf und bootet kalt.
|
||||
|
||||
---
|
||||
|
||||
## Starten und Stoppen von außen
|
||||
|
||||
```bash
|
||||
pvesnap-recovery start 9101
|
||||
pvesnap-recovery stop 9101
|
||||
pvesnap-recovery list
|
||||
pvesnap-recovery console 9101
|
||||
```
|
||||
|
||||
`list` zeigt dieselbe Tabelle wie die Übersicht:
|
||||
|
||||
```
|
||||
Maschine Zustand Node Herkunft Modus
|
||||
VM 9101 running pve1 VM 101 @ auto-stuendlich-20260809-… live
|
||||
VM 9102 stopped pve2 VM 105 @ auto-taeglich-20260809-02… recover
|
||||
```
|
||||
|
||||
Steht in der Spalte **Zustand** ein `weg`, wurde die Maschine außerhalb von
|
||||
pvesnap entfernt — dann hilft [`cleanup`](verwerfen.md#cleanup).
|
||||
@@ -0,0 +1,176 @@
|
||||
# Dongle und USB
|
||||
|
||||
Eine abgeschottete Maschine hat kein Netzwerk. Ein Software-Schutzmodul hängt
|
||||
sonst an einem USB-Server im Netz — der ist damit unerreichbar. Und ohne
|
||||
Lizenzprüfung startet die Warenwirtschaft nicht, aus der man gerade Daten holen
|
||||
wollte.
|
||||
|
||||
**SPICE löst das.** Die USB-Weiterleitung kommt vom **Rechner des Bedieners**,
|
||||
nicht über das Gastnetz. Die Maschine bleibt also vollständig abgeschottet und
|
||||
hat trotzdem ihren Dongle.
|
||||
|
||||
```
|
||||
Dein Arbeitsplatz Proxmox-Host Gast
|
||||
Dongle am USB ──SPICE──► QEMU ──virtuell──► "USB-Gerät"
|
||||
remote-viewer (kein Netz nötig)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Einrichten
|
||||
|
||||
Beim Anlegen in der [Optionsmaske](einrichten.md#die-optionsmaske) die beiden
|
||||
Felder setzen — oder direkt:
|
||||
|
||||
```bash
|
||||
pvesnap-recovery live 105 --usb 2 --no-resume
|
||||
```
|
||||
|
||||
`--usb` schaltet `--spice` automatisch mit ein.
|
||||
|
||||
Die Zusammenfassung sagt dann, was zu tun ist:
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Verbinden
|
||||
|
||||
```bash
|
||||
pvesnap-recovery spice 9104 -o vm.vv # Verbindungsdatei erzeugen
|
||||
scp root@10.20.0.12:vm.vv . # auf den Arbeitsplatz holen
|
||||
remote-viewer vm.vv # öffnen
|
||||
```
|
||||
|
||||
Ohne `-o` wird die Datei auf die Standardausgabe geschrieben — praktisch für
|
||||
eine Pipeline:
|
||||
|
||||
```bash
|
||||
ssh root@pve2 pvesnap-recovery spice 9104 > vm.vv && remote-viewer vm.vv
|
||||
```
|
||||
|
||||
Im **remote-viewer** dann unter **Datei → USB-Geräteauswahl** das Gerät
|
||||
anhaken. Es taucht sofort im Gast auf.
|
||||
|
||||
!!! success "Guest-Tools braucht es dafür nicht"
|
||||
|
||||
Der Dongle erscheint im Gast als gewöhnliches USB-Gerät; QEMU und der
|
||||
SPICE-Client machen die Arbeit.
|
||||
|
||||
Die Guest-Tools (`tools/get-guest-tools.sh` holt virtio-win auf einen
|
||||
ISO-Storage) sind nur für Zwischenablage, automatische Auflösung und
|
||||
Mauszeiger nützlich. Für den Dongle sind sie überflüssig.
|
||||
|
||||
Die Verbindungsdatei ist **kurzlebig**: Das darin enthaltene Kennwort gilt nur
|
||||
für wenige Sekunden. Sie muss also zeitnah nach dem Erzeugen benutzt werden —
|
||||
nicht am Vortag vorbereiten.
|
||||
|
||||
---
|
||||
|
||||
## Zwei Dinge, die man vorher wissen sollte
|
||||
|
||||
### USB braucht SPICE
|
||||
|
||||
Ohne `vga: qxl` legt QEMU die Weiterleitungen zwar an, aber es gibt keinen
|
||||
Kanal, der sie transportiert — die Maschine startet dann mit `no spice port`
|
||||
gar nicht erst.
|
||||
|
||||
Deshalb schaltet `--usb` die Anzeige automatisch mit ein.
|
||||
|
||||
Umgekehrt gilt das nicht: Wer SPICE **ausschaltet**, verliert die USB-Anschlüsse
|
||||
mit — ohne Kanal wären sie ohnehin wirkungslos. pvesnap sagt das dazu, statt sie
|
||||
stillschweigend stehen zu lassen.
|
||||
|
||||
### SPICE und geladener Arbeitsspeicher schließen sich aus
|
||||
|
||||
Das ist der unangenehme Teil, und er hängt davon ab, was im **Original** steht:
|
||||
|
||||
| Original | warmer RAM-Zustand | SPICE + Dongle |
|
||||
|---|---|---|
|
||||
| `vga: std` (Vorgabe) | ✅ | nur mit `--no-resume` |
|
||||
| `vga: qxl` | ✅ | ✅ **gleichzeitig** |
|
||||
|
||||
Der Grund: `qxl` bringt 64 MB Grafikspeicher mit, die Vorgabe 16. Der
|
||||
gespeicherte Zustand passt dann nicht mehr, und das Laden bricht ab:
|
||||
|
||||
```
|
||||
Size mismatch: vga.vram
|
||||
```
|
||||
|
||||
Die Maschine bleibt danach angehalten stehen, während Proxmox `TASK OK` meldet.
|
||||
`pvesnap-recovery` lehnt die Kombination deshalb von vornherein ab und nennt die
|
||||
Auswege.
|
||||
|
||||
!!! tip "Der Griff, der sich lohnt — für Produktivmaschinen"
|
||||
|
||||
Setz auf Maschinen, die ein Schutzmodul brauchen, **einmal** `vga: qxl`:
|
||||
|
||||
```bash
|
||||
qm set 105 --vga qxl
|
||||
```
|
||||
|
||||
Dann tragen alle künftigen Snapshots es mit, und im Ernstfall gibt es
|
||||
warmen RAM-Zustand **und** Dongle gleichzeitig.
|
||||
|
||||
**Nachträglich lässt sich das bei einem vorhandenen Snapshot nicht mehr
|
||||
reparieren** — der gespeicherte Zustand enthält die alte Grafikkarte. Es ist
|
||||
also eine Entscheidung, die man vorher trifft oder gar nicht.
|
||||
|
||||
Auf der Produktivmaschine kostet `qxl` nichts außer ein paar Megabyte
|
||||
Grafikspeicher.
|
||||
|
||||
---
|
||||
|
||||
## Nachträglich umstellen
|
||||
|
||||
Taste ++p++ in der [Detailansicht](arbeiten.md) ändert SPICE und USB auch an
|
||||
einer bestehenden Maschine:
|
||||
|
||||
|
||||
|
||||
Dann die Zahl der Anschlüsse:
|
||||
|
||||
|
||||
|
||||
| Änderung | |
|
||||
|---|---|
|
||||
| **SPICE ein oder aus** | **Neustart nötig** — die Grafikkarte lässt sich im Betrieb nicht wechseln |
|
||||
| **USB dazu oder weg** | sofort, solange der SPICE-Kanal schon steht |
|
||||
|
||||
Ist ein Neustart nötig, warnt pvesnap vorher deutlich:
|
||||
|
||||
|
||||
|
||||
… und lässt danach die Wahl, **wie** neu gestartet wird — siehe
|
||||
[Damit arbeiten](arbeiten.md#neu-starten).
|
||||
|
||||
!!! danger "Bei geladenem Arbeitsspeicher"
|
||||
|
||||
Der ist nach dem Neustart **endgültig weg**. Wer SPICE nachrüstet, um an
|
||||
den Dongle zu kommen, verliert also genau den warmen Zustand, wegen dem er
|
||||
vielleicht überhaupt mit `--resume` gestartet ist.
|
||||
|
||||
Deshalb: die Entscheidung möglichst **vor** dem ersten Start treffen.
|
||||
|
||||
Höchstens **14 Anschlüsse** sind möglich — mehr sieht QEMU nicht vor. Für einen
|
||||
Dongle reicht einer; zwei sind bequem, wenn man zusätzlich einen USB-Stick
|
||||
durchreichen will.
|
||||
|
||||
---
|
||||
|
||||
## Wenn der Dongle nicht auftaucht
|
||||
|
||||
| Symptom | woran es liegt |
|
||||
|---|---|
|
||||
| Kein Eintrag unter „USB-Geräteauswahl" | Der `remote-viewer` läuft auf dem falschen Rechner — er muss dort laufen, wo der Dongle steckt. |
|
||||
| Maschine startet nicht, `no spice port` | `vga: qxl` fehlt. In der Detailansicht ++p++ → SPICE ein. |
|
||||
| Gerät angehakt, im Gast nichts | Manche Dongles brauchen im Gast einen Treiber. Der gehört auf ein [Austauschlaufwerk](transfer.md). |
|
||||
| `.vv`-Datei wird abgewiesen | Sie ist zu alt — neu erzeugen, das Kennwort gilt nur kurz. |
|
||||
| Unter Linux fehlt `remote-viewer` | Paket `virt-viewer` installieren. |
|
||||
|
||||
!!! note "Der Dongle bleibt am Arbeitsplatz"
|
||||
|
||||
Er wird nicht in den Host gesteckt und nicht ins Netz gehängt. Genau das ist
|
||||
der Punkt: Der Weg führt über die SPICE-Verbindung, die ohnehin schon
|
||||
zwischen Arbeitsplatz und Maschine besteht — und nicht über ein Netz, das
|
||||
die abgeschottete Maschine gar nicht hat.
|
||||
@@ -0,0 +1,188 @@
|
||||
# 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
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **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:
|
||||
|
||||
|
||||
|
||||
++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:
|
||||
|
||||
|
||||
|
||||
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 <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
|
||||
|
||||
1. **Klone** aller Datenträger des Snapshots (`PVE::Storage::vdisk_clone`)
|
||||
2. eine **Konfigurationsdatei** unter `/etc/pve/nodes/<node>/qemu-server/<id>.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.
|
||||
@@ -0,0 +1,179 @@
|
||||
# Wiederherstellen
|
||||
|
||||
Manchmal reicht es nicht, einzelne Dateien herauszukopieren.
|
||||
|
||||
Eine Datenbank liegt im Snapshot als Haufen halbfertiger Dateien — brauchbar
|
||||
wird sie erst, wenn der Datenbankserver läuft und selbst einen Dump schreibt.
|
||||
Eine Warenwirtschaft prüft beim Start ihre Lizenz. Ein Verzeichnisdienst ist
|
||||
ohne laufende Maschine überhaupt nicht zu befragen.
|
||||
|
||||
`pvesnap-recovery` startet den Snapshot deshalb als **eigenständige Maschine** —
|
||||
ohne das Original anzufassen.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Zwei Betriebsarten
|
||||
|
||||
| | **live** | **recovery** |
|
||||
|---|---|---|
|
||||
| Netzwerk | keins | volles Netz |
|
||||
| Identität | bleibt (UUID, MACs, Hostname) | bleibt (UUID, MACs, Hostname) |
|
||||
| Wofür | hineinschauen, Dump ziehen, Daten holen | die Maschine wirklich wieder in Betrieb nehmen |
|
||||
| Risiko | keins — sie kann nichts erreichen | hoch, solange das Original läuft |
|
||||
|
||||
**Der Unterschied ist ausschließlich das Netzwerk** — und die Zahl der
|
||||
Sicherheitsabfragen. An den Datenträgern ändert der Modus nichts; beide klonen
|
||||
gleich.
|
||||
|
||||
`live` ist der Normalfall. Die Maschine ist vollständig abgeschottet: Sie kann
|
||||
nichts erreichen und niemanden stören, auch wenn sie dieselbe IP-Adresse
|
||||
konfiguriert hat wie das noch laufende Original. Daten kommen über ein
|
||||
[Austauschlaufwerk](transfer.md) heraus.
|
||||
|
||||
`recovery` ist der Ernstfall — und gefährlich, solange das Original läuft.
|
||||
Details unter [Mit Netzwerk](netzwerk.md).
|
||||
|
||||
---
|
||||
|
||||
## Warum das schnell geht
|
||||
|
||||
Die Datenträger werden nicht kopiert, sondern **geklont**. Auf Ceph/RBD, ZFS und
|
||||
LVM-thin ist das ein Copy-on-Write-Klon: fertig in Sekunden, egal wie groß die
|
||||
Platte ist, und anfangs ohne zusätzlichen Platzbedarf.
|
||||
|
||||
```
|
||||
Klon ~1 s egal ob 32 GB oder 2 TB
|
||||
Start Sekunden mit RAM-Zustand sofort im laufenden Zustand
|
||||
Arbeiten ab jetzt voll beschreibbar
|
||||
```
|
||||
|
||||
Eine 32-GB-Platte war im Test nach **0,8 Sekunden** geklont.
|
||||
|
||||
Dafür wird `PVE::Storage::vdisk_clone` benutzt — dieselbe Funktion, die auch
|
||||
Proxmox selbst für Klone verwendet, samt Cluster-Sperre auf dem Storage. Es
|
||||
wird nichts nachgebaut, was Proxmox schon kann.
|
||||
|
||||
!!! info "Kein „Live-Restore"— besser"
|
||||
|
||||
Beim Live-Restore eines Backup-Servers liegt die Sicherung auf einem anderen
|
||||
Medium: Die VM startet zwar sofort, holt die Blöcke aber im Hintergrund
|
||||
übers Netz nach und läuft bis dahin gebremst.
|
||||
|
||||
Hier wird **gar nichts nachgeladen**. Der Klon liegt im selben Pool und ist
|
||||
aus Sicht des Gastes von Sekunde eins an vollständig — bei voller
|
||||
Geschwindigkeit. Bei einer 2-TB-VM wird also nicht stundenlang kopiert und
|
||||
dann gestartet; gearbeitet wird ab der ersten Sekunde.
|
||||
|
||||
!!! warning "Nicht auf jedem Storage"
|
||||
|
||||
Auf Datei-Storages (`dir`, `nfs`, `cifs`) geht das nicht — aus einem
|
||||
qcow2-internen Snapshot lässt sich kein Klon ziehen. Für diese Storages
|
||||
bleibt der Weg über den [Explorer](../holen/explorer.md).
|
||||
|
||||
Was welches Storage kann, steht unter
|
||||
[Speicherarten](../nachschlagen/speicher.md).
|
||||
|
||||
---
|
||||
|
||||
## Der Arbeitsspeicher kommt mit
|
||||
|
||||
Enthält der Snapshot den Arbeitsspeicher (`vmstate = yes` in der Gruppe), wird
|
||||
er mitgenommen. Die Maschine **bootet dann nicht**, sondern läuft genau dort
|
||||
weiter, wo sie beim Snapshot stand:
|
||||
|
||||
* kein Crash-Recovery, kein `fsck`, kein Journal-Rollback
|
||||
* Datenbanken sind bereits offen und konsistent
|
||||
* die Uhr im Gast steht auf dem Snapshot-Zeitpunkt
|
||||
|
||||
Im Test war das gut zu sehen: Die Konsole zeigte 10:38 — die Uhrzeit des
|
||||
Snapshots — während auf dem Host längst 11:24 war.
|
||||
|
||||
Damit das klappt, muss die Geräteausstattung **exakt** zum gespeicherten Zustand
|
||||
passen. `pvesnap-recovery` sorgt selbst dafür:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| `vmgenid`, `smbios1` | bleiben erhalten — fehlen sie, bricht das Laden mit `Unknown savevm section or instance 'vmgenid'` ab |
|
||||
| `runningmachine`, `runningcpu` | werden aus dem Snapshot übernommen |
|
||||
| Netzwerkkarte | bleibt **vorhanden**, wird aber abgeklemmt (`link_down=1`) statt entfernt |
|
||||
| Austauschlaufwerke | werden erst **nach** dem Fortsetzen angesteckt (Hotplug) — der Gast wacht in einem Zustand auf, in dem es die Platte noch nicht gab |
|
||||
|
||||
!!! note "Ein Detail, das Proxmox nicht selbst meldet"
|
||||
|
||||
Schlägt das Laden des Arbeitsspeichers fehl, quittiert Proxmox den Start
|
||||
trotzdem mit `TASK OK` und lässt die Maschine angehalten stehen.
|
||||
|
||||
`pvesnap-recovery` liest das Task-Protokoll mit, setzt die Maschine fort und
|
||||
sagt deutlich, wenn statt des RAM-Standes kalt gebootet wurde.
|
||||
|
||||
Mit `--no-resume` lässt sich der Arbeitsspeicher bewusst weglassen — etwa, wenn
|
||||
[SPICE](dongle.md) gebraucht wird, das sich damit ausschließt.
|
||||
|
||||
---
|
||||
|
||||
## Der übliche Ablauf
|
||||
|
||||
<div class="ablauf" markdown>
|
||||
|
||||
**1.** [Austauschlaufwerk vorbereiten](transfer.md) — *vorher*, in Ruhe
|
||||
|
||||
**2.** [Maschine einrichten](einrichten.md) — Snapshot wählen, Optionen prüfen, anlegen
|
||||
|
||||
**3.** [Damit arbeiten](arbeiten.md) — noVNC-Konsole, Dump ziehen, Laufwerk auswerfen
|
||||
|
||||
**4.** [Verwerfen](verwerfen.md) — oder [dauerhaft übernehmen](loesen.md)
|
||||
|
||||
</div>
|
||||
|
||||
Bedient wird alles entweder über die ncurses-Oberfläche:
|
||||
|
||||
```bash
|
||||
pvesnap-recovery
|
||||
```
|
||||
|
||||
… oder direkt über Parameter:
|
||||
|
||||
```bash
|
||||
pvesnap-recovery live 101 # neuester Snapshot, abgeschottet
|
||||
pvesnap-recovery live 101 auto-stuendlich-20260809-100000
|
||||
pvesnap-recovery recover 101 --newid 9101 # mit Netzwerk
|
||||
pvesnap-recovery list
|
||||
pvesnap-recovery destroy 9101
|
||||
```
|
||||
|
||||
Vollständig unter [Alle Befehle](../nachschlagen/befehle.md#pvesnap-recovery).
|
||||
|
||||
---
|
||||
|
||||
## Was in der Übersicht steht
|
||||
|
||||
| Spalte | |
|
||||
|---|---|
|
||||
| **Maschine** | die neue VMID |
|
||||
| **Zustand** | `running`, `stopped` — oder `weg`, wenn sie außerhalb von pvesnap entfernt wurde |
|
||||
| **Node** | auf welchem Cluster-Knoten sie läuft |
|
||||
| **Herkunft** | Original-VMID und Snapshot, aus dem sie stammt |
|
||||
| **Modus** | `live` oder `recover` |
|
||||
|
||||
| Taste | |
|
||||
|---|---|
|
||||
| ++enter++ | [Detailansicht](arbeiten.md) |
|
||||
| ++n++ | [neue Wiederherstellung](einrichten.md) |
|
||||
| ++s++ / ++h++ | starten / herunterfahren |
|
||||
| ++x++ | [verwerfen](verwerfen.md) |
|
||||
| ++v++ | [Austauschlaufwerke](transfer.md) |
|
||||
| ++r++ | Liste neu einlesen |
|
||||
| ++q++ | Ende |
|
||||
|
||||
!!! tip "Wiederhergestellte Maschinen tragen einen Tag"
|
||||
|
||||
Jede von `pvesnap-recovery` angelegte Maschine bekommt in Proxmox den Tag
|
||||
**`pvesnap-recovery`**. Daran erkennt man sie in der Weboberfläche — und
|
||||
daran erkennt `destroy`, dass es sie anfassen darf. Eine von Hand angelegte
|
||||
VM lässt sich damit nicht versehentlich löschen.
|
||||
|
||||
Der Tag ist auch der Grund, warum
|
||||
`exclude_tags = nosnap, pvesnap-recovery` in jede `all`-Gruppe gehört, siehe
|
||||
[Auswahl](../sichern/auswahl.md#ausschlusse).
|
||||
@@ -0,0 +1,194 @@
|
||||
# Vom Snapshot lösen
|
||||
|
||||
Ein Linked Clone hängt für immer am Quell-Snapshot. Fürs Hineinschauen ist das
|
||||
ideal — es kostet nichts und geht in Sekunden. Für eine **dauerhaft übernommene**
|
||||
Maschine ist es ein Problem:
|
||||
|
||||
* der Quell-Snapshot lässt sich nicht mehr löschen — die
|
||||
[Vorhaltezeit](../sichern/vorhaltezeit.md) scheitert mit
|
||||
`snapshot is protected`
|
||||
* die Original-VM muss mitsamt ihrer Platte bestehen bleiben
|
||||
* der Klon wächst ohnehin mit jedem Schreibvorgang
|
||||
|
||||
Die Detailansicht sagt, woran man ist:
|
||||
|
||||
|
||||
|
||||
```
|
||||
Datentraeger: Linked Clone - haengt am Quell-Snapshot
|
||||
Belegt nur, was seither geschrieben wurde. Der Quell-Snapshot ist dafuer unloeschbar.
|
||||
Fuer den Dauerbetrieb mit f loesen (kopiert die Daten wirklich).
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Lösen
|
||||
|
||||
Taste ++f++ in der Detailansicht — oder:
|
||||
|
||||
```bash
|
||||
pvesnap-recovery flatten 9101
|
||||
```
|
||||
|
||||
Zuerst wird gemessen, wie viel kopiert werden muss:
|
||||
|
||||
|
||||
|
||||
Dahinter steckt `rbd flatten`: Die Daten aus dem Elternteil werden jetzt
|
||||
wirklich in den Klon kopiert. Danach hängt die Maschine an nichts mehr, und der
|
||||
Schutz der Quell-Snapshots wird **automatisch aufgehoben** — die Vorhaltezeit
|
||||
kommt wieder durch.
|
||||
|
||||
Schnell ist es, solange Platz da ist: 13 GB waren im Test in rund
|
||||
**70 Sekunden** kopiert.
|
||||
|
||||
---
|
||||
|
||||
## Die Maschine läuft dabei weiter
|
||||
|
||||
!!! success "`rbd flatten` ist eine Online-Operation"
|
||||
|
||||
Im Test blieb die VM über den gesamten Vorgang auf `qmpstatus: running`, der
|
||||
QEMU-Monitor antwortete durchgehend, und die Uhr auf der Konsole lief weiter
|
||||
— inklusive geladenem RAM-Zustand.
|
||||
|
||||
Auch Daten, die **während** des Abkoppelns geschrieben werden, überleben es.
|
||||
Gemessen an einem Container, der durchgehend schrieb:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| vor dem Flatten geschrieben | 64 MB Zufallsdaten, SHA-256 danach **OK** |
|
||||
| während des Flatten geschrieben | 192 MB Zufallsdaten, SHA-256 danach **OK** |
|
||||
| Schreibvorgänge im Zeitfenster | 12, von 19:35:48 bis 19:36:10 (Flatten: 19:35:48–19:36:11) |
|
||||
| Zustand des Gastes | durchgehend `running` |
|
||||
|
||||
Der Grund: `rbd flatten` füllt nur die Blöcke auf, die der Klon noch **nicht**
|
||||
selbst besitzt. Was der Gast bereits geschrieben hat, gehört ihm — und wird
|
||||
nicht überschrieben.
|
||||
|
||||
`flatten` betrifft also ausschließlich die *Abhängigkeit* vom Quell-Snapshot,
|
||||
nie die Verfügbarkeit.
|
||||
|
||||
---
|
||||
|
||||
## Der Platzbedarf — und warum `rbd du` täuscht
|
||||
|
||||
!!! warning "Nicht von der Snapshot-Zeile täuschen lassen"
|
||||
|
||||
Die Zeile eines Snapshots in `rbd du` zeigt nur dessen **Zuwachs**, nicht
|
||||
seinen Inhalt.
|
||||
|
||||
Im Test stand `@handtest01` mit `USED 56 MiB` da — kopiert wurden beim
|
||||
Flatten trotzdem über 8 GB. Denn sichtbar ist an dieser Stelle der gesamte
|
||||
Inhalt der Kette (`<TOTAL> 14 GiB`).
|
||||
|
||||
Deshalb misst `pvesnap-recovery flatten` das vorher richtig und nennt die
|
||||
Größe, bevor es losgeht.
|
||||
|
||||
### Es wird geprüft, ob der Platz reicht
|
||||
|
||||
!!! danger "Ein volllaufender Ceph-Pool blockiert alles"
|
||||
|
||||
Läuft der Pool während des Kopierens voll, blockiert er **jeden**
|
||||
Schreibvorgang. Dann steht nicht nur das Flatten, sondern jede VM auf diesem
|
||||
Storage — und selbst das Aufräumen wird schwierig, weil Löschen ebenfalls
|
||||
ein Schreibvorgang ist.
|
||||
|
||||
`flatten` bricht deshalb ab, wenn weniger als das **1,15-fache** des Bedarfs
|
||||
frei ist. `--force` setzt sich darüber hinweg.
|
||||
|
||||
Vorher selbst nachsehen:
|
||||
|
||||
```bash
|
||||
ceph df # MAX AVAIL beachten, nicht % RAW USED
|
||||
```
|
||||
|
||||
`% RAW USED` täuscht, weil es die Replikation nicht berücksichtigt: Bei
|
||||
dreifacher Replikation kosten 13 GB Nutzdaten 39 GB im Pool.
|
||||
|
||||
---
|
||||
|
||||
## Nachsehen, was los ist
|
||||
|
||||
```bash
|
||||
rbd -p <pool> ls -l | grep -E 'NAME|vm-9101' # Spalte PARENT
|
||||
rbd -p <pool> du | grep -E 'NAME|vm-9101' # PROVISIONED gegen USED
|
||||
```
|
||||
|
||||
Eine frisch geklonte 32-GB-Platte steht dort mit `PROVISIONED 32 GiB` und
|
||||
`USED 80 MiB` — die 80 MiB sind alles, was der laufende Gast seither geschrieben
|
||||
hat.
|
||||
|
||||
Nach dem Flatten ist die Spalte `PARENT` leer, und `USED` entspricht dem
|
||||
tatsächlichen Inhalt.
|
||||
|
||||
---
|
||||
|
||||
## Auf anderen Speicherarten
|
||||
|
||||
Das ganze Thema ist eine **Ceph-Eigenheit**. Andere Storages verhalten sich
|
||||
anders:
|
||||
|
||||
| Storage | Hängt am Quell-Snapshot? | `flatten` |
|
||||
|---|---|---|
|
||||
| `rbd` (Ceph) | **ja** — Snapshot wird geschützt und unlöschbar | nötig für den Dauerbetrieb |
|
||||
| `lvmthin` | **nein** | nicht nötig |
|
||||
| `zfspool` | ja | nicht möglich |
|
||||
|
||||
### LVM-thin ist hier angenehmer als Ceph
|
||||
|
||||
Ein Thin-Snapshot ist ein eigenständiges Volume, das sich mit anderen nur die
|
||||
Blöcke im Pool teilt. Nachgemessen:
|
||||
|
||||
```
|
||||
Belegung im Thin-Pool nach dem Klonen (256 MB Nutzdaten):
|
||||
data <19.84g 1.26 % ← Pool hält die Daten nur EINMAL
|
||||
snap_..._wdhtest 1.00g
|
||||
vm-9998-disk-0 1.00g 25.00 % Klon
|
||||
vm-9999-disk-0 1.00g 25.00 % Original
|
||||
|
||||
Quell-Snapshot löschen, während der Klon existiert → erlaubt
|
||||
Original löschen → erlaubt
|
||||
Prüfsumme des Klons danach → unverändert
|
||||
```
|
||||
|
||||
Also: platzsparend geteilt **und** trotzdem frei löschbar. `flatten` meldet
|
||||
solche Datenträger entsprechend als „nicht nötig".
|
||||
|
||||
Der Preis liegt woanders: `lvmthin` ist **lokaler** Speicher. Die
|
||||
Wiederherstellung muss auf demselben Node laufen wie das Original;
|
||||
`pvesnap-recovery` prüft das und lehnt einen anderen Node ab. Mit Ceph ist sie
|
||||
dagegen auf jedem Node des Clusters startbar.
|
||||
|
||||
!!! warning "Auch Thin-Pools laufen voll"
|
||||
|
||||
Und dann stehen alle Volumes darin. Überprovisionierung im Blick behalten:
|
||||
|
||||
```bash
|
||||
lvs -o lv_name,data_percent,metadata_percent
|
||||
```
|
||||
|
||||
### Bei ZFS geht es nicht
|
||||
|
||||
Der Klon hängt wie bei Ceph am Snapshot. `zfs promote` würde die Abhängigkeit
|
||||
nur **umdrehen** statt auflösen — danach hinge das Original am Klon, was das
|
||||
Problem nicht löst, sondern verschiebt.
|
||||
|
||||
Echte Unabhängigkeit ginge nur über eine Vollkopie per `zfs send | zfs recv`.
|
||||
Das macht `flatten` nicht, und es sagt das auch so:
|
||||
|
||||
```
|
||||
nicht moeglich - ein ZFS-Klon haengt am Snapshot. Loesen ginge nur
|
||||
ueber 'zfs send | zfs recv' in einen neuen Datentraeger
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Wann lösen, wann nicht?
|
||||
|
||||
| Lage | |
|
||||
|---|---|
|
||||
| Kurz hineinschauen, Dump ziehen, verwerfen | **nicht lösen.** Kostet nur Platz und Zeit. |
|
||||
| Die Maschine bleibt ein paar Tage stehen | **lösen**, sonst blockiert sie die Vorhaltezeit des Originals |
|
||||
| Die Maschine übernimmt dauerhaft | **lösen** — und zwar vor dem Löschen des Originals |
|
||||
| Auf LVM-thin | nichts zu tun |
|
||||
@@ -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).
|
||||
@@ -0,0 +1,228 @@
|
||||
# Austauschlaufwerke
|
||||
|
||||
Eine abgeschottete Wiederherstellung hat **kein Netzwerk**. Kein SCP, kein
|
||||
Netzlaufwerk, kein Cloud-Speicher. Wie kommt der Datenbank-Dump dann heraus?
|
||||
|
||||
Über ein **Austauschlaufwerk**: eine benannte Abbilddatei unter
|
||||
`/var/lib/pvesnap/transfer/`, die sich am Host ganz normal einhängen lässt und
|
||||
einem Gast als zusätzliche Platte angehängt wird.
|
||||
|
||||
```
|
||||
/var/lib/pvesnap/transfer/dumps.img 20G "Datenbank-Dumps und Exporte"
|
||||
/var/lib/pvesnap/transfer/werkzeuge.img 4G "Skripte, Treiber, Installer"
|
||||
```
|
||||
|
||||
!!! success "Der eigentliche Sinn: vorher, nicht mittendrin"
|
||||
|
||||
Ein Austauschlaufwerk gehört zu keiner Maschine und überlebt jede
|
||||
Wiederherstellung. Man legt es **einmal in Ruhe an**, packt hinein, was man
|
||||
im Notfall braucht — und wählt es im Ernstfall nur noch aus einer Liste aus.
|
||||
|
||||
Im Notfall ist keine Zeit, sich Werkzeuge zusammenzusuchen. Und die
|
||||
Maschine, in der man sie bräuchte, kommt nicht ins Netz.
|
||||
|
||||
---
|
||||
|
||||
## Die Übersicht
|
||||
|
||||
Taste ++v++ — erreichbar aus der Übersicht, aus der
|
||||
[Optionsmaske](einrichten.md#die-optionsmaske) und aus der
|
||||
[Detailansicht](arbeiten.md):
|
||||
|
||||
|
||||
|
||||
| Taste | |
|
||||
|---|---|
|
||||
| ++enter++ | am Host einhängen und im Commander öffnen |
|
||||
| ++n++ | neues Laufwerk anlegen |
|
||||
| ++u++ | am Host aushängen |
|
||||
| ++l++ | löschen |
|
||||
| ++r++ | neu einlesen |
|
||||
| ++q++ | zurück |
|
||||
|
||||
Die Spalte **Zustand** ist die wichtigste. Sie kennt drei Werte:
|
||||
|
||||
| Zustand | Farbe | bedeutet |
|
||||
|---|---|---|
|
||||
| `frei` | — | gehört niemandem, kann angehängt oder eingehängt werden |
|
||||
| `am Host eingehängt` | grün | liegt gerade unter `/run/pvesnap/transfer/<name>` |
|
||||
| `in Benutzung von 9101` | gelb | steckt in dieser Maschine |
|
||||
|
||||
---
|
||||
|
||||
## Ein Laufwerk anlegen
|
||||
|
||||
Taste ++n++, dann drei Fragen:
|
||||
|
||||
|
||||
|
||||
| Frage | |
|
||||
|---|---|
|
||||
| **Name** | kurz, klein geschrieben, z. B. `dumps`. Wird zur Bezeichnung im Gast (`DUMPS`). |
|
||||
| **Größe** | `20G`, `500M`, `2T` |
|
||||
| **Wofür** | freier Text, taucht in der Übersicht auf |
|
||||
|
||||
Dabei passiert:
|
||||
|
||||
1. Abbilddatei anlegen (dünn besetzt — sie belegt anfangs nichts)
|
||||
2. GPT-Partitionstabelle mit einer Partition, Typ `msftdata`
|
||||
3. exFAT-Dateisystem, Bezeichnung = Name in Großbuchstaben
|
||||
4. Rechte `0777` und eine `LIESMICH.txt` hineinlegen
|
||||
|
||||
!!! note "Die Größe ist eine Obergrenze, keine Reservierung"
|
||||
|
||||
Die Datei ist dünn besetzt: Ein 20-GB-Laufwerk mit 3 GB Inhalt belegt 3 GB
|
||||
auf dem Host. In der Übersicht stehen beide Zahlen nebeneinander —
|
||||
**Größe** und **belegt**.
|
||||
|
||||
---
|
||||
|
||||
## Befüllen und auslesen
|
||||
|
||||
++enter++ hängt das Laufwerk am Host ein und öffnet den
|
||||
[Commander](../holen/explorer.md) darauf:
|
||||
|
||||
|
||||
|
||||
Links das Laufwerk, rechts der Host. **Beide Seiten sind beschreibbar** — anders
|
||||
als beim Snapshot-Explorer, wo links Schreibschutz herrscht. Kopiert wird mit
|
||||
++f5++ in beide Richtungen.
|
||||
|
||||
Beim Verlassen mit ++q++ wird das Laufwerk automatisch wieder ausgehängt.
|
||||
|
||||
!!! tip "Was hineingehört"
|
||||
|
||||
Alles, was man im Gast bräuchte und dort nicht herunterladen kann:
|
||||
|
||||
* ein passendes `pg_dump` / `mysqldump` in der richtigen Version
|
||||
* ein Packprogramm (`7z.exe` für Windows-Gäste)
|
||||
* eigene Auswerteskripte
|
||||
* bei Windows die virtio-Treiber, falls die Maschine sie braucht
|
||||
* ein leeres Verzeichnis `ausgang/` für das, was herauskommen soll
|
||||
|
||||
---
|
||||
|
||||
## Host oder Gast, nie beides
|
||||
|
||||
Zwei unabhängige Einhängungen desselben Blockgeräts zerlegen das Dateisystem.
|
||||
Nicht „vielleicht" — zuverlässig, weil beide Seiten Puffer halten, von denen
|
||||
die andere nichts weiß.
|
||||
|
||||
Die Verwaltung lässt das deshalb nicht zu:
|
||||
|
||||
| Versuch | |
|
||||
|---|---|
|
||||
| Anhängen, während der Host es hält | abgelehnt |
|
||||
| Aushängen, während ein Gast darauf arbeitet | abgelehnt |
|
||||
| Löschen, solange es überhaupt in Benutzung ist | abgelehnt |
|
||||
|
||||
Woher sie das weiß: Sie liest die **Gast-Konfigurationen** unter
|
||||
`/etc/pve/nodes/*/`. Dort steht der Eintrag auch dann, wenn die Maschine gerade
|
||||
nicht läuft — was die Wahrheit besser trifft als jede Merkliste.
|
||||
|
||||
!!! info "Bei Containern ist es anders"
|
||||
|
||||
Dort ist es kein Blockgerät, sondern ein durchgereichtes Verzeichnis
|
||||
(Bind-Mount). Host und Container sehen dieselben Dateien **gleichzeitig** —
|
||||
es ist dasselbe Dateisystem, nicht zweimal eingehängt.
|
||||
|
||||
Dort gibt es also nichts auszuwerfen und nichts abzuwarten.
|
||||
|
||||
---
|
||||
|
||||
## Im laufenden Betrieb wechseln
|
||||
|
||||
Taste ++e++ in der [Detailansicht](arbeiten.md) zieht das Laufwerk bei laufender
|
||||
Maschine ab und gibt es wieder hinein — beliebig oft:
|
||||
|
||||
<div class="ablauf" markdown>
|
||||
|
||||
**auswerfen** → gehört wieder dem Host: einhängen, auslesen, neu befüllen
|
||||
|
||||
**einklinken** → zurück in denselben Steckplatz, die VM läuft durchgehend
|
||||
|
||||
</div>
|
||||
|
||||
Das ist der Weg, ohne die Maschine anzufassen an Zwischenergebnisse zu kommen —
|
||||
Dump ziehen, abholen, weitermachen.
|
||||
|
||||
!!! warning "Im Gast vorher aushängen"
|
||||
|
||||
Unter Linux `umount`, unter Windows „Auswerfen" im Explorer.
|
||||
|
||||
Proxmox meldet das Gerät zwar ordentlich ab, aber ein Dateisystem, auf das
|
||||
gerade geschrieben wird, nimmt das übel. Hält der Gast es fest, schlägt das
|
||||
Auswerfen mit einer entsprechenden Meldung fehl — dann erst im Gast
|
||||
aushängen und noch einmal.
|
||||
|
||||
Die Detailansicht zeigt jederzeit, was steckt:
|
||||
|
||||
```
|
||||
Transfer-Laufwerke:
|
||||
dumps eingesteckt als scsi1
|
||||
e = auswerfen / einklinken, im laufenden Betrieb
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Warum exFAT
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Windows und Linux** lesen und schreiben es von Haus aus | kein Treiber, keine Nachinstallation im Gast |
|
||||
| **Keine 4-GB-Grenze** je Datei | ein 30-GB-Dump passt |
|
||||
| **Keine Besitzrechte auf der Platte** | keine Rechteprobleme zwischen Host und Gast, keine `chown`-Runden |
|
||||
|
||||
Die Bezeichnung darf höchstens **11 Zeichen** haben — daher der Rat, den Namen
|
||||
kurz zu halten. Eingehängt wird mit `umask=0000`, damit auch ein
|
||||
unprivilegierter Container hineinschreiben kann (dessen `root` ist auf dem Host
|
||||
die UID 100000).
|
||||
|
||||
### Warum eine Datei und kein Proxmox-Volume?
|
||||
|
||||
!!! danger "Ein Volume würde mitgelöscht"
|
||||
|
||||
Beim Entfernen der Maschine — auch aus der Proxmox-Weboberfläche heraus.
|
||||
Die mühsam vorbereitete Werkzeugsammlung wäre weg, und zwar genau in dem
|
||||
Moment, in dem jemand aufräumt.
|
||||
|
||||
Pfade überspringt PVE beim Zerstören ausdrücklich:
|
||||
`return if $volid =~ m|^/|`. Deshalb eine Datei.
|
||||
|
||||
Angehängt wird über ein **Loop-Gerät**, weil Proxmox als Pfad nur `/dev/…`
|
||||
akzeptiert — eine Abbilddatei direkt einzutragen lehnt es ab
|
||||
(`unable to associate path to any storage`).
|
||||
|
||||
Die GPT-Partition trägt bewusst den Typ `msftdata`. Ohne diese Angabe vergibt
|
||||
`parted` den Typ „Linux filesystem", und Windows gibt dem Laufwerk dann keinen
|
||||
Buchstaben.
|
||||
|
||||
---
|
||||
|
||||
## Auf der Kommandozeile
|
||||
|
||||
```bash
|
||||
pvesnap-recovery live 101 --transfer werkzeuge --transfer dumps
|
||||
```
|
||||
|
||||
Mehrfach möglich. Die Laufwerke müssen frei sein, sonst bricht das Anlegen mit
|
||||
einer Meldung ab.
|
||||
|
||||
Angelegt und verwaltet werden sie nur über die Oberfläche — dafür gibt es
|
||||
bewusst keine Parameter. Das ist eine Vorbereitungsaufgabe, keine, die man
|
||||
unter Zeitdruck tippt.
|
||||
|
||||
---
|
||||
|
||||
## Wo sie liegen
|
||||
|
||||
```
|
||||
/var/lib/pvesnap/transfer/index.json Verzeichnis der Laufwerke
|
||||
/var/lib/pvesnap/transfer/dumps.img die Abbilddatei
|
||||
/run/pvesnap/transfer/dumps Einhängepunkt am Host
|
||||
```
|
||||
|
||||
!!! warning "`uninstall.sh --purge` nimmt sie mit"
|
||||
|
||||
Ohne `--purge` bleibt alles liegen. Mit `--purge` ist auch der Inhalt der
|
||||
Austauschlaufwerke weg. Siehe [Installation](../installation.md#deinstallation).
|
||||
@@ -0,0 +1,146 @@
|
||||
# Verwerfen und aufräumen
|
||||
|
||||
## Verwerfen
|
||||
|
||||
Taste ++x++ in der Übersicht oder in der Detailansicht:
|
||||
|
||||
|
||||
|
||||
Oder auf der Kommandozeile:
|
||||
|
||||
```bash
|
||||
pvesnap-recovery destroy 9101
|
||||
pvesnap-recovery destroy 9101 -y # ohne Rückfrage
|
||||
```
|
||||
|
||||
`destroy` räumt vollständig auf:
|
||||
|
||||
<div class="ablauf" markdown>
|
||||
|
||||
**1.** Maschine stoppen
|
||||
|
||||
**2.** Gast samt aller Klone entfernen
|
||||
|
||||
**3.** Austauschlaufwerke freigeben (der **Inhalt bleibt** — sie gehören zu
|
||||
keiner Maschine)
|
||||
|
||||
**4.** Den **Schutz der Quell-Snapshots wieder aufheben**
|
||||
|
||||
**5.** Eintrag aus der Merkliste nehmen
|
||||
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
### Schritt 4 ist der wichtige
|
||||
|
||||
!!! info "Warum der Snapshot-Schutz wieder weg muss"
|
||||
|
||||
Ceph verlangt für einen Klon, dass der Quell-Snapshot geschützt ist
|
||||
(`rbd snap protect`), und Proxmox setzt das beim Klonen selbst.
|
||||
|
||||
Bliebe der Schutz stehen, könnte die [Vorhaltezeit](../sichern/vorhaltezeit.md)
|
||||
diesen Snapshot später nicht mehr löschen — im Protokoll stünde dann immer
|
||||
wieder:
|
||||
|
||||
```
|
||||
snapshot is protected
|
||||
```
|
||||
|
||||
Solange eine Wiederherstellung existiert, ist ihr Quell-Snapshot also
|
||||
**bewusst** unlöschbar. Danach nicht mehr.
|
||||
|
||||
---
|
||||
|
||||
### Was `destroy` nicht anfasst
|
||||
|
||||
!!! success "Nur Maschinen mit dem Tag `pvesnap-recovery`"
|
||||
|
||||
Eine von Hand angelegte VM lässt sich damit nicht versehentlich löschen —
|
||||
auch dann nicht, wenn sie zufällig eine VMID hat, die einmal einer
|
||||
Wiederherstellung gehörte.
|
||||
|
||||
**Austauschlaufwerke bleiben.** Sie gehören zu keiner Maschine; ihr Inhalt
|
||||
überlebt jede Wiederherstellung. Sie werden nur wieder als `frei` markiert.
|
||||
|
||||
**Das Original bleibt.** Selbstverständlich — `destroy` fasst ausschließlich die
|
||||
Wiederherstellung an.
|
||||
|
||||
---
|
||||
|
||||
## `cleanup`
|
||||
|
||||
Wird eine Wiederherstellung in der **Proxmox-Oberfläche** entfernt statt mit
|
||||
`destroy`, bleibt etwas liegen:
|
||||
|
||||
* der Klon selbst kann übrigbleiben
|
||||
* der Quell-Snapshot bleibt **geschützt** — die Vorhaltezeit scheitert dann
|
||||
dauerhaft
|
||||
|
||||
```bash
|
||||
pvesnap-recovery cleanup # zeigt Gefundenes, fragt, räumt auf
|
||||
pvesnap-recovery cleanup --all # auch Datenträger ohne Elternteil
|
||||
pvesnap-recovery cleanup -y # ohne Rückfrage
|
||||
```
|
||||
|
||||
### Wonach gesucht wird
|
||||
|
||||
Nach Datenträgern der Form `vm-<id>-disk-N`, zu deren VMID es **keine
|
||||
Konfigurationsdatei** unter `/etc/pve/nodes/*/` mehr gibt.
|
||||
|
||||
!!! info "Bewusst nicht über `/cluster/resources`"
|
||||
|
||||
Ein Gast auf einem abgemeldeten Node taucht dort unter Umständen nicht auf
|
||||
— und dann würden die Platten einer **lebenden** Maschine als verwaist
|
||||
gelten.
|
||||
|
||||
Die Konfigurationsdateien im Cluster-Dateisystem sind die verlässlichere
|
||||
Quelle.
|
||||
|
||||
Zwei weitere Vorsichtsmaßnahmen:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **Ohne Elternteil** wird nichts von selbst entfernt | dafür braucht es `--all` |
|
||||
| **Der Schutz eines Snapshots wird nur gelöst**, wenn wirklich kein Klon mehr daran hängt | sonst würde ein noch lebender Klon seine Grundlage verlieren |
|
||||
|
||||
### Wann man es braucht
|
||||
|
||||
* Jemand hat eine Wiederherstellung in der Weboberfläche gelöscht
|
||||
* Ein `destroy` ist mittendrin abgebrochen (Host neu gestartet, Netz weg)
|
||||
* Im Protokoll des Dienstes taucht wiederholt `snapshot is protected` auf
|
||||
|
||||
Der letzte Fall ist der häufigste — und der, den man sonst lange sucht.
|
||||
|
||||
---
|
||||
|
||||
## Aufräumen prüfen
|
||||
|
||||
```bash
|
||||
pvesnap-recovery list # sind noch welche eingetragen?
|
||||
qm list | grep -i recovery # laufen noch welche?
|
||||
rbd -p <pool> ls | grep -E 'vm-9[0-9]{3}-' # liegen noch Klone herum?
|
||||
rbd -p <pool> snap ls vm-101-disk-0 # steht noch ein Schutz?
|
||||
```
|
||||
|
||||
Bei der letzten Ausgabe steht in der Spalte `PROTECTED` ein `yes`, solange ein
|
||||
Snapshot geschützt ist. Ohne zugehörigen Klon ist das ein Fall für `cleanup`.
|
||||
|
||||
---
|
||||
|
||||
## Vor der Deinstallation
|
||||
|
||||
`uninstall.sh` warnt, wenn noch Wiederherstellungen offen sind. Der Grund ist
|
||||
derselbe:
|
||||
|
||||
!!! warning "Erst verwerfen, dann deinstallieren"
|
||||
|
||||
Nach dem Entfernen von pvesnap gibt es kein `destroy` und kein `cleanup`
|
||||
mehr. Die Klone müsste man dann von Hand aufspüren, und den Snapshot-Schutz
|
||||
von Hand lösen:
|
||||
|
||||
```bash
|
||||
rbd -p <pool> snap unprotect vm-101-disk-0@auto-stuendlich-20260809-100000
|
||||
```
|
||||
|
||||
Mit Werkzeug ist das ein Tastendruck. Ohne eine Stunde Sucherei.
|
||||
Reference in New Issue
Block a user