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](../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.

---

## 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`](../sichern/vorhaltezeit.md#platz-vor-dem-snapshot).
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

```bash
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:

```bash
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:

```bash
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 %:

```bash
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:

```bash
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. |