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>
177 lines
5.5 KiB
Markdown
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:
|
|
|
|

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