From c76ceb4c1055a1574363a6858163d8fc94272b78 Mon Sep 17 00:00:00 2001 From: arnol Date: Wed, 22 Jul 2026 21:18:42 +0200 Subject: [PATCH] Move 07-backup-restore.md to wiki --- 07-backup-restore.md | 99 -------------------------------------------- 1 file changed, 99 deletions(-) delete mode 100644 07-backup-restore.md diff --git a/07-backup-restore.md b/07-backup-restore.md deleted file mode 100644 index 4e225a3..0000000 --- a/07-backup-restore.md +++ /dev/null @@ -1,99 +0,0 @@ -# Backup & Restore — Laufzeit-Zustand (PVE-LXCs + VPS-Guacamole-Stack) - -Sichert den Laufzeit-Zustand, nicht nur Dateien: LXC-Configs, Datenbanken, Guacamole-Verbindungsdefinitionen/TOTP-Secrets, Vaultwardens verschlüsselten Tresor. Der ZFS-Mirror (`nas/freigabe`) deckt reinen Dateiverlust ab — dieses Kapitel deckt den Fall "Server/Container ist weg und muss aus dem Nichts wiederhergestellt werden". - -## 1. PVE-Host: Backup-Dataset + Ausschluss der NAS-Freigabe - -```bash -zfs create nas/backups -mkdir -p /nas/backups/pve /nas/backups/vps -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 - -```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 - -``` - -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. - -## 3. VPS: rsync/cron nachinstallieren - -```bash -apt update && apt install -y rsync cron -systemctl enable --now cron -``` - -⚠️ **NICHT vergessen:** Die minimale Debian-13-Installation auf dem VPS hat weder `rsync` (liefert `rrsync` mit, ab Version 3.4.x fertig unter `/usr/bin/rrsync`) noch `cron` vorinstalliert. Ohne `cron`-Paket schlägt `crontab -l`/`crontab -` mit "command not found" fehl. - -## 4. VPS: Backup-Skript für die Guacamole-Stack - -`/usr/local/bin/backup-guacamole.sh`: -```bash -#!/bin/bash -set -e -DEST=/root/backups -DATE=$(date +%F) -mkdir -p "$DEST" -docker exec guac-postgres pg_dump -U guacamole_user guacamole_db | gzip > "$DEST/guacamole_db_$DATE.sql.gz" -tar czf "$DEST/guacamole-opt_$DATE.tar.gz" --exclude=pg-data -C /opt guacamole -find "$DEST" -mtime +7 -delete -``` -```bash -chmod +x /usr/local/bin/backup-guacamole.sh -(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/backup-guacamole.sh >> /var/log/backup-guacamole.log 2>&1") | crontab - -``` - -`pg_dump` statt rohem Kopieren von `pg-data` — transaktionssicher bei laufendem Postgres, roher Kopiervorgang eines laufenden Datenverzeichnisses wäre das nicht. Rotation: 7 Tage lokal auf dem VPS (das eigentliche Archiv liegt nach Schritt 6 auf dem NAS). - -## 5. Restriktiver Pull-Key (VPS → NAS) - -Dediziertes Keypair auf dem PVE-Host, **nicht** `id_rsa` oder `wol_vps_key` wiederverwenden: -```bash -ssh-keygen -t ed25519 -f /root/.ssh/backup_pull_key -N "" -C "backup-pull@pve" -``` - -Public Key auf dem VPS in `authorized_keys` ergänzen: -```bash -PUBKEY=$(cat /root/.ssh/backup_pull_key.pub) -ssh root@ "echo 'restrict,command=\"rrsync -ro /root/backups/\" $PUBKEY' >> /root/.ssh/authorized_keys" -``` - -→ 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 - -```bash -(crontab -l 2>/dev/null; echo '0 4 * * * rsync -av -e "ssh -i /root/.ssh/backup_pull_key" root@: /nas/backups/vps/ >> /var/log/vps-backup-pull.log 2>&1') | crontab - -``` - -Zeitlich nach beiden vorherigen Jobs (02:00 VPS-Backup, 03:00 vzdump). - -⚠️ **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@:` — das adressiert die Wurzel des Restricted-Verzeichnisses. - -## 7. Restore - -**LXC (jede der 4 Instanzen):** -```bash -pct restore /nas/backups/pve/vzdump-lxc--.tar.zst --storage local-lvm -``` -Vaultwarden (CT103) braucht keinen separaten Restore-Schritt — Tresor + `rsa_key.pem` sind im LXC-Restore enthalten. - -**Guacamole-Stack (VPS):** Compose-Stack aus dem Tar-Archiv wiederherstellen, dann DB einspielen: -```bash -gunzip -c guacamole-opt_.tar.gz | tar x -C /opt # falls /opt/guacamole fehlt -cd /opt/guacamole && docker compose up -d postgres guacd -gunzip -c guacamole_db_.sql.gz | docker exec -i guac-postgres psql -U guacamole_user guacamole_db -docker compose up -d guacamole -``` - -## Referenz: Backup-Übersicht - -| Was | Wo (Quelle) | Mechanismus | Ziel | Rotation | -|---|---|---|---|---| -| 4 LXCs (100–103) | 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 |