Platz vor jedem Snapshot pruefen, bei Mangel alte loeschen, per Mail warnen

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>
This commit is contained in:
duffyduck
2026-11-01 10:27:21 +01:00
co-authored by Claude Opus 5.5
parent d9d9345d03
commit 74be5aee59
21 changed files with 1125 additions and 26 deletions
+2 -1
View File
@@ -25,6 +25,7 @@ pvesnap [globale Optionen] <befehl> [optionen]
| `vms` | alle VMs und Container mit den Gruppen, in denen sie stecken |
| `list` | vorhandene pvesnap-Snapshots |
| `check` | Konfiguration prüfen |
| `mail-test` | Test-Mail mit den Einstellungen aus [`[mail]`](konfiguration.md#mail) senden |
| `config` (oder `edit`) | [ncurses-Editor](../sichern/editor.md) |
| `run` | fällige Gruppen jetzt ausführen |
| `prune` | nur aufräumen, nichts anlegen |
@@ -41,7 +42,7 @@ pvesnap [globale Optionen] <befehl> [optionen]
```bash
pvesnap run # was fällig ist
pvesnap run --force -g taeglich # diese Gruppe sofort
pvesnap run --force --dry-run # Probelauf
pvesnap --dry-run run --force # Probelauf
pvesnap run -g taeglich -g monatlich # zwei Gruppen
```
+17 -1
View File
@@ -20,6 +20,22 @@ pvesnap check
---
## Kein Snapshot wegen Platzmangel
```
VM 101 (web): kein Snapshot angelegt, zu wenig Platz ('data': 8.0G frei, 25.6G gebraucht) und nichts mehr loeschbar
```
Auf dem Storage ist weniger als `space_min_free` frei, und von dieser VM sind
nur noch die neuesten `space_keep` pvesnap-Snapshots übrig. Der Platz steckt
also woanders: bei anderen VMs oder von Hand angelegten Snapshots. Abhilfe schafft Aufräumen, mehr Speicher oder ein kleinerer Wert,
siehe [Platz vor dem Snapshot](../sichern/vorhaltezeit.md#platz-vor-dem-snapshot).
Ist der Speicher schon voll, stehen die Notfall-Befehle für Ceph und ZFS unter
[Früher „voll“ sagen](speicher.md#fruher-voll-sagen-damit-luft-zum-loschen-bleibt).
---
## Storage-Lock
```
@@ -272,7 +288,7 @@ und danach wieder gestartet.
```bash
pvesnap -v check # ausführlich
pvesnap -v run --force --dry-run # zeigt jeden pvesh-Aufruf
pvesnap -v --dry-run run --force # zeigt jeden pvesh-Aufruf
journalctl -u pvesnap -n 200 --no-pager
```
+53 -1
View File
@@ -47,6 +47,7 @@ systemctl reload pvesnap
| `retries` | `2` | zusätzliche Versuche, wenn eine Sperre belegt ist |
| `retry_delay` | `60s` | Wartezeit vor dem nächsten Versuch |
| `pause_between` | `0s` | Pause zwischen zwei Gästen |
| `space_settle` | `30s` | Geduld, bis nach dem Löschen bei Platzmangel der Platz zurückkommt |
| `run_on_start` | `no` | beim Dienststart sofort einen Durchlauf machen |
| `dry_run` | `no` | `yes` = nichts wirklich tun, nur protokollieren |
| `description` | siehe unten | Standard-Beschreibung aller Snapshots |
@@ -68,6 +69,47 @@ description = pvesnap | Gruppe: {group} | erstellt: {datetime} | Vorhaltezeit: {
---
## `[mail]`
Meldet per Mail, wenn wegen Platzmangels ein Snapshot ausfällt. Am bequemsten
im Editor: `pvesnap config`, Taste ++m++, dort sendet ++t++ eine Test-Mail. Von
der Kommandozeile geht das mit `pvesnap mail-test`.
```ini
[mail]
enabled = yes
server = mail.example.org
security = starttls
user = pvesnap@example.org
password = geheim
sender = pvesnap@example.org
recipients = admin@example.org, technik@example.org
```
| Schlüssel | Vorgabe | |
|---|---|---|
| `enabled` | `no` | Alarm einschalten |
| `server` | — | SMTP-Server |
| `security` | `starttls` | `starttls` (TLS nach dem Verbinden), `ssl` (SSL/TLS von Anfang an) oder `none` |
| `port` | passend zu `security` | `587`, `465` bzw. `25` |
| `tls_verify` | `yes` | Zertifikat des Servers prüfen; `no` nur bei selbstsignierten Zertifikaten |
| `user`, `password` | — | Anmeldung; ohne `user` wird nicht angemeldet |
| `sender` | — | Absender |
| `recipients` | — | Empfänger, mehrere mit Komma |
* Bietet der Server kein STARTTLS an, schlägt der Versand fehl. Auf Klartext
ausgewichen wird nie.
* Eine Anmeldung mit `security = none` lehnt `pvesnap check` ab, weil das Passwort
sonst im Klartext übertragen würde.
* Das Passwort steht im Klartext in der Datei. Der Editor setzt beim Speichern
die Rechte `600`; wer von Hand einträgt, macht das selbst. `pvesnap check` warnt,
wenn jeder die Datei lesen darf.
* Je Gruppe und Lauf geht höchstens eine Mail heraus, in der alle betroffenen
Gäste stehen. Bleibt das Problem bestehen, kommt sie bei jedem Lauf erneut.
* Scheitert der Versand, steht das im Protokoll. Die Snapshots laufen weiter.
---
## `[defaults]`
Vorgaben für **alle** Gruppen. Jede Gruppe darf sie einzeln überschreiben.
@@ -121,9 +163,12 @@ Einzelheiten unter [Zeitpläne](../sichern/zeitplan.md).
| `keep_count` | `0` | höchstens so viele je VM und Gruppe (`0` = unbegrenzt) |
| `keep_time` | `0` | nichts älter als (`0` = unbegrenzt) |
| `keep_min` | `0` | so viele bleiben in jedem Fall stehen |
| `space_min_free` | `20%` | so viel muss vor dem Snapshot frei sein, auch absolut (`20G`); `0` = keine Prüfung |
| `space_keep` | `7` | so viele bleiben je VM auch bei Platzmangel stehen, über alle Gruppen gezählt |
**Mindestens eine von `keep_count` und `keep_time` muss gesetzt sein.**
Einzelheiten unter [Vorhaltezeit](../sichern/vorhaltezeit.md).
Einzelheiten unter [Vorhaltezeit](../sichern/vorhaltezeit.md) und
[Platz vor dem Snapshot](../sichern/vorhaltezeit.md#platz-vor-dem-snapshot).
### Auswahl der Gäste
@@ -193,6 +238,13 @@ Damit die Datei lesbar bleibt, versteht pvesnap eine Reihe deutscher Synonyme:
| `anzahl`, `max_anzahl`, `behalte_anzahl` | `keep_count` |
| `vorhaltezeit`, `behalte_zeit`, `max_alter` | `keep_time` |
| `mindestens` | `keep_min` |
| `mindestens_frei` | `space_min_free` |
| `verschluesselung` | `security` |
| `benutzer` | `user` |
| `passwort` | `password` |
| `absender` | `sender` |
| `empfaenger` | `recipients` |
| `platzmangel_behalten` | `space_keep` |
| `alle` | `all` |
| `namen` | `names` |
| `typen` | `types` |
+155
View File
@@ -182,6 +182,161 @@ nennt den Grund, bevor etwas angelegt wird.
---
## Früher „voll“ sagen, damit Luft zum Löschen bleibt
Auf einem wirklich vollen Speicher stehen die VMs, und auch das Aufräumen kann
scheitern, weil Löschen selbst ein Schreibvorgang ist. Deshalb lohnt es sich, den Speicher schon bei etwa
80 % als voll zu behandeln. Im Notfall gibt man die Grenze kurz frei, räumt auf
und setzt sie wieder zurück.
Das gilt zusätzlich zu [`space_min_free`](../sichern/vorhaltezeit.md#platz-vor-dem-snapshot).
Beide Grenzen wirken aufeinander: `space_min_free` rechnet mit dem, was Proxmox
als frei meldet, und das schrumpft mit der Grenze. Auf einem Test-Cluster sank
`MAX AVAIL` mit `full = 0.80` von 41 auf 29 GiB. Bei einer Grenze von 80 % passt
deshalb `space_min_free = 15%` besser als die Vorgabe: pvesnap greift dann bei etwa
70 % der vollsten OSD ein, mit der Vorgabe von 20 % schon bei etwa 65 %.
### Ceph: die Ratios
```bash
ceph osd dump | grep ratio # aktuelle Werte
ceph df # MAX AVAIL je Pool
ceph osd df # Belegung je OSD; die vollste entscheidet
ceph health detail # wer ist nearfull, backfillfull, full?
```
| Ratio | Vorgabe | Was passiert, wenn eine OSD sie erreicht |
|---|---|---|
| `nearfull` | `0.85` | nur eine Warnung |
| `backfillfull` | `0.90` | Ceph verschiebt keine Daten mehr auf diese OSD |
| `full` | `0.95` | **Schreibvorgänge der VMs hängen**, bis wieder Platz da ist |
**Einrichten**, Beispiel „voll bei 80 %“. Die Werte müssen aufsteigend bleiben und
gelten sofort, ohne Neustart:
```bash
ceph osd set-nearfull-ratio 0.70
ceph osd set-backfillfull-ratio 0.75
ceph osd set-full-ratio 0.80
```
**Im Notfall**, wenn der Cluster `full` meldet:
```bash
pvesnap list -a # was belegt den Platz?
qm delsnapshot <vmid> <snapshot> # zuerst einfach versuchen
ceph -s # löst sich full von selbst?
ceph osd set-full-ratio 0.90 # wenn es hängt, oder die VMs sofort weiter sollen
ceph osd set-full-ratio 0.80 # nach dem Aufräumen sofort zurück
```
Bei einem Test mit Ceph 18.2 ging das Löschen trotz `full` durch: Snapshot und
ganze Platte waren nach Sekunden weg, der Platz nach 15 Sekunden zurück, `full` löste
sich von selbst, und die VMs konnten weiterschreiben. Das Anheben allein ließ die
hängenden Schreibvorgänge ebenfalls sofort weiterlaufen.
Verlassen sollte man sich darauf nicht. Der Test setzte `full` knapp unter die
Belegung, die OSDs hatten also noch reichlich echten Platz. Auf wirklich vollen OSDs
kann es anders aussehen, und ein früherer Vorfall mit einem vollgelaufenen Pool lief
genau so: Auch Löschen stand.
!!! danger "Nie über `0.96`"
Ab dem Failsafe-Wert (`ceph config get osd osd_failsafe_full_ratio`, Vorgabe
`0.97`) verweigern die OSDs selbst das Schreiben, egal was `full` sagt. Und
läuft eine OSD wirklich auf 100 %, startet sie unter Umständen nicht mehr.
Das Anheben ist keine Lösung, es verschafft nur Zeit zum Aufräumen.
!!! warning "Eine niedrige Grenze hat einen Preis"
Fällt ein Node aus, verteilt Ceph seine Daten auf die übrigen. Das hält bei
`backfillfull` an, mit `0.75` also früher, und der Cluster bleibt dann
ungeschützt, bis Platz da ist oder die Ratio angehoben wird. Bei 4 Nodes und
3 Replikaten steigt die Belegung durch den Ausfall um ein Drittel.
### ZFS: die Notreserve
ZFS hat keine solche Ratio. Die Grenze muss man **vorher** einrichten, im Ernstfall
lässt sie sich nicht mehr nachholen. Am einfachsten ist ein leeres Dataset, das
Platz reserviert. Beispiel: ein Pool `tank` mit 10 TiB, voll bei 80 %:
```bash
zpool list tank # Größe des Pools
zfs create -o refreservation=2T -o canmount=off -o mountpoint=none tank/notreserve
zfs list -o name,used,avail tank tank/notreserve
```
**Im Notfall**, wenn VMs `No space left on device` melden:
```bash
zfs set refreservation=none tank/notreserve # Reserve freigeben
pvesnap list -a # was belegt den Platz?
zfs list -t snapshot -o name,used -s used # die größten Snapshots zuletzt
qm delsnapshot <vmid> <snapshot> # aufräumen
zfs set refreservation=2T tank/notreserve # danach sofort zurück
```
Das Zurücksetzen gelingt erst, wenn genug Platz da ist. Sonst meldet ZFS
`size is greater than available space`, dann muss weiter aufgeräumt werden.
**Was man dabei sieht** (gemessen an einem kleinen Testpool mit 200 MiB Reserve,
vollgeschrieben):
| Stelle | Anzeige | |
|---|---|---|
| `zpool list` | `CAP 65 %` | die echte Belegung der Laufwerke, die Reserve zählt nicht |
| `zfs list` | `AVAIL 0` | das ist die Grenze, an die die VMs stoßen |
| Proxmox-Storage auf einem Dataset (`tank/data`) | 100 % von 631 MiB | die Gesamtgröße schrumpft um die Reserve |
| Proxmox-Storage auf dem Pool selbst (`tank`) | 100 % von 832 MiB | Gesamtgröße bleibt, die Reserve zählt als belegt |
Der Pool wird dabei **nicht schreibgeschützt**. Lesen geht weiter, neue Daten
scheitern mit `No space left on device`, und das Löschen von Dateien und Snapshots
klappte im Test auch ohne Freigabe der Reserve. Für die VMs ist das trotzdem ein
Ausfall: Sie bekommen Schreibfehler, und je nach Einstellung hält Proxmox sie an.
!!! note "Alternative: Quota"
`zfs set quota=8T tank/data` wirkt genauso und zählt Snapshots mit, begrenzt
aber nur dieses Dataset und seine Kinder. Im Notfall `zfs set quota=9T tank/data`.
Die Notreserve ist einfacher, weil sie unabhängig vom Aufbau des Pools für alles
gilt.
!!! warning "Dick angelegte Zvols: Ein Snapshot kostet sofort Platz"
Ohne `sparse` am Storage reserviert Proxmox die ganze Platte, und diese
Reservierung muss auch nach dem Snapshot gelten. Alles, was seit dem letzten
Snapshot geschrieben wurde, wird deshalb beim Anlegen zusätzlich belegt. Fehlt
der Platz, scheitert der Snapshot mit `out of space`. Bei dünn angelegten Zvols
(`sparse 1`) kostet er nichts.
Das lässt sich exakt ausrechnen:
```bash
zfs get -Hp refreservation,usedbyrefreservation tank/data/vm-100-disk-0
# Kosten = refreservation - usedbyrefreservation
```
pvesnap rechnet genau das ein und prüft `frei ≥ Kosten + space_min_free`, die
Reserve bleibt also auch nach dem Snapshot frei. `pvesnap --dry-run run --force`
zeigt die Rechnung, ohne etwas zu ändern:
```
VM 100 (web): 'zfs': 1.1G frei, Snapshot belegt sofort 100.6M, danach frei 992.2M, Reserve 50.0M
```
Die Werte liefert die Proxmox-API nicht. Läuft der Gast auf einem anderen Node,
fragt pvesnap sie per `ssh` ab, über den Schlüssel, den Proxmox im Cluster ohnehin
einrichtet. Klappt das nicht, steht eine Warnung im Protokoll und das Volume zählt
mit 0, gelöscht wird deswegen nichts.
Das Löschen alter Snapshots gibt bei Zvols nur frei, was allein dieser Snapshot
festhält. Überschreibt eine VM immer dieselben Blöcke, ist das viel, sonst wenig.
---
## Empfehlung
| Lage | |
+1
View File
@@ -14,6 +14,7 @@ Alle Oberflächen auf einer Seite. Zum Ausdrucken und Danebenlegen.
| ++c++ | Gruppe kopieren |
| ++d++ | Gruppe löschen |
| ++g++ | globale Einstellungen |
| ++m++ | Mail-Alarm einrichten, dort ++t++ für eine Test-Mail |
| ++v++ | Übersicht: welche VM in welcher Gruppe |
| ++s++ | speichern |
| ++r++ | Dienst neu laden |