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,192 @@
|
||||
# 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](../sichern/vorhaltezeit.md) scheitert an ihm
|
||||
mit `snapshot is protected`.
|
||||
|
||||
pvesnap geht damit sauber um: Beim [Verwerfen](../wiederherstellen/verwerfen.md)
|
||||
wird der Schutz wieder aufgehoben, und
|
||||
[`flatten`](../wiederherstellen/loesen.md) löst die Abhängigkeit ganz.
|
||||
|
||||
### Platz im Blick
|
||||
|
||||
```bash
|
||||
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.
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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](../wiederherstellen/einrichten.md#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. |
|
||||
Reference in New Issue
Block a user