duffyduckandClaude Opus 5
59e7224297
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>
3.8 KiB
Zeitpläne
Jede Gruppe hat entweder ein Intervall oder einen festen Termin. Beides
gleichzeitig geht nicht — pvesnap check weist darauf hin.
Intervall
interval = 30m # 30m, 1h, 6h, 2d12h, 1w ...
align = yes
Zeitangaben gelten überall im selben Format: 30m, 1h, 6h, 2d12h, 1w.
0 heißt „unbegrenzt".
Der Unterschied steckt in align:
align = yes |
an der Uhr ausgerichtet — 00:00, 00:30, 01:00 … Die Snapshots liegen auf runden Zeiten, unabhängig davon, wann der Dienst gestartet wurde. |
align = no |
30 Minuten nach dem letzten Lauf. Startet der Dienst um 14:07 neu, liegen die Snapshots danach bei :07 und :37. |
Für alles, was regelmäßig aussehen soll, ist align = yes die richtige Wahl.
align = no ist nur dann sinnvoll, wenn der Abstand wichtiger ist als der
Zeitpunkt.
Fester Termin
schedule = daily
at = 02:30
schedule |
zusätzliche Angaben | ergibt |
|---|---|---|
hourly |
minute = 15 |
jede Stunde um :15 |
daily |
at = 02:30 |
täglich um 02:30 |
weekly |
at, day_of_week = so |
sonntags um 03:00 |
monthly |
at, day_of_month = 1 |
am 1. jedes Monats |
yearly |
at, day_of_month, month |
einmal jährlich |
Wochentage: mo di mi do fr sa so (auch mon, tue … funktionieren).
Der 31. in kurzen Monaten
schedule = monthly
day_of_month = 31
Wird automatisch auf den letzten Tag des Monats gezogen — im Februar also auf den 28. bzw. 29. Kein ausgefallener Lauf, keine Sonderbehandlung nötig.
Verpasste Termine
Läuft der Host zum Termin nicht, wird der Lauf beim nächsten Start nachgeholt. Einmal — nicht für jeden ausgefallenen Termin einzeln.
Ein Host, der eine Woche aus war, legt beim Hochfahren also einen täglichen Snapshot an, nicht sieben.
Merken tut sich das die Zustandsdatei:
[global]
state_file = /var/lib/pvesnap/state.json
Wird sie gelöscht, gilt jede Gruppe als „noch nie gelaufen" und wird beim nächsten Prüfintervall sofort ausgeführt.
Beim Start sofort loslegen
[global]
run_on_start = no
Mit yes macht der Dienst direkt nach dem Start einen Durchlauf, statt auf den
nächsten regulären Termin zu warten.
Auf einem Host, der oft neu startet, führt das zu vielen zusätzlichen
Snapshots. Vorgabe ist deshalb no.
Die Zeitumstellung
!!! warning "Gerechnet wird mit lokaler Zeit"
Ein täglicher Termin um 02:30 kann in der Umstellungsnacht **ausfallen**
(im Frühjahr existiert 02:30 nicht) oder **doppelt anstehen** (im Herbst
gibt es sie zweimal).
Wen das stört, legt den Termin auf eine Zeit außerhalb des Fensters —
04:00 statt 02:30 — oder nimmt ein Intervall statt eines festen Termins.
Wie oft ist richtig?
Es gibt keine allgemeingültige Antwort, aber eine brauchbare Faustregel: Der Abstand ist die Datenmenge, die du im Ernstfall verlierst.
| Abstand | Verlust im schlimmsten Fall | Passt zu |
|---|---|---|
| 15 min | eine Viertelstunde Arbeit | Datenbanken, Warenwirtschaft |
| 1 h | eine Stunde | Anwendungsserver |
| täglich | ein Arbeitstag | Fileserver, Infrastruktur |
| monatlich | — | der lange Rückweg, „wie war es vor dem Update?" |
Was dagegen spricht, öfter zu sichern, ist der Platz: Jeder Snapshot hält die alten Blöcke fest. Bei einer schreibfreudigen VM wächst das schnell. Deshalb gehören kurze Intervalle immer mit kurzer Vorhaltezeit zusammen — 24 stündliche Snapshots über zwei Tage sind billiger als sieben tägliche über eine Woche.
!!! tip "Gestoppte Gäste überspringen"
Bei kurzen Intervallen lohnt sich `skip_stopped = yes`. Sonst sammelt eine
abgeschaltete Test-VM stündlich Snapshots vom immer gleichen Zustand.