# Vom Snapshot lösen

Ein Linked Clone hängt für immer am Quell-Snapshot. Fürs Hineinschauen ist das
ideal — es kostet nichts und geht in Sekunden. Für eine **dauerhaft übernommene**
Maschine ist es ein Problem:

* der Quell-Snapshot lässt sich nicht mehr löschen — die
  [Vorhaltezeit](../sichern/vorhaltezeit.md) scheitert mit
  `snapshot is protected`
* die Original-VM muss mitsamt ihrer Platte bestehen bleiben
* der Klon wächst ohnehin mit jedem Schreibvorgang

Die Detailansicht sagt, woran man ist:

![Linked Clone in der Detailansicht](../bilder/recovery-detail.svg)

```
Datentraeger: Linked Clone - haengt am Quell-Snapshot
  Belegt nur, was seither geschrieben wurde. Der Quell-Snapshot ist dafuer unloeschbar.
  Fuer den Dauerbetrieb mit  f  loesen (kopiert die Daten wirklich).
```

---

## Lösen

Taste ++f++ in der Detailansicht — oder:

```bash
pvesnap-recovery flatten 9101
```

Zuerst wird gemessen, wie viel kopiert werden muss:

![Der Lösen-Dialog mit der Größe](../bilder/recovery-loesen.svg)

Dahinter steckt `rbd flatten`: Die Daten aus dem Elternteil werden jetzt
wirklich in den Klon kopiert. Danach hängt die Maschine an nichts mehr, und der
Schutz der Quell-Snapshots wird **automatisch aufgehoben** — die Vorhaltezeit
kommt wieder durch.

Schnell ist es, solange Platz da ist: 13 GB waren im Test in rund
**70 Sekunden** kopiert.

---

## Die Maschine läuft dabei weiter

!!! success "`rbd flatten` ist eine Online-Operation"

    Im Test blieb die VM über den gesamten Vorgang auf `qmpstatus: running`, der
    QEMU-Monitor antwortete durchgehend, und die Uhr auf der Konsole lief weiter
    — inklusive geladenem RAM-Zustand.

Auch Daten, die **während** des Abkoppelns geschrieben werden, überleben es.
Gemessen an einem Container, der durchgehend schrieb:

| | |
|---|---|
| vor dem Flatten geschrieben | 64 MB Zufallsdaten, SHA-256 danach **OK** |
| während des Flatten geschrieben | 192 MB Zufallsdaten, SHA-256 danach **OK** |
| Schreibvorgänge im Zeitfenster | 12, von 19:35:48 bis 19:36:10 (Flatten: 19:35:48–19:36:11) |
| Zustand des Gastes | durchgehend `running` |

Der Grund: `rbd flatten` füllt nur die Blöcke auf, die der Klon noch **nicht**
selbst besitzt. Was der Gast bereits geschrieben hat, gehört ihm — und wird
nicht überschrieben.

`flatten` betrifft also ausschließlich die *Abhängigkeit* vom Quell-Snapshot,
nie die Verfügbarkeit.

---

## Der Platzbedarf — und warum `rbd du` täuscht

!!! warning "Nicht von der Snapshot-Zeile täuschen lassen"

    Die Zeile eines Snapshots in `rbd du` zeigt nur dessen **Zuwachs**, nicht
    seinen Inhalt.

    Im Test stand `@handtest01` mit `USED 56 MiB` da — kopiert wurden beim
    Flatten trotzdem über 8 GB. Denn sichtbar ist an dieser Stelle der gesamte
    Inhalt der Kette (`<TOTAL> 14 GiB`).

    Deshalb misst `pvesnap-recovery flatten` das vorher richtig und nennt die
    Größe, bevor es losgeht.

### Es wird geprüft, ob der Platz reicht

!!! danger "Ein volllaufender Ceph-Pool blockiert alles"

    Läuft der Pool während des Kopierens voll, blockiert er **jeden**
    Schreibvorgang. Dann steht nicht nur das Flatten, sondern jede VM auf diesem
    Storage — und selbst das Aufräumen wird schwierig, weil Löschen ebenfalls
    ein Schreibvorgang ist.

`flatten` bricht deshalb ab, wenn weniger als das **1,15-fache** des Bedarfs
frei ist. `--force` setzt sich darüber hinweg.

Vorher selbst nachsehen:

```bash
ceph df                    # MAX AVAIL beachten, nicht % RAW USED
```

`% RAW USED` täuscht, weil es die Replikation nicht berücksichtigt: Bei
dreifacher Replikation kosten 13 GB Nutzdaten 39 GB im Pool.

---

## Nachsehen, was los ist

```bash
rbd -p <pool> ls -l | grep -E 'NAME|vm-9101'   # Spalte PARENT
rbd -p <pool> du    | grep -E 'NAME|vm-9101'   # PROVISIONED gegen USED
```

Eine frisch geklonte 32-GB-Platte steht dort mit `PROVISIONED 32 GiB` und
`USED 80 MiB` — die 80 MiB sind alles, was der laufende Gast seither geschrieben
hat.

Nach dem Flatten ist die Spalte `PARENT` leer, und `USED` entspricht dem
tatsächlichen Inhalt.

---

## Auf anderen Speicherarten

Das ganze Thema ist eine **Ceph-Eigenheit**. Andere Storages verhalten sich
anders:

| Storage | Hängt am Quell-Snapshot? | `flatten` |
|---|---|---|
| `rbd` (Ceph) | **ja** — Snapshot wird geschützt und unlöschbar | nötig für den Dauerbetrieb |
| `lvmthin` | **nein** | nicht nötig |
| `zfspool` | ja | nicht möglich |

### LVM-thin ist hier angenehmer als Ceph

Ein Thin-Snapshot ist ein eigenständiges Volume, das sich mit anderen nur die
Blöcke im Pool teilt. Nachgemessen:

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

Also: platzsparend geteilt **und** trotzdem frei löschbar. `flatten` meldet
solche Datenträger entsprechend als „nicht nötig".

Der Preis liegt woanders: `lvmthin` ist **lokaler** Speicher. Die
Wiederherstellung muss auf demselben Node laufen wie das Original;
`pvesnap-recovery` prüft das und lehnt einen anderen Node ab. Mit Ceph ist sie
dagegen auf jedem Node des Clusters startbar.

!!! 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
    ```

### Bei ZFS geht es nicht

Der Klon hängt wie bei Ceph am Snapshot. `zfs promote` würde die Abhängigkeit
nur **umdrehen** statt auflösen — danach hinge das Original am Klon, was das
Problem nicht löst, sondern verschiebt.

Echte Unabhängigkeit ginge nur über eine Vollkopie per `zfs send | zfs recv`.
Das macht `flatten` nicht, und es sagt das auch so:

```
nicht moeglich - ein ZFS-Klon haengt am Snapshot. Loesen ginge nur
ueber 'zfs send | zfs recv' in einen neuen Datentraeger
```

---

## Wann lösen, wann nicht?

| Lage | |
|---|---|
| Kurz hineinschauen, Dump ziehen, verwerfen | **nicht lösen.** Kostet nur Platz und Zeit. |
| Die Maschine bleibt ein paar Tage stehen | **lösen**, sonst blockiert sie die Vorhaltezeit des Originals |
| Die Maschine übernimmt dauerhaft | **lösen** — und zwar vor dem Löschen des Originals |
| Auf LVM-thin | nichts zu tun |