Files
proxmox-snapshot-service/handbuch/docs/sichern/editor.md
T
duffyduckandClaude Opus 5 59e7224297 Handbuch auf MkDocs-Basis, mit Bildschirmfotos aus dem Programm
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>
2026-08-09 12:39:30 +02:00

187 lines
5.9 KiB
Markdown

# Der Konfigurationseditor
```bash
pvesnap config
```
Braucht `root` — der Editor schreibt nach `/etc/pvesnap/` und fragt Proxmox nach
dem Inventar.
Alles, was hier geht, geht auch von Hand in der INI-Datei. Der Editor hat aber
zwei Vorteile, die man beim Tippen nicht hat: Er zeigt **live, auf wie viele
Gäste eine Auswahl gerade zutrifft**, und er rechnet den **nächsten Termin**
aus, bevor man speichert.
---
## Die Gruppenliste
![Die Gruppenliste](../bilder/config-gruppen.svg)
Der Einstiegsbildschirm. Oben steht die Datei, an der gearbeitet wird, und
rechts daneben, ob der Dienst gerade läuft. Ein `*` vor dem Dateinamen bedeutet:
ungespeicherte Änderungen.
| Taste | |
|---|---|
| ++enter++ | Gruppe bearbeiten |
| ++space++ | Gruppe ein- oder ausschalten |
| ++n++ | neue Gruppe |
| ++c++ | Gruppe kopieren — der schnellste Weg zu einer Variante |
| ++d++ | Gruppe löschen |
| ++g++ | [globale Einstellungen](#globale-einstellungen) |
| ++v++ | [Übersicht: welche VM in welcher Gruppe?](#die-ubersicht) |
| ++s++ | speichern |
| ++r++ | [Dienst neu laden](#dienst-neu-laden) |
| ++q++ | Ende |
Die Spalte **Auswahl** fasst zusammen, wie die Gruppe ihre Gäste findet —
`Tags: produktion`, `alle VMs`, `VMIDs: 100-110`. Wer viele Gruppen hat, sieht
hier auf einen Blick, wo eine Maschine hineinfallen könnte.
---
## Eine Gruppe bearbeiten
![Eine Gruppe bearbeiten](../bilder/config-gruppe.svg)
Eine lange Maske in vier Abschnitten: **Allgemein**, **Zeitplan**,
**Vorhaltezeit**, **Welche VMs?**, **Snapshot-Optionen**. Pfeiltasten bewegen
sich, ++enter++ ändert ein Feld, ++space++ schaltet Ja/Nein um.
Zwei Zeilen darin sind keine Einstellungen, sondern Antworten:
!!! tip "Nächster Termin (Vorschau)"
```
Naechster Termin (Vorschau) Mo 10.08.2026 02:30 (taeglich um 02:30)
```
Rechnet sofort nach, was der eingestellte Zeitplan bedeutet. Damit fällt
ein Denkfehler auf, bevor er drei Wochen lang unbemerkt bleibt — etwa
`day_of_month = 31` in einem 30-Tage-Monat.
!!! tip "Trifft aktuell zu auf"
```
Trifft aktuell zu auf 6 Gast/Gaeste (100, 101, 102, 105, 110, 130)
```
Die Auswahlregeln, angewendet auf das echte Inventar — mitsamt VMIDs. Steht
dort `0 Gast/Gaeste`, ist meist ein Tag falsch geschrieben.
Oben in der Kopfzeile steht außerdem, wie die Snapshots dieser Gruppe heißen
werden:
```
Kurzname im Snapshot: auto-taeglich-JJJJMMTT-HHMMSS
```
---
## VMs aus einer Liste wählen
Auf dem Feld **VMs aus Liste wählen …** öffnet ++enter++ das Inventar; aus der
Gruppenmaske heraus geht auch direkt ++v++:
![Die VM-Auswahl](../bilder/config-vms.svg)
| Taste | |
|---|---|
| ++space++ | Gast an- oder abwählen |
| ++a++ | alle |
| ++n++ | keine |
| ++i++ | Auswahl umkehren |
| ++slash++ | filtern (Name, VMID oder Tag) |
| ++enter++ | übernehmen |
Die Spalte **Tags** ist der eigentliche Grund, hier hereinzuschauen: Sie zeigt,
womit die Gäste in Proxmox markiert sind — und damit, ob eine Auswahl über
`tags = …` besser wäre als eine feste Liste von VMIDs.
!!! note "Feste Listen altern schlecht"
Eine Auswahl über VMIDs muss bei jeder neuen VM angefasst werden. Eine
Auswahl über Tags nicht. Für alles, was länger als ein paar Wochen leben
soll, sind [Tags](auswahl.md#tags) die bessere Wahl.
---
## Globale Einstellungen
Taste ++g++ in der Gruppenliste:
![Globale Einstellungen](../bilder/config-global.svg)
Das gilt für alle Gruppen — Präfix, Prüfintervall, Wiederholungen bei belegter
Sperre, Standard-Beschreibung. Was welcher Wert genau bedeutet, steht unter
[Alle Einstellungen](../nachschlagen/konfiguration.md#global).
Der wichtigste ist **Testlauf (nichts wirklich tun)** — das `dry_run = yes` der
INI-Datei. Damit protokolliert der Dienst nur, was er täte. Zum Ausprobieren
einer neuen Konfiguration ohne Risiko.
---
## Die Übersicht
Taste ++v++ in der Gruppenliste:
![Übersicht: welche VM in welcher Gruppe](../bilder/config-uebersicht.svg)
Die Gegenprobe von der anderen Seite: nicht „welche Gäste hat diese Gruppe",
sondern **„in welchen Gruppen steckt dieser Gast"**. Wer hier steht, wird
gesichert. Wer `(keine Gruppe)` daneben stehen hat, nicht.
Das ist der Bildschirm, den man nach jeder Änderung einmal ansehen sollte. Er
deckt beide typischen Fehler auf: eine vergessene Maschine — und eine, die
versehentlich in vier Gruppen gleichzeitig liegt.
!!! example "Was hier auffällt"
Im Bild trägt `build-test` das Tag `nosnap` und fällt damit überall heraus —
gewollt. Die beiden Maschinen `db01-live` und `warenwirtschaft-w` sind
laufende [Wiederherstellungen](../wiederherstellen/index.md); sie stehen
ebenfalls in keiner Gruppe, weil die monatliche Gruppe
`exclude_tags = nosnap, pvesnap-recovery` gesetzt hat.
**Das ist ein Griff, der sich lohnt.** Ohne ihn bekämen kurzlebige
Wiederherstellungsmaschinen eigene Snapshots — die dann wiederum verhindern,
dass ihre Klone sauber verworfen werden können.
---
## Dienst neu laden
Taste ++r++ — entspricht `systemctl reload pvesnap`, ohne den Editor zu
verlassen. Der Editor nimmt einem dabei das Mitdenken ab:
<div class="ablauf" markdown>
Ungespeicherte Änderungen? → bietet vorher das Speichern an
Dienst gestoppt? → bietet das Starten an
Neuladen scheitert? → bietet einen Neustart an
</div>
Nach ++s++ fragt er ohnehin gleich, ob neu geladen werden soll. In der Kopfzeile
steht jederzeit, ob der Dienst läuft.
---
## Beim Speichern
!!! warning "Die INI-Datei wird neu geschrieben"
Eigene Kommentare gehen dabei verloren. Ein `[defaults]`-Abschnitt
ebenfalls — inhaltlich bleiben die Werte erhalten, sie stehen danach nur in
jeder Gruppe einzeln.
Eine Sicherung der alten Fassung wird als **`pvesnap.conf.bak`** abgelegt.
Wer eine handgepflegte Konfiguration mit vielen Kommentaren hat, bearbeitet sie
besser weiter im Texteditor. Der ncurses-Editor ist für alle anderen da — und
für die beiden Vorschauzeilen, die es im Texteditor nicht gibt.