duffyduckandClaude Opus 5
59e7224297
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht: erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen, dahinter der Nachschlagteil. Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten: keine Schriften vom CDN (font: false), Volltextsuche mit deutschem Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe Netz - dann nuetzt eine Doku im Internet nichts. handbuch/bauen.sh baut handbuch/site/ handbuch/bauen.sh ansehen Vorschau auf 127.0.0.1:8000 install.sh nimmt das gebaute Handbuch mit nach /usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor. Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm ueberein, sind reproduzierbar und enthalten keine echten Daten. Die Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md. Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange, das mit dem eingebauten Austauschlaufwerk weggefallen ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
195 lines
6.4 KiB
Markdown
195 lines
6.4 KiB
Markdown
# 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:
|
||
|
||
|
||
|
||
```
|
||
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:
|
||
|
||
|
||
|
||
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 |
|