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.

---

Platz vor dem Snapshot

space_min_free = 20%    # so viel muss frei sein (auch absolut: 20G; 0 = keine Prüfung)
space_keep     = 7      # so viele bleiben auch bei Platzmangel stehen

Vor jedem Snapshot sieht pvesnap auf allen Storages der VM nach, ob space_min_free auch danach noch frei bleibt. Die Werte oben gelten als Vorgabe, auch ohne Eintrag in der Konfiguration. Wer mehr oder weniger möchte, setzt sie in [defaults] für alle Gruppen, je Gruppe einzeln oder im Editor unter Mindestens frei.

1. Genug Platz: Der Snapshot wird angelegt.
2. Zu wenig Platz: Der älteste pvesnap-Snapshot der VM wird gelöscht, dann wird erneut geprüft. Das wiederholt sich, bis der Platz reicht. Weiter gelöscht wird dann nicht.
3. Sind nur noch die neuesten space_keep übrig und es reicht immer noch nicht, entsteht für diese VM kein Snapshot. Das steht als Fehler im Protokoll, und die nächste VM kommt dran.

Was geprüft wird: frei ≥ sofortiger Verbrauch + space_min_free. Die Reserve bleibt also auch nach dem Snapshot frei und ist für das da, was die VM danach schreibt, denn wie groß ein Snapshot später wird, lässt sich nicht vorhersagen.

	Sofortiger Verbrauch
Ceph, LVM-thin, dünne ZFS-Zvols, qcow2	praktisch nichts
Dicke ZFS-Zvols	alles seit dem letzten Snapshot Geschriebene, exakt berechnet
vmstate = yes	zusätzlich der zugewiesene RAM, als Obergrenze

Eine Vorschau zeigt pvesnap --dry-run run --force: Je Storage steht dort, was frei ist, was der Snapshot belegen würde, was danach frei bleibt und wie groß die Reserve ist.

Dabei gilt:

• Gezählt wird je VM über alle Gruppen, anders als bei der normalen Vorhaltezeit. Ein voller Pool ist schlimmer als ein verlorener alter Stand. Bei Platzmangel kann eine stündliche Gruppe deshalb auch die Monatsstände derselben VM löschen, ebenso Snapshots von Gruppen, die es nicht mehr gibt.
• Halbfertige Einträge werden zuerst entfernt und zählen nicht mit.
• Das keep_min jeder Gruppe bleibt auch hier gewahrt.
• Von Hand angelegte Snapshots bleiben auch hier unangetastet.
• Lässt sich der Platz nicht feststellen, wird nichts gelöscht und der Snapshot trotzdem versucht.
• Ein Klon-Quell-Snapshot (snapshot is protected) wird als Fehler gemeldet und übergangen, weiter geht es mit dem nächsten.
• pvesnap run --no-prune löscht nie. Fehlt der Platz, entfällt der Snapshot.
• pvesnap --dry-run run löscht nichts und kann deshalb nicht sehen, wann es reichen würde. Es nennt alle Snapshots, die infrage kämen.

Wie viel Puffer? Die Schwelle bleibt frei für das, was die VMs bis zum nächsten Lauf schreiben, und damit Löschen überhaupt noch funktioniert. Grobe Werte aus einem Ceph-Cluster mit 8 OSDs und 3 Replikaten:

space_min_free	Vollste OSD
10%	86 %	schon über der nearfull-Warnung
15%	82 %	knapp darunter, wenig Reaktionszeit
20%	78 %	Vorgabe
30%	69 %	für viel Schreiblast oder kleine Pools

Als Probe sollte der Puffer mindestens das Dreifache von dem abdecken, was im Pool zwischen zwei Läufen im schlimmsten Fall neu belegt wird. Bei großen Pools passt oft eine feste Größe wie 2T besser.

Fällt deshalb ein Snapshot aus, kann pvesnap per Mail warnen. Wie man Ceph und ZFS schon vorher eine Grenze setzt, damit im Notfall Luft zum Löschen bleibt, steht unter Früher „voll“ sagen.

!!! note "space_settle: warten, bis der Platz zurückkommt"

Ceph und ZFS geben gelöschten Platz erst im Hintergrund frei. Würde pvesnap
sofort nachsehen, wäre scheinbar noch nichts frei und der nächste Snapshot
würde umsonst gelöscht. Deshalb wartet es, solange der freie Platz wächst,
und geht erst weiter, wenn sich `space_settle` lang (Vorgabe `30s`, in
`[global]`) nichts mehr getan hat. Auf einem Test-Cluster mit NVMe war der Platz
nach wenigen Sekunden zurück; ohne die Wartezeit wurde dort ein Snapshot zu viel
gelöscht. Bei HDDs und großen Snapshots dauert es länger. Das Löschen einer VM kann also dauern;
die Arbeitssperre bleibt währenddessen gehalten.

---

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. Einzige Ausnahme ist der Platzmangel.

---

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 --dry-run prune          # 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