proxmox-snapshot-service/handbuch/docs/nachschlagen/speicher.md

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.

---

Früher „voll“ sagen, damit Luft zum Löschen bleibt

Auf einem wirklich vollen Speicher stehen die VMs, und auch das Aufräumen kann scheitern, weil Löschen selbst ein Schreibvorgang ist. Deshalb lohnt es sich, den Speicher schon bei etwa 80 % als voll zu behandeln. Im Notfall gibt man die Grenze kurz frei, räumt auf und setzt sie wieder zurück.

Das gilt zusätzlich zu space_min_free. Beide Grenzen wirken aufeinander: space_min_free rechnet mit dem, was Proxmox als frei meldet, und das schrumpft mit der Grenze. Auf einem Test-Cluster sank MAX AVAIL mit full = 0.80 von 41 auf 29 GiB. Bei einer Grenze von 80 % passt deshalb space_min_free = 15% besser als die Vorgabe: pvesnap greift dann bei etwa 70 % der vollsten OSD ein, mit der Vorgabe von 20 % schon bei etwa 65 %.

Ceph: die Ratios

ceph osd dump | grep ratio     # aktuelle Werte
ceph df                        # MAX AVAIL je Pool
ceph osd df                    # Belegung je OSD; die vollste entscheidet
ceph health detail             # wer ist nearfull, backfillfull, full?

Ratio	Vorgabe	Was passiert, wenn eine OSD sie erreicht
nearfull	0.85	nur eine Warnung
backfillfull	0.90	Ceph verschiebt keine Daten mehr auf diese OSD
full	0.95	Schreibvorgänge der VMs hängen, bis wieder Platz da ist

Einrichten, Beispiel „voll bei 80 %“. Die Werte müssen aufsteigend bleiben und gelten sofort, ohne Neustart:

ceph osd set-nearfull-ratio 0.70
ceph osd set-backfillfull-ratio 0.75
ceph osd set-full-ratio 0.80

Im Notfall, wenn der Cluster full meldet:

pvesnap list -a                        # was belegt den Platz?
qm delsnapshot <vmid> <snapshot>       # zuerst einfach versuchen
ceph -s                                # löst sich full von selbst?

ceph osd set-full-ratio 0.90           # wenn es hängt, oder die VMs sofort weiter sollen
ceph osd set-full-ratio 0.80           # nach dem Aufräumen sofort zurück

Bei einem Test mit Ceph 18.2 ging das Löschen trotz full durch: Snapshot und ganze Platte waren nach Sekunden weg, der Platz nach 15 Sekunden zurück, full löste sich von selbst, und die VMs konnten weiterschreiben. Das Anheben allein ließ die hängenden Schreibvorgänge ebenfalls sofort weiterlaufen.

Verlassen sollte man sich darauf nicht. Der Test setzte full knapp unter die Belegung, die OSDs hatten also noch reichlich echten Platz. Auf wirklich vollen OSDs kann es anders aussehen, und ein früherer Vorfall mit einem vollgelaufenen Pool lief genau so: Auch Löschen stand.

!!! danger "Nie über 0.96"

Ab dem Failsafe-Wert (`ceph config get osd osd_failsafe_full_ratio`, Vorgabe
`0.97`) verweigern die OSDs selbst das Schreiben, egal was `full` sagt. Und
läuft eine OSD wirklich auf 100 %, startet sie unter Umständen nicht mehr.
Das Anheben ist keine Lösung, es verschafft nur Zeit zum Aufräumen.

!!! warning "Eine niedrige Grenze hat einen Preis"

Fällt ein Node aus, verteilt Ceph seine Daten auf die übrigen. Das hält bei
`backfillfull` an, mit `0.75` also früher, und der Cluster bleibt dann
ungeschützt, bis Platz da ist oder die Ratio angehoben wird. Bei 4 Nodes und
3 Replikaten steigt die Belegung durch den Ausfall um ein Drittel.

ZFS: die Notreserve

