Files
proxmox-snapshot-service/handbuch/docs/sichern/index.md
T
duffyduckandClaude Opus 5 59e7224297 Handbuch auf MkDocs-Basis, mit Bildschirmfotos aus dem Programm
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht:
erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen,
dahinter der Nachschlagteil.

Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten:
keine Schriften vom CDN (font: false), Volltextsuche mit deutschem
Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe
Netz - dann nuetzt eine Doku im Internet nichts.

  handbuch/bauen.sh              baut handbuch/site/
  handbuch/bauen.sh ansehen      Vorschau auf 127.0.0.1:8000

install.sh nimmt das gebaute Handbuch mit nach
/usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst
wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor.

Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der
echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen
Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm
nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm
ueberein, sind reproduzierbar und enthalten keine echten Daten. Die
Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md.

Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange,
das mit dem eingebauten Austauschlaufwerk weggefallen ist.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 12:39:30 +02:00

177 lines
5.5 KiB
Markdown

# 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