# Sichern

Alles, was pvesnap tut, steckt in **Gruppen**. Eine Gruppe beantwortet drei
Fragen:

<div class="ablauf" markdown>

**Wann?** — [Zeitplan](zeitplan.md): alle 30 Minuten, täglich um 02:30, am
Monatsersten

**Wer?** — [Auswahl](auswahl.md): diese VMIDs, alles mit dem Tag `produktion`,
alle außer `nosnap`

**Wie lange?** — [Vorhaltezeit](vorhaltezeit.md): die letzten 24, nichts älter
als zwei Tage

</div>

Davon darf es beliebig viele geben, und eine VM darf in mehreren stecken. Genau
das ist der Sinn: Die Datenbank bekommt stündliche Snapshots mit kurzer
Vorhaltezeit, dieselbe Datenbank zusätzlich einen monatlichen, der ein Jahr
liegen bleibt.

---

## Ein typischer Aufbau

```ini
[group:stuendlich]
interval = 1h
align = yes                # an der Uhr: 00:00, 01:00, 02:00 ...
keep_count = 24
keep_time = 2d
tags = stuendlich
skip_stopped = yes

[group:taeglich]
schedule = daily
at = 02:30
keep_count = 14
keep_time = 21d
tags = produktion
exclude_tags = nosnap

[group:monatlich]
schedule = monthly
day_of_month = 1
at = 04:00
keep_count = 6
keep_time = 400d
all = yes
exclude_tags = nosnap
```

Drei Gruppen, drei Zeithorizonte. Die Datenbank mit den Tags
`produktion,stuendlich` landet in allen dreien — und hat damit den Stand von
vor einer Stunde, von gestern Nacht und vom Monatsersten.

So sieht das im Editor aus:

![Die Gruppenliste](../bilder/config-gruppen.svg)

---

## Namensschema

Jeder Snapshot heißt nach demselben Muster:

```
auto-taeglich-20260809-023000
 │      │         │       └── Uhrzeit
 │      │         └────────── Datum
 │      └──────────────────── Kurzname der Gruppe
 └─────────────────────────── prefix aus [global]
```

Das ist keine Kosmetik, sondern die **Sicherheitsgrenze** des ganzen Programms.

!!! success "pvesnap löscht ausschließlich, was exakt auf dieses Muster passt"

    Und zusätzlich muss der Gruppen-Kurzname zu einer Gruppe gehören, die
    gerade aufräumt. Ein Snapshot namens `vor-update-14.2` oder
    `bkp_20260101` wird nie angefasst — egal wie alt er ist, egal wie voll das
    Storage läuft.

Umlaute und Sonderzeichen im Gruppennamen werden für den Kurznamen
umgeschrieben (`täglich` → `taeglich`). Ergäben zwei Gruppen denselben
Kurznamen, meldet das `pvesnap check` — sonst würden sie sich gegenseitig die
Snapshots wegräumen.

!!! warning "Gruppe umbenennen"

    Der neue Name bekommt einen eigenen Kurznamen. Snapshots unter dem alten
    Namen passen dann zu keiner Gruppe mehr und werden **nicht mehr
    aufgeräumt** — sie bleiben für immer liegen. Entweder vorher aufräumen
    lassen oder die alten hinterher von Hand entfernen.

---

## Der Ablauf eines Laufs

Der Dienst schaut alle `check_interval` (Vorgabe: 60 s) nach, ob eine Gruppe
fällig ist. Ist sie es:

1. **Gäste bestimmen** — nach den Auswahlregeln der Gruppe
2. **Snapshot anlegen**, ein Gast nach dem anderen; dazwischen optional
   `pause_between`
3. **Warten, bis Proxmox wirklich fertig ist** — nicht nur, bis der Aufruf
   zurückkommt
4. **Aufräumen** — alles, was `keep_count` oder `keep_time` reißt

Schritt 3 ist wichtiger, als er aussieht. Proxmox nimmt beim Anlegen eine
Sperre auf dem Storage (`cfs-lock 'storage-<name>'`). Würde pvesnap gleich die
nächste VM anstoßen, sperrten sich die eigenen Läufe gegenseitig aus. Mehr dazu
unter [Fehlersuche](../nachschlagen/fehlersuche.md#storage-lock).

Wird ein Termin verpasst, weil der Host aus war, wird er beim nächsten Start
**nachgeholt** — einmal, nicht für jeden ausgefallenen Termin einzeln.

---

## Was in einen Snapshot gehört

| Einstellung | Vorgabe | |
|---|---|---|
| `vmstate` | `no` | Arbeitsspeicher mitsichern — nur QEMU, nur bei laufender VM |
| `skip_stopped` | `no` | gestoppte Gäste überspringen |
| `description` | siehe unten | Beschreibung, die am Snapshot hängt |

### `vmstate` — der Arbeitsspeicher

Mit `vmstate = yes` wird der RAM mitgeschrieben. Die Maschine friert dafür kurz
ein, und es braucht Platz in Höhe des zugewiesenen Arbeitsspeichers — bei einer
32-GB-Datenbank also 32 GB **pro Snapshot**.

Für regelmäßige Läufe ist das meist zu teuer. Es hat aber einen konkreten
Nutzen: Beim [Wiederherstellen](../wiederherstellen/index.md) läuft die
Maschine dann genau dort weiter, wo sie stand — statt zu booten wie nach einem
Stromausfall. Datenbanken sind dabei bereits offen und konsistent.

!!! tip "Der Mittelweg"

    Eine eigene Gruppe mit `vmstate = yes`, die einmal täglich läuft und nur
    zwei Stände vorhält. Kostet zweimal RAM-Größe und gibt im Ernstfall einen
    warmen Einstiegspunkt.

### Die Beschreibung

Sie steht in der Proxmox-Oberfläche neben jedem Snapshot:

```ini
description = pvesnap | Gruppe: {group} | erstellt: {datetime} | Vorhaltezeit: {keep_time} | max: {keep_count}
```

Verfügbare Platzhalter:

| | | |
|---|---|---|
| `{group}` | `{group_slug}` | `{schedule}` |
| `{vmid}` | `{name}` | `{node}` |
| `{type}` | `{pool}` | `{tags}` |
| `{date}` | `{time}` | `{datetime}` |
| `{timestamp}` | `{keep_time}` | `{keep_count}` |

Ein unbekannter Platzhalter führt nicht zum Abbruch — es wird dann eine
brauchbare Ersatzbeschreibung eingesetzt.

---

## Weiter

* [Der Konfigurationseditor](editor.md) — alles das mit Menüs statt INI-Datei
* [Zeitpläne](zeitplan.md)
* [Welche Gäste?](auswahl.md)
* [Vorhaltezeit](vorhaltezeit.md)
* [Im Betrieb](betrieb.md) — Dienst, Protokoll, Probelauf