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