ZFS hat keine solche Ratio. Die Grenze muss man vorher einrichten, im Ernstfall lässt sie sich nicht mehr nachholen. Am einfachsten ist ein leeres Dataset, das Platz reserviert. Beispiel: ein Pool tank mit 10 TiB, voll bei 80 %:

zpool list tank       # Größe des Pools
zfs create -o refreservation=2T -o canmount=off -o mountpoint=none tank/notreserve
zfs list -o name,used,avail tank tank/notreserve

Im Notfall, wenn VMs No space left on device melden:

zfs set refreservation=none tank/notreserve   # Reserve freigeben

pvesnap list -a                               # was belegt den Platz?
zfs list -t snapshot -o name,used -s used     # die größten Snapshots zuletzt
qm delsnapshot <vmid> <snapshot>              # aufräumen

zfs set refreservation=2T tank/notreserve     # danach sofort zurück

Das Zurücksetzen gelingt erst, wenn genug Platz da ist. Sonst meldet ZFS size is greater than available space, dann muss weiter aufgeräumt werden.

Was man dabei sieht (gemessen an einem kleinen Testpool mit 200 MiB Reserve, vollgeschrieben):

Stelle	Anzeige
zpool list	CAP 65 %	die echte Belegung der Laufwerke, die Reserve zählt nicht
zfs list	AVAIL 0	das ist die Grenze, an die die VMs stoßen
Proxmox-Storage auf einem Dataset (tank/data)	100 % von 631 MiB	die Gesamtgröße schrumpft um die Reserve
Proxmox-Storage auf dem Pool selbst (tank)	100 % von 832 MiB	Gesamtgröße bleibt, die Reserve zählt als belegt

Der Pool wird dabei nicht schreibgeschützt. Lesen geht weiter, neue Daten scheitern mit No space left on device, und das Löschen von Dateien und Snapshots klappte im Test auch ohne Freigabe der Reserve. Für die VMs ist das trotzdem ein Ausfall: Sie bekommen Schreibfehler, und je nach Einstellung hält Proxmox sie an.

!!! note "Alternative: Quota"

`zfs set quota=8T tank/data` wirkt genauso und zählt Snapshots mit, begrenzt
aber nur dieses Dataset und seine Kinder. Im Notfall `zfs set quota=9T tank/data`.
Die Notreserve ist einfacher, weil sie unabhängig vom Aufbau des Pools für alles
gilt.

!!! warning "Dick angelegte Zvols: Ein Snapshot kostet sofort Platz"

Ohne `sparse` am Storage reserviert Proxmox die ganze Platte, und diese
Reservierung muss auch nach dem Snapshot gelten. Alles, was seit dem letzten
Snapshot geschrieben wurde, wird deshalb beim Anlegen zusätzlich belegt. Fehlt
der Platz, scheitert der Snapshot mit `out of space`. Bei dünn angelegten Zvols
(`sparse 1`) kostet er nichts.

Das lässt sich exakt ausrechnen:

```bash
zfs get -Hp refreservation,usedbyrefreservation tank/data/vm-100-disk-0
# Kosten = refreservation - usedbyrefreservation
```

pvesnap rechnet genau das ein und prüft `frei ≥ Kosten + space_min_free`, die
Reserve bleibt also auch nach dem Snapshot frei. `pvesnap --dry-run run --force`
zeigt die Rechnung, ohne etwas zu ändern:

```
VM 100 (web): 'zfs': 1.1G frei, Snapshot belegt sofort 100.6M, danach frei 992.2M, Reserve 50.0M
```

Die Werte liefert die Proxmox-API nicht. Läuft der Gast auf einem anderen Node,
fragt pvesnap sie per `ssh` ab, über den Schlüssel, den Proxmox im Cluster ohnehin
einrichtet. Klappt das nicht, steht eine Warnung im Protokoll und das Volume zählt
mit 0, gelöscht wird deswegen nichts.

Das Löschen alter Snapshots gibt bei Zvols nur frei, was allein dieser Snapshot
festhält. Überschreibt eine VM immer dieselben Blöcke, ist das viel, sonst wenig.

---

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.