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
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
d9d9345d03
commit
74be5aee59
@@ -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
|
||||
```
|
||||
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
|
||||
@@ -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` |
|
||||
|
||||
@@ -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 | |
|
||||
|
||||
@@ -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 |
|
||||
|
||||
@@ -92,7 +92,7 @@ Maschine gesichert wird und welche nicht.
|
||||
Nicht bis morgen früh warten wollen:
|
||||
|
||||
```bash
|
||||
pvesnap run --force -g taeglich --dry-run # Probelauf, ändert nichts
|
||||
pvesnap --dry-run run --force -g taeglich # Probelauf, ändert nichts
|
||||
pvesnap run --force -g taeglich # jetzt wirklich
|
||||
```
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ anderem:
|
||||
```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 --dry-run run --force # Probelauf, ändert nichts
|
||||
pvesnap prune -g stuendlich # nur aufräumen
|
||||
```
|
||||
|
||||
@@ -60,7 +60,7 @@ zwischen zwei Terminen schlicht nichts.
|
||||
|
||||
```bash
|
||||
pvesnap -c /root/test.conf check
|
||||
pvesnap -c /root/test.conf run --force --dry-run
|
||||
pvesnap -c /root/test.conf --dry-run run --force
|
||||
```
|
||||
|
||||
`-c` gilt für alle Unterbefehle. Zusammen mit `--dry-run` ein gefahrloser Weg,
|
||||
@@ -78,7 +78,7 @@ dry_run = yes
|
||||
oder einmalig:
|
||||
|
||||
```bash
|
||||
pvesnap run --force --dry-run
|
||||
pvesnap --dry-run run --force
|
||||
```
|
||||
|
||||
Protokolliert, was geschähe, ohne etwas anzulegen oder zu löschen:
|
||||
|
||||
@@ -123,6 +123,15 @@ einer neuen Konfiguration ohne Risiko.
|
||||
|
||||
---
|
||||
|
||||
## Mail-Alarm
|
||||
|
||||
Taste ++m++ in der Gruppenliste: SMTP-Server, Verschlüsselung (STARTTLS oder
|
||||
SSL/TLS), Anmeldung, Absender und Empfänger. ++t++ sendet sofort eine Test-Mail
|
||||
mit den angezeigten Werten, auch wenn sie noch nicht gespeichert sind. Alles
|
||||
Weitere steht unter [`[mail]`](../nachschlagen/konfiguration.md#mail).
|
||||
|
||||
---
|
||||
|
||||
## Die Übersicht
|
||||
|
||||
Taste ++v++ in der Gruppenliste:
|
||||
|
||||
@@ -51,13 +51,99 @@ bleibt immer einer übrig.
|
||||
|
||||
---
|
||||
|
||||
## Platz vor dem Snapshot
|
||||
|
||||
```ini
|
||||
space_min_free = 20% # so viel muss frei sein (auch absolut: 20G; 0 = keine Prüfung)
|
||||
space_keep = 7 # so viele bleiben auch bei Platzmangel stehen
|
||||
```
|
||||
|
||||
Vor jedem Snapshot sieht pvesnap auf **allen Storages der VM** nach, ob
|
||||
`space_min_free` auch danach noch frei bleibt. Die Werte oben gelten als Vorgabe,
|
||||
auch ohne Eintrag in der Konfiguration. Wer mehr oder weniger möchte, setzt sie
|
||||
in `[defaults]` für alle Gruppen, je Gruppe einzeln oder im
|
||||
[Editor](editor.md) unter *Mindestens frei*.
|
||||
|
||||
1. Genug Platz: Der Snapshot wird angelegt.
|
||||
2. Zu wenig Platz: Der **älteste** pvesnap-Snapshot der VM wird gelöscht, dann wird
|
||||
erneut geprüft. Das wiederholt sich, bis der Platz reicht. Weiter gelöscht
|
||||
wird dann nicht.
|
||||
3. Sind nur noch die neuesten `space_keep` übrig und es reicht immer noch
|
||||
nicht, entsteht für diese VM **kein** Snapshot. Das steht als Fehler im
|
||||
Protokoll, und die nächste VM kommt dran.
|
||||
|
||||
**Was geprüft wird:** `frei ≥ sofortiger Verbrauch + space_min_free`. Die Reserve
|
||||
bleibt also auch nach dem Snapshot frei und ist für das da, was die VM danach
|
||||
schreibt, denn wie groß ein Snapshot später wird, lässt sich nicht vorhersagen.
|
||||
|
||||
| | Sofortiger Verbrauch |
|
||||
|---|---|
|
||||
| Ceph, LVM-thin, dünne ZFS-Zvols, qcow2 | praktisch nichts |
|
||||
| [Dicke ZFS-Zvols](../nachschlagen/speicher.md#zfs-die-notreserve) | alles seit dem letzten Snapshot Geschriebene, exakt berechnet |
|
||||
| `vmstate = yes` | zusätzlich der zugewiesene RAM, als Obergrenze |
|
||||
|
||||
Eine Vorschau zeigt `pvesnap --dry-run run --force`: Je Storage steht dort, was frei
|
||||
ist, was der Snapshot belegen würde, was danach frei bleibt und wie groß die Reserve
|
||||
ist.
|
||||
|
||||
Dabei gilt:
|
||||
|
||||
* Gezählt wird **je VM über alle Gruppen**, anders als bei der normalen
|
||||
Vorhaltezeit. Ein voller Pool ist schlimmer als ein verlorener alter Stand.
|
||||
Bei Platzmangel kann eine stündliche Gruppe deshalb auch die Monatsstände
|
||||
derselben VM löschen, ebenso Snapshots von Gruppen, die es nicht mehr gibt.
|
||||
* Halbfertige Einträge werden zuerst entfernt und zählen nicht mit.
|
||||
* Das `keep_min` jeder Gruppe bleibt auch hier gewahrt.
|
||||
* Von Hand angelegte Snapshots bleiben auch hier unangetastet.
|
||||
* Lässt sich der Platz nicht feststellen, wird nichts gelöscht und der Snapshot
|
||||
trotzdem versucht.
|
||||
* Ein Klon-Quell-Snapshot (`snapshot is protected`) wird als Fehler gemeldet und
|
||||
übergangen, weiter geht es mit dem nächsten.
|
||||
* `pvesnap run --no-prune` löscht nie. Fehlt der Platz, entfällt der Snapshot.
|
||||
* `pvesnap --dry-run run` löscht nichts und kann deshalb nicht sehen, wann es
|
||||
reichen würde. Es nennt alle Snapshots, die infrage kämen.
|
||||
|
||||
**Wie viel Puffer?** Die Schwelle bleibt frei für das, was die VMs bis zum
|
||||
nächsten Lauf schreiben, und damit Löschen überhaupt noch funktioniert. Grobe
|
||||
Werte aus einem Ceph-Cluster mit 8 OSDs und 3 Replikaten:
|
||||
|
||||
| `space_min_free` | Vollste OSD | |
|
||||
|---|---|---|
|
||||
| `10%` | 86 % | schon über der `nearfull`-Warnung |
|
||||
| `15%` | 82 % | knapp darunter, wenig Reaktionszeit |
|
||||
| `20%` | 78 % | Vorgabe |
|
||||
| `30%` | 69 % | für viel Schreiblast oder kleine Pools |
|
||||
|
||||
Als Probe sollte der Puffer mindestens das Dreifache von dem abdecken, was im
|
||||
Pool zwischen zwei Läufen im schlimmsten Fall neu belegt wird. Bei großen Pools
|
||||
passt oft eine feste Größe wie `2T` besser.
|
||||
|
||||
Fällt deshalb ein Snapshot aus, kann pvesnap
|
||||
[per Mail warnen](../nachschlagen/konfiguration.md#mail). Wie man Ceph und ZFS
|
||||
schon vorher eine Grenze setzt, damit im Notfall Luft zum Löschen bleibt, steht
|
||||
unter [Früher „voll“ sagen](../nachschlagen/speicher.md#fruher-voll-sagen-damit-luft-zum-loschen-bleibt).
|
||||
|
||||
!!! note "`space_settle`: warten, bis der Platz zurückkommt"
|
||||
|
||||
Ceph und ZFS geben gelöschten Platz erst im Hintergrund frei. Würde pvesnap
|
||||
sofort nachsehen, wäre scheinbar noch nichts frei und der nächste Snapshot
|
||||
würde umsonst gelöscht. Deshalb wartet es, solange der freie Platz wächst,
|
||||
und geht erst weiter, wenn sich `space_settle` lang (Vorgabe `30s`, in
|
||||
`[global]`) nichts mehr getan hat. Auf einem Test-Cluster mit NVMe war der Platz
|
||||
nach wenigen Sekunden zurück; ohne die Wartezeit wurde dort ein Snapshot zu viel
|
||||
gelöscht. Bei HDDs und großen Snapshots dauert es länger. Das Löschen einer VM kann also dauern;
|
||||
die Arbeitssperre bleibt währenddessen gehalten.
|
||||
|
||||
---
|
||||
|
||||
## Getrennt je VM und Gruppe
|
||||
|
||||
Beide Grenzen zählen **pro Gast und pro Gruppe**, nicht insgesamt.
|
||||
|
||||
`keep_count = 24` bei 30 Maschinen heißt also: bis zu 720 Snapshots — aber je
|
||||
Maschine nur 24. Und eine VM, die in drei Gruppen steckt, hat 24 + 14 + 6
|
||||
Snapshots nebeneinander, die sich nicht gegenseitig verdrängen.
|
||||
Snapshots nebeneinander, die sich nicht gegenseitig verdrängen. Einzige Ausnahme
|
||||
ist der [Platzmangel](#platz-vor-dem-snapshot).
|
||||
|
||||
---
|
||||
|
||||
@@ -89,7 +175,7 @@ vor-update-14.2 ← wird nie angefasst
|
||||
```bash
|
||||
pvesnap prune # alle Gruppen
|
||||
pvesnap prune -g stuendlich # nur diese
|
||||
pvesnap prune --dry-run # zeigt, was wegkäme
|
||||
pvesnap --dry-run prune # zeigt, was wegkäme
|
||||
```
|
||||
|
||||
Praktisch nach dem Verkürzen einer Vorhaltezeit: Der Dienst würde erst beim
|
||||
|
||||
Reference in New Issue
Block a user