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>
160 lines
4.9 KiB
Markdown
160 lines
4.9 KiB
Markdown
# Vorhaltezeit
|
|
|
|
Ohne Aufräumen wächst die Zahl der Snapshots ins Unendliche — und jeder hält
|
|
alte Blöcke fest. Die Vorhaltezeit ist deshalb keine Kür.
|
|
|
|
```ini
|
|
keep_count = 24 # höchstens 24 Snapshots je VM und Gruppe (0 = unbegrenzt)
|
|
keep_time = 7d # nichts älter als 7 Tage (0 = unbegrenzt)
|
|
keep_min = 1 # so viele bleiben in jedem Fall stehen
|
|
```
|
|
|
|
---
|
|
|
|
## Die beiden Grenzen
|
|
|
|
Beide sind kombinierbar. Gelöscht wird, was **eine** der beiden reißt — es ist
|
|
ein ODER, kein UND.
|
|
|
|
!!! example "Beispiel: `keep_count = 24`, `keep_time = 2d`"
|
|
|
|
Eine stündliche Gruppe. Nach zwei Tagen sind 48 Snapshots angefallen —
|
|
`keep_count` greift und lässt nur die letzten 24 stehen.
|
|
|
|
Läuft eine VM zwei Wochen lang nicht (mit `skip_stopped = yes`), sind ihre
|
|
Snapshots irgendwann älter als zwei Tage — `keep_time` greift und räumt sie
|
|
weg, auch wenn es weniger als 24 sind.
|
|
|
|
**Mindestens eine der beiden muss gesetzt sein.** Sonst würde die Zahl der
|
|
Snapshots unbegrenzt wachsen; `pvesnap check` meldet das als Fehler.
|
|
|
|
---
|
|
|
|
## `keep_min` — die Untergrenze
|
|
|
|
```ini
|
|
keep_min = 1
|
|
```
|
|
|
|
So viele Snapshots bleiben in jedem Fall stehen, auch wenn sie beide Grenzen
|
|
reißen.
|
|
|
|
Der Sinn: `keep_time = 2d` würde bei einer Maschine, die drei Tage aus war,
|
|
**alles** löschen — und damit den letzten bekannten Stand. Mit `keep_min = 1`
|
|
bleibt immer einer übrig.
|
|
|
|
!!! tip "Eine Empfehlung"
|
|
|
|
`keep_min = 1` in jeder Gruppe mit `keep_time`. Es kostet fast nichts und
|
|
verhindert den einen Fall, in dem das Aufräumen genau das wegräumt, was man
|
|
gebraucht hätte.
|
|
|
|
---
|
|
|
|
## Getrennt je VM und Gruppe
|
|
|
|
Beide Grenzen zählen **pro Gast und pro Gruppe**, nicht insgesamt.
|
|
|
|
`keep_count = 24` bei 30 Maschinen heißt also: bis zu 720 Snapshots — aber je
|
|
Maschine nur 24. Und eine VM, die in drei Gruppen steckt, hat 24 + 14 + 6
|
|
Snapshots nebeneinander, die sich nicht gegenseitig verdrängen.
|
|
|
|
---
|
|
|
|
## Was pvesnap anfasst — und was nicht
|
|
|
|
Aufgeräumt wird ausschließlich, was zum
|
|
[Namensschema](index.md#namensschema) der jeweiligen Gruppe passt:
|
|
|
|
```
|
|
auto-taeglich-20260809-023000 ← wird von der Gruppe "taeglich" gezählt
|
|
auto-stuendlich-20260809-100000 ← zählt für "stuendlich", nicht für "taeglich"
|
|
vor-update-14.2 ← wird nie angefasst
|
|
```
|
|
|
|
!!! success "Von Hand angelegte Snapshots bleiben"
|
|
|
|
Ein Snapshot, den jemand in der Proxmox-Oberfläche angelegt hat, passt nie
|
|
auf das Muster. Er zählt weder gegen `keep_count`, noch wird er jemals
|
|
gelöscht.
|
|
|
|
Das hat eine Kehrseite: Er wird auch nicht aufgeräumt. Wer sich vor einem
|
|
Update einen Sicherheitsstand anlegt, sollte ihn hinterher selbst wieder
|
|
entfernen — sonst hält er ewig alte Blöcke fest.
|
|
|
|
---
|
|
|
|
## Nur aufräumen, ohne Neues anzulegen
|
|
|
|
```bash
|
|
pvesnap prune # alle Gruppen
|
|
pvesnap prune -g stuendlich # nur diese
|
|
pvesnap prune --dry-run # zeigt, was wegkäme
|
|
```
|
|
|
|
Praktisch nach dem Verkürzen einer Vorhaltezeit: Der Dienst würde erst beim
|
|
nächsten regulären Termin aufräumen, `prune` macht es sofort.
|
|
|
|
---
|
|
|
|
## Platz im Blick behalten
|
|
|
|
```bash
|
|
pvesnap list # alle pvesnap-Snapshots
|
|
pvesnap list -a # auch fremde
|
|
```
|
|
|
|
Und auf dem Storage selbst:
|
|
|
|
=== "Ceph / RBD"
|
|
|
|
```bash
|
|
ceph df # MAX AVAIL beachten, nicht nur % RAW USED
|
|
rbd -p <pool> du # PROVISIONED gegen USED
|
|
```
|
|
|
|
=== "ZFS"
|
|
|
|
```bash
|
|
zfs list -o space # USEDSNAP zeigt, was die Snapshots kosten
|
|
```
|
|
|
|
=== "LVM-thin"
|
|
|
|
```bash
|
|
lvs -o lv_name,data_percent,metadata_percent
|
|
```
|
|
|
|
!!! danger "Ein volles Storage blockiert alles"
|
|
|
|
Läuft ein Ceph-Pool oder ein Thin-Pool voll, stehen **alle** Volumes darin
|
|
— nicht nur die schreibfreudige VM. Und das Aufräumen wird dann selbst
|
|
schwierig, weil Löschen ebenfalls ein Schreibvorgang ist.
|
|
|
|
Bei Ceph ist `MAX AVAIL` die Zahl, auf die es ankommt; `% RAW USED` täuscht,
|
|
weil es die Replikation nicht berücksichtigt.
|
|
|
|
---
|
|
|
|
## Wie viel kostet ein Snapshot?
|
|
|
|
Anfangs: nichts. Ein Snapshot ist ein Zeiger, kein Abbild.
|
|
|
|
Er wächst mit dem, was **danach** geschrieben wird — jeder geänderte Block
|
|
bedeutet, dass der alte Stand zusätzlich vorgehalten werden muss.
|
|
|
|
| VM | Verhalten |
|
|
|---|---|
|
|
| Ein Fileserver, auf dem selten geschrieben wird | Snapshots kosten fast nichts, lange Vorhaltezeiten sind billig |
|
|
| Eine Datenbank mit ständigem Schreibverkehr | Jeder Snapshot wächst spürbar; kurze Vorhaltezeit, dafür engmaschig |
|
|
| Eine VM, die gerade ein Update bekommt | Ein einzelner Snapshot kann in Minuten mehrere GB kosten |
|
|
|
|
Deshalb passen kurze Intervalle und lange Vorhaltezeiten schlecht zusammen. Ein
|
|
guter Ausgangspunkt:
|
|
|
|
```ini
|
|
[group:stuendlich] keep_count = 24 keep_time = 2d
|
|
[group:taeglich] keep_count = 14 keep_time = 21d
|
|
[group:monatlich] keep_count = 6 keep_time = 400d
|
|
```
|