# Zeitpläne

Jede Gruppe hat **entweder** ein Intervall **oder** einen festen Termin. Beides
gleichzeitig geht nicht — `pvesnap check` weist darauf hin.

---

## Intervall

```ini
interval = 30m      # 30m, 1h, 6h, 2d12h, 1w ...
align = yes
```

Zeitangaben gelten überall im selben Format: `30m`, `1h`, `6h`, `2d12h`, `1w`.
`0` heißt „unbegrenzt".

Der Unterschied steckt in `align`:

| | |
|---|---|
| `align = yes` | **an der Uhr ausgerichtet** — 00:00, 00:30, 01:00 … Die Snapshots liegen auf runden Zeiten, unabhängig davon, wann der Dienst gestartet wurde. |
| `align = no` | **30 Minuten nach dem letzten Lauf.** Startet der Dienst um 14:07 neu, liegen die Snapshots danach bei :07 und :37. |

Für alles, was regelmäßig aussehen soll, ist `align = yes` die richtige Wahl.
`align = no` ist nur dann sinnvoll, wenn der Abstand wichtiger ist als der
Zeitpunkt.

---

## Fester Termin

```ini
schedule = daily
at = 02:30
```

| `schedule` | zusätzliche Angaben | ergibt |
|---|---|---|
| `hourly` | `minute = 15` | jede Stunde um :15 |
| `daily` | `at = 02:30` | täglich um 02:30 |
| `weekly` | `at`, `day_of_week = so` | sonntags um 03:00 |
| `monthly` | `at`, `day_of_month = 1` | am 1. jedes Monats |
| `yearly` | `at`, `day_of_month`, `month` | einmal jährlich |

Wochentage: `mo di mi do fr sa so` (auch `mon`, `tue` … funktionieren).

### Der 31. in kurzen Monaten

```ini
schedule = monthly
day_of_month = 31
```

Wird automatisch auf den **letzten Tag des Monats** gezogen — im Februar also
auf den 28. bzw. 29. Kein ausgefallener Lauf, keine Sonderbehandlung nötig.

---

## Verpasste Termine

Läuft der Host zum Termin nicht, wird der Lauf beim nächsten Start
**nachgeholt**. Einmal — nicht für jeden ausgefallenen Termin einzeln.

Ein Host, der eine Woche aus war, legt beim Hochfahren also einen täglichen
Snapshot an, nicht sieben.

Merken tut sich das die Zustandsdatei:

```ini
[global]
state_file = /var/lib/pvesnap/state.json
```

Wird sie gelöscht, gilt jede Gruppe als „noch nie gelaufen" und wird beim
nächsten Prüfintervall sofort ausgeführt.

---

## Beim Start sofort loslegen

```ini
[global]
run_on_start = no
```

Mit `yes` macht der Dienst direkt nach dem Start einen Durchlauf, statt auf den
nächsten regulären Termin zu warten.

Auf einem Host, der oft neu startet, führt das zu vielen zusätzlichen
Snapshots. Vorgabe ist deshalb `no`.

---

## Die Zeitumstellung

!!! warning "Gerechnet wird mit lokaler Zeit"

    Ein täglicher Termin um 02:30 kann in der Umstellungsnacht **ausfallen**
    (im Frühjahr existiert 02:30 nicht) oder **doppelt anstehen** (im Herbst
    gibt es sie zweimal).

    Wen das stört, legt den Termin auf eine Zeit außerhalb des Fensters —
    04:00 statt 02:30 — oder nimmt ein Intervall statt eines festen Termins.

---

## Wie oft ist richtig?

Es gibt keine allgemeingültige Antwort, aber eine brauchbare Faustregel: Der
Abstand ist die Datenmenge, die du im Ernstfall verlierst.

| Abstand | Verlust im schlimmsten Fall | Passt zu |
|---|---|---|
| 15 min | eine Viertelstunde Arbeit | Datenbanken, Warenwirtschaft |
| 1 h | eine Stunde | Anwendungsserver |
| täglich | ein Arbeitstag | Fileserver, Infrastruktur |
| monatlich | — | der lange Rückweg, „wie war es vor dem Update?" |

Was dagegen spricht, öfter zu sichern, ist der **Platz**: Jeder Snapshot hält
die alten Blöcke fest. Bei einer schreibfreudigen VM wächst das schnell. Deshalb
gehören kurze Intervalle immer mit kurzer [Vorhaltezeit](vorhaltezeit.md)
zusammen — 24 stündliche Snapshots über zwei Tage sind billiger als sieben
tägliche über eine Woche.

!!! tip "Gestoppte Gäste überspringen"

    Bei kurzen Intervallen lohnt sich `skip_stopped = yes`. Sonst sammelt eine
    abgeschaltete Test-VM stündlich Snapshots vom immer gleichen Zustand.