proxmox-snapshot-service/handbuch/docs/sichern/vorhaltezeit.md

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.

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

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

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

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:

[group:stuendlich]     keep_count = 24    keep_time = 2d
[group:taeglich]       keep_count = 14    keep_time = 21d
[group:monatlich]      keep_count = 6     keep_time = 400d