proxmox-snapshot-service/handbuch/docs/wiederherstellen/loesen.md

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

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:

pvesnap-recovery flatten 9101

Zuerst wird gemessen, wie viel kopiert werden muss:

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:

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

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