Showcase nachgezogen: restliche Portfolio-Dateien auf aktuellen Stand

07-Backup-Restore.md

@@ -12,13 +12,29 @@ pct set 101 -mp0 /nas/freigabe,mp=/srv/freigabe,backup=0
 
 `nas/backups` bewusst **nicht** als PVE-Storage registrieren (gleiche Begründung wie beim `nas`-Pool selbst, siehe `01-pve-host.md` Abschnitt 3) — `vzdump --dumpdir` schreibt direkt dorthin, kein `pvestatd`-Polling nötig. CT101s `mp0` (Bind-Mount von `/nas/freigabe`, 37GB) wird von Container-Backups ausgeschlossen, sonst läge die komplette NAS-Freigabe redundant auch im Backup-Ziel auf demselben Pool.
 
-## 2. PVE-Host: nächtlicher vzdump für alle 4 LXCs
+## 2. PVE-Host: nächtlicher vzdump für alle Instanzen
+
+⚠️ **Diese Sektion ist die häufigste Stelle, an der die Doku hinter der Realität zurückbleibt** —
+jede neue LXC/VM braucht einen Nachtrag hier, sonst fehlt sie stillschweigend im Backup. Stand
+halten heißt: bei jedem neuen Container/jeder neuen VM prüfen, ob diese Sektion noch stimmt.
+
+Läuft nicht mehr als roher Crontab-Einzeiler, sondern über ein versioniertes Skript
+(`scripts/vzdump-backup.sh`, ausgerollt nach `/usr/local/bin/`) mit ntfy-Erfolgs-/Fehlschlag-Meldung:
 
 ```bash
-(crontab -l 2>/dev/null; echo "0 3 * * * vzdump 100 101 102 103 --mode snapshot --compress zstd --dumpdir /nas/backups/pve --prune-backups keep-last=3 >> /var/log/vzdump-cron.log 2>&1") | crontab -
+(crontab -l 2>/dev/null; echo "0 3 * * * /usr/local/bin/vzdump-backup.sh") | crontab -
 ```
 
-LVM-Thin-Snapshot-Modus (`--mode snapshot`) → alle 4 Container laufen auf `local-lvm`, minimale Downtime. Vaultwarden (CT103, SQLite im WAL-Modus) ist damit ohne separates DB-Skript crash-konsistent abgedeckt — SQLite ist genau für diesen Fall ausgelegt.
+`vzdump-backup.sh` (Kern-Aufruf, aktueller Stand — **IDs bei jeder neuen Instanz hier
+nachziehen**, siehe Warnung oben):
+```bash
+vzdump 100 101 102 103 104 105 106 200 --mode snapshot --compress zstd --dumpdir /nas/backups/pve --prune-backups keep-last=3
+```
+
+LVM-Thin-Snapshot-Modus (`--mode snapshot`) → alle Instanzen laufen auf `local-lvm`, minimale
+Downtime. Vaultwarden (CT103, SQLite im WAL-Modus) ist damit ohne separates DB-Skript
+crash-konsistent abgedeckt — SQLite ist genau für diesen Fall ausgelegt. VM 200 (QEMU, nicht LXC)
+läuft im selben `vzdump`-Aufruf mit, Snapshot-Modus funktioniert für beide Typen identisch.
 
 ## 3. VPS: rsync/cron nachinstallieren
 
@@ -64,23 +80,31 @@ ssh root@<TS_IP_VPS> "echo 'restrict,command=\"rrsync -ro /root/backups/\" $PUBK
 
 → Der Key kann ausschließlich lesend aus `/root/backups/` syncen, keine Shell, kein Port-/Agent-Forwarding. Im Gegensatz zum `wolonly`-Key (`01-pve-host.md` Abschnitt 6) ist `restrict` hier unproblematisch — der Pull läuft per Cron ohne PTY-Anforderung, das PTY-Problem betraf nur Guacamoles SSH-Client.
 
