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>
130 lines
3.8 KiB
Markdown
130 lines
3.8 KiB
Markdown
# Zeitpläne
|
|
|
|
Jede Gruppe hat **entweder** ein Intervall **oder** einen festen Termin. Beides
|
|
gleichzeitig geht nicht — `pvesnap check` weist darauf hin.
|
|
|
|
---
|
|
|
|
## Intervall
|
|
|
|
```ini
|
|
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
|
|
|
|
```ini
|
|
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
|
|
|
|
```ini
|
|
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:
|
|
|
|
```ini
|
|
[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
|
|
|
|
```ini
|
|
[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](vorhaltezeit.md)
|
|
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.
|