From 09dcd4c572e7c0e5df4420ed9e339dbfccab8f1b Mon Sep 17 00:00:00 2001 From: duffyduck Date: Fri, 31 Jul 2026 19:37:20 +0200 Subject: [PATCH] README: Schreibzugriffe waehrend des Flatten sind belegt Gemessen an einem Container, der durchgehend schrieb, waehrend abgekoppelt wurde: 64 MB vor dem Flatten geschrieben -> SHA-256 danach OK 192 MB waehrend des Flatten -> SHA-256 danach OK 12 Schreibvorgaenge im Zeitfenster 19:35:48 - 19:36:10 Flatten selbst 19:35:48 - 19:36:11 Gast durchgehend running rbd flatten fuellt nur Bloecke auf, die der Klon nicht selbst besitzt - was der Gast geschrieben hat, gehoert ihm und wird nicht ueberschrieben. Dazu die Einordnung gegenueber dem Live-Restore des Proxmox Backup Servers: dort wird im Hintergrund nachgeladen, hier nicht. Der Klon ist von Anfang an vollstaendig und - weil Copy-on-Write nichts kopiert - unabhaengig von der Groesse in etwa einer Sekunde fertig. Eine 2-TB-VM wird also nicht erst stundenlang kopiert, sondern ist sofort in Betrieb. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 44 +++++++++++++++++++++++++++++++++++++++----- 1 file changed, 39 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index bec78df..a070e8e 100644 --- a/README.md +++ b/README.md @@ -639,15 +639,49 @@ setzt sich darüber hinweg. Schnell ist es, solange Platz da ist: 13 GB waren im Test in rund 70 Sekunden kopiert. -**Die Maschine läuft dabei weiter.** `rbd flatten` ist eine Online-Operation — -anders als beim Live-Restore des Proxmox Backup Servers wird hier nichts -nachgeladen: Der Linked Clone liegt im selben Pool und ist aus Sicht des Gastes -von Sekunde eins an vollständig. `flatten` löst nur die *Abhängigkeit*, nicht -die Verfügbarkeit. Im Test blieb die VM über den gesamten Vorgang auf +**Die Maschine läuft dabei weiter — und bleibt voll beschreibbar.** `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 (10:38 → 10:39, mit sichtbarer Bildschirmanimation) — 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. + +### Warum das kein „Live-Restore" ist, sondern besser + +Beim Live-Restore des Proxmox Backup Servers liegt das Backup auf einem anderen +Medium: Die VM startet sofort, holt die Blöcke aber im Hintergrund übers Netz +nach und läuft bis dahin gebremst. + +Hier wird **gar nichts nachgeladen**. Der Klon liegt im selben Pool und ist aus +Sicht des Gastes von Sekunde eins an vollständig — bei voller Geschwindigkeit. +Und weil Copy-on-Write nichts kopiert, ist er **unabhängig von der Größe** in +etwa einer Sekunde fertig: + +``` +Klon ~1 s egal ob 32 GB oder 2 TB +Start Sekunden mit RAM-Zustand sofort im laufenden Zustand +Arbeiten ab jetzt voll beschreibbar +flatten nebenher optional, im laufenden Betrieb +``` + +Bei einer 2-TB-VM wird also nicht stundenlang kopiert und dann gestartet — +gearbeitet wird ab der ersten Sekunde, das Abkoppeln läuft im Hintergrund mit. +`flatten` betrifft ausschließlich die *Abhängigkeit* vom Quell-Snapshot, nie +die Verfügbarkeit. + ### Wenn außerhalb von pvesnap gelöscht wurde — `cleanup` Wird eine Wiederherstellung in der Proxmox-Oberfläche entfernt statt mit