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>
176 lines
4.9 KiB
Markdown
176 lines
4.9 KiB
Markdown
# Im Betrieb
|
|
|
|
## Der Dienst
|
|
|
|
```bash
|
|
systemctl status pvesnap # läuft er?
|
|
systemctl reload pvesnap # Konfiguration neu einlesen (SIGHUP)
|
|
systemctl restart pvesnap # kompletter Neustart
|
|
journalctl -u pvesnap -f # Protokoll mitlesen
|
|
```
|
|
|
|
`reload` ist der Normalfall nach einer Änderung: Der Dienst liest die
|
|
Konfiguration neu ein, ohne laufende Vorgänge abzubrechen und ohne den
|
|
gemerkten Zustand zu verlieren.
|
|
|
|
---
|
|
|
|
## Nachsehen
|
|
|
|
```bash
|
|
pvesnap status # Gruppen, letzte und nächste Läufe
|
|
pvesnap vms # welche VM landet in welcher Gruppe
|
|
pvesnap list # vorhandene pvesnap-Snapshots (-a = auch fremde)
|
|
pvesnap check # Konfiguration prüfen
|
|
```
|
|
|
|
### `pvesnap check`
|
|
|
|
Der Befehl, den man nach jeder Änderung laufen lassen sollte. Er findet unter
|
|
anderem:
|
|
|
|
* Gruppen ohne `keep_count` **und** ohne `keep_time` — die würden endlos wachsen
|
|
* zwei Gruppen mit demselben Kurznamen — die räumten sich gegenseitig ab
|
|
* Zeitpläne, die sich widersprechen (`interval` und `schedule` zugleich)
|
|
* eine Auswahl, die auf keinen einzigen Gast passt
|
|
* [Sandbox-Optionen in der systemd-Unit](../installation.md#die-systemd-unit),
|
|
an denen später jeder Snapshot scheitern würde
|
|
|
|
---
|
|
|
|
## Von Hand auslösen
|
|
|
|
```bash
|
|
pvesnap run # jetzt fällige Gruppen ausführen
|
|
pvesnap run --force -g taeglich # diese Gruppe sofort, egal ob fällig
|
|
pvesnap run --force --dry-run # Probelauf, ändert nichts
|
|
pvesnap prune -g stuendlich # nur aufräumen
|
|
```
|
|
|
|
`--force` heißt „auch wenn nicht fällig". Ohne das passiert bei einem Aufruf
|
|
zwischen zwei Terminen schlicht nichts.
|
|
|
|
!!! note "Parallel zum Dienst"
|
|
|
|
Ein manueller `pvesnap run` ist auch möglich, während der Dienst läuft.
|
|
Beide teilen sich eine Sperre und kommen sich nicht in die Quere — der
|
|
zweite wartet, bis der erste fertig ist.
|
|
|
|
### Eine andere Konfiguration ausprobieren
|
|
|
|
```bash
|
|
pvesnap -c /root/test.conf check
|
|
pvesnap -c /root/test.conf run --force --dry-run
|
|
```
|
|
|
|
`-c` gilt für alle Unterbefehle. Zusammen mit `--dry-run` ein gefahrloser Weg,
|
|
eine neue Gruppenstruktur durchzuspielen, bevor sie scharf geschaltet wird.
|
|
|
|
---
|
|
|
|
## Der Probelauf
|
|
|
|
```ini
|
|
[global]
|
|
dry_run = yes
|
|
```
|
|
|
|
oder einmalig:
|
|
|
|
```bash
|
|
pvesnap run --force --dry-run
|
|
```
|
|
|
|
Protokolliert, was geschähe, ohne etwas anzulegen oder zu löschen:
|
|
|
|
```
|
|
[TESTLAUF] wuerde Snapshot anlegen: VM 101 (db01) -> auto-taeglich-20260809-023000
|
|
[TESTLAUF] wuerde Snapshot loeschen: VM 101 (db01) -> auto-taeglich-20260719-023000
|
|
```
|
|
|
|
Besonders die zweite Zeilenart ist es wert, einmal angesehen zu werden, bevor
|
|
eine neue Vorhaltezeit produktiv geht.
|
|
|
|
---
|
|
|
|
## Protokoll
|
|
|
|
```ini
|
|
[global]
|
|
log_level = INFO
|
|
# log_file = /var/log/pvesnap.log
|
|
```
|
|
|
|
| Stufe | |
|
|
|---|---|
|
|
| `DEBUG` | jeder `pvesh`-Aufruf mit Argumenten — für die Fehlersuche |
|
|
| `INFO` | was angelegt und gelöscht wird (Vorgabe) |
|
|
| `WARNING` | nur Auffälligkeiten |
|
|
| `ERROR` | nur Fehler |
|
|
|
|
Ohne `log_file` geht alles ins Journal:
|
|
|
|
```bash
|
|
journalctl -u pvesnap -f # mitlesen
|
|
journalctl -u pvesnap --since "-1h" # letzte Stunde
|
|
journalctl -u pvesnap -p err # nur Fehler
|
|
journalctl -u pvesnap --since today | grep -i fehl
|
|
```
|
|
|
|
---
|
|
|
|
## Was im Protokoll normal ist
|
|
|
|
Nicht jede Meldung ist ein Problem:
|
|
|
|
| Meldung | Bedeutung |
|
|
|---|---|
|
|
| `storage does not support snapshots` | Diese VM liegt auf LVM-thick oder einem `raw`-Image. Sie wird übersprungen, die übrigen laufen weiter. |
|
|
| `got lock request timeout` | Das Storage war gerade belegt. Wird `retries`-mal wiederholt — erst danach ist es ein Fehler. |
|
|
| `VM is locked (backup)` | Ein `vzdump` läuft gerade. Ebenfalls vorübergehend. |
|
|
|
|
Dauerhaft wiederkehrende Lock-Fehler sind dagegen ein Zeichen — siehe
|
|
[Fehlersuche](../nachschlagen/fehlersuche.md#storage-lock).
|
|
|
|
---
|
|
|
|
## Wenn viele VMs auf demselben Storage liegen
|
|
|
|
```ini
|
|
[global]
|
|
pause_between = 10s # Pause zwischen zwei Gästen
|
|
retries = 2 # zusätzliche Versuche je Snapshot
|
|
retry_delay = 60s # Wartezeit davor
|
|
task_timeout = 15m # Geduld mit einem einzelnen Proxmox-Task
|
|
```
|
|
|
|
`pause_between` nimmt Druck vom Storage-Lock, wenn dreißig Maschinen im selben
|
|
Pool nacheinander drankommen. Vorgabe ist `0s`; bei Problemen sind `5s` bis
|
|
`15s` ein guter erster Versuch.
|
|
|
|
---
|
|
|
|
## Überwachen
|
|
|
|
Ein einfacher Weg, im Blick zu behalten, ob die Sicherung wirklich läuft:
|
|
|
|
```bash
|
|
# Gab es in den letzten 25 Stunden einen taeglichen Snapshot?
|
|
pvesnap list | grep auto-taeglich | tail -1
|
|
```
|
|
|
|
Oder gezielt über den Dienstzustand:
|
|
|
|
```bash
|
|
systemctl is-active pvesnap # active / failed
|
|
journalctl -u pvesnap --since "-25h" -p err -q # leer = keine Fehler
|
|
```
|
|
|
|
!!! warning "Der Klassiker"
|
|
|
|
Der Dienst läuft, das Protokoll ist ruhig — und trotzdem entsteht nichts,
|
|
weil alle Gruppen auf `enabled = no` stehen. Genau so wird ausgeliefert.
|
|
|
|
`pvesnap status` zeigt es sofort: Eine ausgeschaltete Gruppe hat keinen
|
|
nächsten Termin.
|