duffyduckandClaude Opus 5
59e7224297
26 Kapitel in vier Teilen, in der Reihenfolge, in der man sie braucht: erst sichern, dann Dateien holen, dann ganze Maschinen wiederherstellen, dahinter der Nachschlagteil. Gebaut wird mit MkDocs + Material. Bewusst ohne Netzabhaengigkeiten: keine Schriften vom CDN (font: false), Volltextsuche mit deutschem Stemming liegt neben den Seiten. Im Notfall steht vielleicht das halbe Netz - dann nuetzt eine Doku im Internet nichts. handbuch/bauen.sh baut handbuch/site/ handbuch/bauen.sh ansehen Vorschau auf 127.0.0.1:8000 install.sh nimmt das gebaute Handbuch mit nach /usr/share/doc/pvesnap/handbuch/ - falls es vorliegt. Auf dem Host selbst wird nichts gebaut, mkdocs gehoert nicht auf einen Hypervisor. Die 28 Bildschirmfotos sind nicht abfotografiert, sondern erzeugt: Der echte Programmcode laeuft in einem Pseudo-Terminal gegen einen erfundenen Proxmox-Host (Attrappen fuer pvesh, perl und rbd), pyte baut den Bildschirm nach, heraus faellt ein SVG. Damit stimmen sie garantiert mit dem Programm ueberein, sind reproduzierbar und enthalten keine echten Daten. Die Werkstatt dafuer liegt unter handbuch/werkstatt/ samt LIESMICH.md. Nebenbei: die Schlussmeldung von install.sh warb noch mit --exchange, das mit dem eingebauten Austauschlaufwerk weggefallen ist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
138 lines
3.8 KiB
Markdown
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
|
|
```
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
---
|
|
|
|
## 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 run --force -g taeglich --dry-run # 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.
|
|
|
|
|
|
|
|
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.
|