proxmox-snapshot-service/handbuch/docs/sichern/betrieb.md

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_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, 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 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

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

[global]
dry_run = yes

oder einmalig:

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

[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.