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>
5.5 KiB
Sichern
Alles, was pvesnap tut, steckt in Gruppen. Eine Gruppe beantwortet drei Fragen:
Wann? — Zeitplan: alle 30 Minuten, täglich um 02:30, am Monatsersten
Wer? — Auswahl: diese VMIDs, alles mit dem Tag produktion,
alle außer nosnap
Wie lange? — Vorhaltezeit: die letzten 24, nichts älter als zwei Tage
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
[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:
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:
- Gäste bestimmen — nach den Auswahlregeln der Gruppe
- Snapshot anlegen, ein Gast nach dem anderen; dazwischen optional
pause_between - Warten, bis Proxmox wirklich fertig ist — nicht nur, bis der Aufruf zurückkommt
- Aufräumen — alles, was
keep_countoderkeep_timereiß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.
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 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:
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 — alles das mit Menüs statt INI-Datei
- Zeitpläne
- Welche Gäste?
- Vorhaltezeit
- Im Betrieb — Dienst, Protokoll, Probelauf