Files
proxmox-snapshot-service/handbuch/docs/schnellstart.md
T
duffyduckandClaude Opus 5.5 74be5aee59 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>
2026-11-01 10:27:21 +01:00

138 lines
3.8 KiB
Markdown

# Schnellstart
Vom leeren Host zur laufenden Sicherung. Rechne mit einer Viertelstunde,
davon zehn Minuten Nachdenken darüber, was wie oft gesichert werden soll.
---
## 1. Installieren
Auf dem Proxmox-Host, als `root`:
```bash
git clone <dieses-repo> pvesnap && cd pvesnap
./install.sh --with-webexplorer --port 8823
```
Ohne `--with-webexplorer` wird nur der Snapshot-Dienst eingerichtet; die
Web-Oberfläche lässt sich jederzeit nachrüsten. Einzelheiten:
[Installation](installation.md).
!!! note "Es passiert erst einmal nichts"
In der mitgelieferten Konfiguration stehen **alle Gruppen auf `enabled = no`**.
Der Dienst läuft, legt aber nichts an, bis du eine Gruppe einschaltest. Das
ist Absicht — niemand soll nach der Installation überrascht feststellen,
dass sein Storage vollläuft.
---
## 2. Gäste markieren
pvesnap sucht sich die Gäste über Proxmox-**Tags** aus. Das ist der bequemste
Weg, weil du danach nie wieder die Konfiguration anfassen musst: Eine neue VM
bekommt ihr Tag, und sie ist dabei.
In der Proxmox-Oberfläche bei jeder VM unter **Optionen → Tags**, oder auf der
Shell:
```bash
qm set 101 --tags produktion,datenbank
pct set 110 --tags produktion
```
Für den Anfang reicht ein einziges Tag, etwa `produktion`.
---
## 3. Eine Gruppe einschalten
```bash
pvesnap config
```
![Die Gruppenliste](bilder/config-gruppen.svg)
Mit den Pfeiltasten auf `taeglich`, dann:
<div class="ablauf" markdown>
`Leertaste` — schaltet die Gruppe ein (Spalte **Aktiv** springt auf `ja`)
`Enter` — öffnet sie, um Zeitplan und Auswahl zu prüfen
`s` — speichern
`r` — Dienst neu laden
</div>
In der Gruppe siehst du unten sofort, auf wie viele Gäste die Auswahl gerade
zutrifft — du musst also nicht raten, ob das Tag richtig geschrieben ist:
![Eine Gruppe bearbeiten](bilder/config-gruppe.svg)
---
## 4. Nachsehen, ob es stimmt
```bash
pvesnap check # meckert über Widersprüche in der Konfiguration
pvesnap vms # welche VM landet in welcher Gruppe?
pvesnap status # letzte und nächste Läufe
```
`pvesnap vms` ist der ehrlichste Test: Dort steht schwarz auf weiß, welche
Maschine gesichert wird und welche nicht.
---
## 5. Einmal von Hand auslösen
Nicht bis morgen früh warten wollen:
```bash
pvesnap --dry-run run --force -g taeglich # Probelauf, ändert nichts
pvesnap run --force -g taeglich # jetzt wirklich
```
Danach stehen die Snapshots in der Proxmox-Oberfläche unter **Snapshots** —
mit Namen wie `auto-taeglich-20260809-023000` und einer Beschreibung, an der
man sie wiedererkennt.
---
## 6. Den Ernstfall einmal proben
Das ist der Schritt, den fast alle auslassen — und der im Ernstfall den
Unterschied macht. Hol dir jetzt, in Ruhe, eine Datei aus einem Snapshot:
```bash
pvesnap-explorer 101
```
Snapshot auswählen, mit den Pfeiltasten durch das Dateisystem, `Leertaste` zum
Markieren, `F5` kopiert nach rechts auf den Host.
![Dateien kopieren](bilder/explorer-kopieren.svg)
Wenn du das einmal gemacht hast, weißt du im Notfall, wo die Tasten liegen.
---
## Fertig. Und dann?
| | |
|---|---|
| Mehrere Zeitpläne nebeneinander | [Sichern](sichern/index.md) — stündlich für die Datenbank, monatlich für den Rest |
| Etwas herausgeben, ohne Shell-Zugang | [Die Web-Oberfläche](holen/web.md) |
| Eine ganze Maschine zurückholen | [Wiederherstellen](wiederherstellen/index.md) |
| Austauschlaufwerke vorbereiten | [Austauschlaufwerke](wiederherstellen/transfer.md) — *vor* dem Notfall, nicht mittendrin |
!!! tip "Der eine Rat, wenn du nur einen mitnimmst"
Leg dir **jetzt** ein Austauschlaufwerk an und pack die Werkzeuge hinein,
die du im Notfall brauchst — `pg_dump`, ein Packprogramm, deine Skripte.
Im Ernstfall ist keine Zeit, so etwas zusammenzusuchen, und die
wiederhergestellte Maschine hat kein Netzwerk.