-## 6. PVE-Host: nächtlicher Pull-Cron
+## 6. PVE-Host: Pull direkt im Anschluss an `vzdump`, kein eigener Cron-Eintrag
+
+`vps-backup-pull.sh` (der `rsync`-Pull) wird **nicht** über einen eigenen Cron-Zeitpunkt getriggert, sondern am Ende von `vzdump-backup.sh` aufgerufen — beide laufen damit in einem einzigen HDD-Wachfenster:
 
 ```bash
-(crontab -l 2>/dev/null; echo '0 4 * * * rsync -av -e "ssh -i /root/.ssh/backup_pull_key" root@<TS_IP_VPS>: /nas/backups/vps/ >> /var/log/vps-backup-pull.log 2>&1') | crontab -
+# letzte Zeile in /usr/local/bin/vzdump-backup.sh:
+/usr/local/bin/vps-backup-pull.sh
 ```
 
-Zeitlich nach beiden vorherigen Jobs (02:00 VPS-Backup, 03:00 vzdump).
+⚠️ **NICHT TUN: `vzdump-backup.sh` (03:00) und `vps-backup-pull.sh` als zwei getrennte Cron-Einträge eine Stunde auseinander laufen lassen** (ursprünglich als zwei getrennte Zeitpunkte gesetzt). Die NAS-HDDs gehen nach dem `vzdump`-Snapshot in ~5 Minuten wieder in Standby (Spindown-Timeout) — der komplette `vzdump`-Lauf dauert aber nur ~2 Minuten. Ein zweiter Cron-Job eine Stunde später weckt die Platten dadurch ein zweites Mal unnötig. Fix: `vps-backup-pull.sh` als letzten Schritt in `vzdump-backup.sh` aufrufen (kein eigener Cron-Eintrag mehr) — beide Backups passen zeitlich locker in ein gemeinsames Wachfenster.
 
 ⚠️ **NICHT TUN:** Auf dem Client den vollen Pfad wiederholen (`root@vps:/root/backups/ ziel/`). `rrsync -ro /root/backups/` fixiert das Restricted-Verzeichnis bereits serverseitig; ein vom Client mitgegebener Pfad wird (nach Entfernen des führenden `/`) daran **angehängt** — Ergebnis ist der doppelte, nicht existierende Pfad `/root/backups/root/backups/` (Fehler "No such file or directory"). Korrekt ist ein leerer Pfad nach dem Doppelpunkt: `root@<TS_IP_VPS>:` — das adressiert die Wurzel des Restricted-Verzeichnisses.
 
 ## 7. Restore
 
-**LXC (jede der 4 Instanzen):**
+**LXC (jede der sieben LXC-Instanzen: 100–106):**
 ```bash
 pct restore <vmid> /nas/backups/pve/vzdump-lxc-<vmid>-<timestamp>.tar.zst --storage local-lvm
 ```
-Vaultwarden (CT103) braucht keinen separaten Restore-Schritt — Tresor + `rsa_key.pem` sind im LXC-Restore enthalten.
+Vaultwarden (CT103) braucht keinen separaten Restore-Schritt — Tresor + `rsa_key.pem` sind im LXC-Restore enthalten. Weitere Dienste mit eigener DB im Container-Rootfs ebenso: alle Zustandsdaten liegen im Container selbst, keine externe DB.
+
+**VM (200, QEMU statt LXC — anderer Restore-Befehl):**
+```bash
+qmrestore /nas/backups/pve/vzdump-qemu-200-<timestamp>.vma.zst 200 --storage local-lvm
+```
 
 **Guacamole-Stack (VPS):** Compose-Stack aus dem Tar-Archiv wiederherstellen, dann DB einspielen:
 ```bash
@@ -94,6 +118,6 @@ docker compose up -d guacamole
 
 | Was | Wo (Quelle) | Mechanismus | Ziel | Rotation |
 |---|---|---|---|---|
-| 4 LXCs (100–103) | PVE-Host | `vzdump` Snapshot, 03:00 | `/nas/backups/pve` | keep-last=3 |
+| 7 LXCs (100–106) + VM 200 | PVE-Host | `vzdump` Snapshot, 03:00 | `/nas/backups/pve` | keep-last=3 |
 | Guacamole-DB + Configs | VPS | `pg_dump` + `tar`, 02:00 | `/root/backups` (VPS, Zwischenstand) | 7 Tage |
 | — Pull der VPS-Backups | PVE-Host | `rsync` über `backup_pull_key`, 04:00 | `/nas/backups/vps` | folgt VPS-Rotation |