# 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. |