duffyduckandClaude Opus 5
59e7224297
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>
3.3 KiB
Daten zurückholen
Ein Snapshot ist kein Verzeichnis. Er liegt als Blockgerät oder als Eintrag im qcow2-Kopf im Storage, und dort kann man nicht einfach hineinsehen.
pvesnap nimmt einem das ab: Der Snapshot wird schreibgeschützt eingebunden und gemountet, und danach ist er ein ganz gewöhnlicher Pfad.
Drei Wege hinein
| wofür | |
|---|---|
| Der Explorer | Auf dem Host, im Terminal. Zwei Fenster wie im Midnight Commander. Der schnellste Weg, wenn man ohnehin per SSH angemeldet ist. |
| Die Web-Oberfläche | Im Browser, auch vom Arbeitsplatz. Anmeldung mit den Proxmox-Benutzern. Verzeichnisse kommen als ZIP. |
| Als Maschine starten | Wenn Dateien nicht reichen — eine Datenbank etwa wird erst brauchbar, wenn ihr Server läuft und selbst einen Dump schreibt. |
Die ersten beiden lesen nur. Sie können nichts kaputt machen.
Was dabei im Hintergrund passiert
Je nach Storage geht es unterschiedlich hinein:
| Storage | Weg |
|---|---|
rbd (Ceph) |
rbd map pool/image@snap; bei nicht unterstützten Image-Features über rbd-nbd |
zfspool |
Container direkt über .zfs/snapshot/…, VMs über einen temporären Klon |
lvmthin, lvm |
die Snapshot-LV snap_<volume>_<snapname> aktivieren |
dir, nfs, cifs |
qemu-nbd --load-snapshot — nur bei qcow2 |
Danach werden die Partitionen erkannt und gemountet, und zwar mit
ro,noload bzw. ro,norecovery,nouuid.
!!! info "Warum diese Optionen wichtig sind"
Der Snapshot einer **laufenden** Maschine hat fast immer ein unsauberes
Journal — die VM war ja mitten in der Arbeit. Ohne `noload` bzw.
`norecovery` würde der Kernel das Journal abspielen wollen, also
**schreiben**. In einen Snapshot, der schreibgeschützt sein soll.
Deshalb wird bewusst darauf verzichtet. Die Folge: Die letzten Sekunden vor
dem Snapshot können in den Dateien fehlen, auch wenn sie im Journal stünden.
Für eine Datenbank ist das der Grund, den Weg über
[`pvesnap-recovery`](../wiederherstellen/index.md) zu nehmen — dort startet
der Datenbankserver und räumt selbst auf.
Aufräumen
Beim Beenden wird alles wieder ausgehängt — automatisch, auch beim Verlassen über ++q++ oder ++ctrl+c++.
Bleibt nach einem Absturz etwas hängen:
pvesnap-explorer --cleanup
pvesnap-web --cleanup
Beide räumen dieselben Reste weg: Einbindungen unter /run/pvesnap/,
rbd-Zuordnungen, NBD-Geräte, temporäre ZFS-Klone.
Nachsehen, ob wirklich nichts mehr liegt:
findmnt | grep pvesnap
rbd showmapped
losetup -a
ls /run/pvesnap/
Was nicht geht
!!! warning "Schreiben"
In einen Snapshot hinein geht nichts. Kein Kopieren, kein Löschen, kein
Umbenennen. Das ist keine Vorsichtsmaßnahme, sondern eine Eigenschaft der
Sache: Ein Snapshot ist ein festgehaltener Stand.
Wer einen Stand **ändern** will, um daraus weiterzuarbeiten, braucht
[`pvesnap-recovery`](../wiederherstellen/index.md) — dort entsteht ein Klon,
der voll beschreibbar ist.
!!! warning "Verschlüsselte Dateisysteme"
LUKS, BitLocker oder eine verschlüsselte Datenbankpartition bleiben auch im
Snapshot verschlüsselt. Es gibt keinen Weg daran vorbei — die Daten müssen
im laufenden Gast entschlüsselt werden. Auch das ist ein Fall für
`pvesnap-recovery`.