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>
6.0 KiB
Speicherarten
Nicht jedes Proxmox-Storage kann alles. Diese Seite fasst zusammen, was wo geht.
Die Übersicht
| Storage | Snapshots | Dateien lesen | Als Maschine starten | Vom Snapshot lösen |
|---|---|---|---|---|
rbd (Ceph) |
✅ | ✅ | ✅ | ✅ nötig |
zfspool |
✅ | ✅ | ✅ | ❌ nicht möglich |
lvmthin |
✅ | ✅ | ✅ | — nicht nötig |
lvm (dick) |
❌ | — | — | — |
dir, nfs, cifs (qcow2) |
✅ | ✅ | ❌ | — |
dir, nfs, cifs (raw) |
❌ | — | — | — |
Ceph / RBD
Die beste Grundlage für pvesnap. Alles geht, und es geht clusterweit.
| Snapshot | rbd snap create, sofort |
| Hineinsehen | rbd map pool/image@snap, bei nicht unterstützten Image-Features über rbd-nbd |
| Klonen | rbd clone, in etwa einer Sekunde — unabhängig von der Größe |
| Wiederherstellung startbar auf | jedem Node des Clusters (geteiltes Storage) |
Die eine Eigenheit
RBD verlangt für einen Klon, dass der Quell-Snapshot geschützt ist
(rbd snap protect). Solange ein Klon existiert, ist der Snapshot damit
unlöschbar, und die Vorhaltezeit scheitert an ihm
mit snapshot is protected.
pvesnap geht damit sauber um: Beim Verwerfen
wird der Schutz wieder aufgehoben, und
flatten löst die Abhängigkeit ganz.
Platz im Blick
ceph df # MAX AVAIL beachten
rbd -p <pool> du
rbd -p <pool> ls -l # Spalte PARENT zeigt Klone
!!! danger "% RAW USED täuscht"
Es berücksichtigt die Replikation nicht. Bei dreifacher Replikation kosten
13 GB Nutzdaten 39 GB im Pool. **`MAX AVAIL`** ist die Zahl, die zählt.
Läuft ein Pool voll, blockiert er jeden Schreibvorgang — und damit alle VMs
darauf. Selbst das Aufräumen wird dann schwierig, weil Löschen ebenfalls
ein Schreibvorgang ist.
ZFS
| Snapshot | zfs snapshot, sofort |
| Hineinsehen | Container direkt über .zfs/snapshot/…, VMs über einen temporären Klon |
| Klonen | zfs clone, sofort |
| Wiederherstellung startbar auf | dem Node mit dem Pool (bzw. clusterweit bei ZFS over iSCSI) |
Lösen geht nicht
Der Klon hängt wie bei Ceph am Snapshot. zfs promote würde die Abhängigkeit
nur umdrehen — danach hinge das Original am Klon. Das verschiebt das
Problem, statt es zu lösen.
Echte Unabhängigkeit ginge nur über zfs send | zfs recv in einen neuen
Datenträger. Das macht flatten nicht und sagt es auch so.
zfs list -o space # USEDSNAP zeigt, was die Snapshots kosten
zfs list -t snapshot
LVM-thin
In einem Punkt angenehmer als Ceph: Ein Thin-Snapshot ist ein eigenständiges Volume, das sich mit anderen nur die Blöcke im Pool teilt.
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
Platzsparend geteilt und trotzdem frei löschbar. Es gibt dort weder geschützte Snapshots noch etwas zu flatten.
Der Preis: lokaler Speicher
lvmthin liegt auf einem einzelnen Node. Die Wiederherstellung muss auf
demselben Node laufen wie das Original; pvesnap-recovery prüft das und lehnt
einen anderen Node ab.
!!! 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
```
Besonders die **Metadaten** — läuft der Metadatenbereich voll, ist der Pool
nicht mehr zu retten, auch wenn noch Datenplatz frei ist.
LVM (dick)
Proxmox kann dort gar keine Snapshots. Betroffene VMs melden im Protokoll:
storage does not support snapshots
Sie werden übersprungen, die übrigen laufen normal weiter.
Der Ausweg ist ein Umzug auf lvmthin — technisch derselbe Speicher, nur mit
Thin-Provisioning:
qm move-disk 101 scsi0 <thin-storage>
Verzeichnis-Storages (dir, nfs, cifs)
Hier kommt es auf das Dateiformat an:
| Format | Snapshots | |
|---|---|---|
qcow2 |
✅ | interne Snapshots im Abbild selbst |
raw |
❌ | keine Snapshot-Fähigkeit |
vmdk |
❌ |
Hineinsehen: ja
qemu-nbd --load-snapshot bindet den Snapshot schreibgeschützt ein. Explorer
und Web-Oberfläche funktionieren also.
Als Maschine starten: nein
!!! warning "Kein Klon aus einem qcow2-internen Snapshot"
Ein qcow2-interner Snapshot lässt sich nicht als eigenständiges Volume
klonen. `pvesnap-recovery` lehnt das ab und verweist auf den Explorer.
Wer die Fähigkeit braucht, verschiebt die VM auf ein Storage, das Klone
kann — Ceph, ZFS oder LVM-thin.
Was passiert bei gemischten Datenträgern?
Hat eine VM Platten auf verschiedenen Storages, gilt für die Wiederherstellung die strengste Regel:
- Liegt eine Platte auf einem Storage, das keine Klone kann, geht es gar nicht
- Liegt eine Platte auf lokalem Storage, ist der Node festgelegt
- Ist ein Storage auf dem Zielnode nicht verfügbar, wird abgelehnt
Die Zusammenfassung nennt den Grund, bevor etwas angelegt wird.
Empfehlung
| Lage | |
|---|---|
| Cluster mit Ceph | Ideal. Alles geht, von jedem Node aus. Nur an flatten denken, wenn eine Wiederherstellung bleibt. |
| Einzelner Host | lvmthin oder ZFS. LVM-thin ist beim Lösen unkomplizierter, ZFS bietet dafür Prüfsummen und zfs send. |
| NFS-Storage | qcow2 statt raw verwenden, dann geht wenigstens das Lesen. Für Wiederherstellungen ist es die falsche Grundlage. |
| LVM dick | Auf lvmthin umstellen. Ohne Snapshot-Fähigkeit hat pvesnap dort nichts zu tun. |