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