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>
96 lines
3.3 KiB
Markdown
96 lines
3.3 KiB
Markdown
# 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**](explorer.md) | 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**](web.md) | Im Browser, auch vom Arbeitsplatz. Anmeldung mit den Proxmox-Benutzern. Verzeichnisse kommen als ZIP. |
|
|
| [**Als Maschine starten**](../wiederherstellen/index.md) | 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:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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`.
|