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.

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

---

## Platz vor dem Snapshot

```ini
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](editor.md) 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](../nachschlagen/speicher.md#zfs-die-notreserve) | 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](../nachschlagen/konfiguration.md#mail). Wie man Ceph und ZFS
schon vorher eine Grenze setzt, damit im Notfall Luft zum Löschen bleibt, steht
unter [Früher „voll“ sagen](../nachschlagen/speicher.md#fruher-voll-sagen-damit-luft-zum-loschen-bleibt).

!!! 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](#platz-vor-dem-snapshot).

---

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

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