duffyduckandClaude Opus 5.5
74be5aee59
Volle Ceph-Pools legen alle VMs darauf lahm. Vor jedem Snapshot gilt jetzt je Storage des Gastes: frei >= sofortiger Verbrauch + space_min_free (Vorgabe 20 %). Die Reserve bleibt also auch nach dem Snapshot frei. Reicht es nicht, wird der aelteste pvesnap-Snapshot des Gastes geloescht und neu geprueft, bis es reicht. Sind nur noch die neuesten space_keep (Vorgabe 7) uebrig, entfaellt der Snapshot und der naechste Gast kommt dran. Gezaehlt wird je Gast ueber alle Gruppen, anders als bei der Vorhaltezeit. Auf dem Testhost haette eine Grenze je Gruppe nie gegriffen: keep_count = 5 liegt unter 7, und 13 GiB steckten in einer Gruppe, die es nicht mehr gibt. Sofortiger Verbrauch: Dicke ZFS-Zvols muessen ihre Reservierung auch nach dem Snapshot garantieren, das kostet alles seit dem letzten Snapshot Geschriebene. Exakt ist das refreservation - usedbyrefreservation; die Werte kommen per zfs get, bei anderen Nodes per ssh ueber die IP aus dem Clusterstatus, weil Node-Namen nicht ueberall aufloesen. Dazu kommt der RAM bei vmstate. --dry-run zeigt die Rechnung je Storage. Ceph und ZFS geben Platz erst im Hintergrund frei. Deshalb wird nach jedem Loeschen gewartet, solange der Platz waechst, und erst nach space_settle (Vorgabe 30s) ohne Zuwachs weitergemacht. Ohne das wurde auf Ceph ein Snapshot zu viel geloescht. Laesst sich der Platz nicht feststellen, wird nichts geloescht und der Snapshot trotzdem versucht. Neu ist [mail]: eine Alarm-Mail je Gruppe und Lauf, wenn ein Snapshot wegen Platzmangels ausfaellt. STARTTLS oder SSL/TLS mit Zertifikatspruefung, ohne Rueckfall auf Klartext. Einzurichten im Editor (Taste m) oder von Hand, Test mit pvesnap mail-test. Liegt ein Passwort in der Datei, setzt der Editor die Rechte auf 600, auch fuer die .bak. Das Handbuch beschreibt, wie man Ceph (Ratios) und ZFS (Notreserve) frueher "voll" sagen laesst und was im Notfall zu tun ist. Ausserdem war "pvesnap run --dry-run" ueberall falsch: Die Option ist global und muss vor dem Unterbefehl stehen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.9 KiB
4.9 KiB
Im Betrieb
Der Dienst
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
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_countund ohnekeep_time— die würden endlos wachsen - zwei Gruppen mit demselben Kurznamen — die räumten sich gegenseitig ab
- Zeitpläne, die sich widersprechen (
intervalundschedulezugleich) - eine Auswahl, die auf keinen einzigen Gast passt
- Sandbox-Optionen in der systemd-Unit, an denen später jeder Snapshot scheitern würde
Von Hand auslösen
pvesnap run # jetzt fällige Gruppen ausführen
pvesnap run --force -g taeglich # diese Gruppe sofort, egal ob fällig
pvesnap --dry-run run --force # 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
pvesnap -c /root/test.conf check
pvesnap -c /root/test.conf --dry-run run --force
-c gilt für alle Unterbefehle. Zusammen mit --dry-run ein gefahrloser Weg,
eine neue Gruppenstruktur durchzuspielen, bevor sie scharf geschaltet wird.
Der Probelauf
[global]
dry_run = yes
oder einmalig:
pvesnap --dry-run run --force
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
[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:
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.
Wenn viele VMs auf demselben Storage liegen
[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:
# Gab es in den letzten 25 Stunden einen taeglichen Snapshot?
pvesnap list | grep auto-taeglich | tail -1
Oder gezielt über den Dienstzustand:
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.