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>
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 --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
|
|
|
|
```bash
|
|
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
|
|
|
|
```ini
|
|
[global]
|
|
dry_run = yes
|
|
```
|
|
|
|
oder einmalig:
|
|
|
|
```bash
|
|
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
|
|
|
|
```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.
|