k3s Disaster Recovery Testing and Edge Patterns

Comprehensive DR testing and edge-specific patterns for k3s — failover validation, scheduled snapshots, multi-cluster recovery, and RPO/RTO planning.

Wenn Sie self-hosten, sind Sie Ihr eigener Cloud-Provider. Kein SLA, kein Region-Failover, kein Support-Ticket, das man um 3 Uhr morgens eröffnen kann. Der Vorteil ist die volle Kontrolle. Der Nachteil: Wenn es kracht, liegt es an Ihnen.

Digitale Souveränität bedeutet nicht, seine Daten zu besitzen – es bedeutet, in der Lage zu sein, sie zurückzuholen.

Was „Disaster“ im Self-Hosted-Kontext tatsächlich bedeutet

Bevor wir über Tools sprechen, definieren Sie Ihre Failure Modes:

Ihre Backup-Strategie sollte alle diese Punkte abdecken. Nicht mit demselben Tool, sondern durch einen mehrschichtigen Ansatz.

Das Drei-Schichten-Backup-Modell

Schicht 1: Filesystem-Snapshots (Restic / Borg)

Für allgemeine Datei-Backups – Konfigurationen, Anwendungsdaten, User-Home-Verzeichnisse – sind Restic oder Borg der moderne Standard. Sie bieten:

• Deduplizierung — inkrementell für immer, ohne jede Version einzeln zu speichern
• Verschlüsselung — clientseitig, bevor die Daten Ihren Server verlassen
• Kompression — typischerweise 2-5x Ersparnis bei Text-/Log-Daten

restic init --repo s3:https://s3.eu-central-1.wasabisys.com/my-backup/bucket

# Backup /etc, /var/lib, and application data
restic backup /etc /var/lib/docker/volumes \
  --repo s3:... \
  --password-file /etc/restic/pw \
  --tag monthly-$(date +%Y-%m)

Borg bietet eine stärkere Deduplizierung für große Dateisätze; Restic hat eine breitere Backend-Unterstützung (S3, SFTP, lokal, REST-Server). Wählen Sie Restic, wenn Sie Cloud-Object-Storage nutzen möchten, und Borg, wenn Sie auf ein lokales NAS oder einen Remote-Server sichern.

Schicht 2: Database Dumps (PostgreSQL / MySQL)

Ein Backup eines Datenbank-Verzeichnisses auf Dateiebene ist riskant – Sie sichern Korruption, partielle Schreibvorgänge und inkonsistente Zustände mit. Verwenden Sie immer das native Dump-Tool der Datenbank.

# PostgreSQL: daily full + continuous WAL archiving
pg_dumpall -f /backup/postgres/daily-$(date +%Y-%m-%d).sql

# Or better: pgBackRest for point-in-time recovery
pgbackrest --stanza=main --type=full backup
pgbackrest --stanza=main --type=archived --set=weekly-full backup

Für PostgreSQL in der Produktion:

1. WAL-Archivierung — Streamen Sie WAL-Segmente an einen separaten Ort (S3, NFS, MinIO). Ermöglicht Point-in-Time Recovery bis auf die Sekunde genau.
2. pgBackRest — paralleles Backup/Restore, Checksum-Validierung, Delta-Restore. Der De-facto-Standard für ernsthaftes Postgres.
3. Testen Sie Ihren Restore — ein Backup, das noch nie wiederhergestellt wurde, ist ein Wunsch.

# Restore to a specific timestamp
pgbackrest --stanza=main --type=time \
  --target="2026-07-10 14:30:00+02" restore

Schicht 3: Off-Site / Off-Line

Ransomware, die Ihren Server verschlüsselt, wird auch Ihre angeschlossene Backup-Festplatte verschlüsseln. Schicht 3 durchbricht diese Kette.

• Off-site: Pushen Sie verschlüsselte Backups zu einem anderen Provider (Backblaze B2, Wasabi, rsync.net) mittels rclone oder restic mit einem anderen Remote.
• Off-line: Rotieren Sie wöchentlich ein USB-Laufwerk, das getrennt bleibt. Eine günstige Versicherung gegen Crypto-Locker.
• 3-2-1-Regel: Drei Kopien, zwei Medientypen, eine Kopie off-site.

# Restic to a second, off-site repository
restic backup /data \
  --repo sftp://backup-host:/srv/restic-repo \
  --password-file /etc/restic/pw-alt

Automatisierter Backup-Plan

Ein Zeitplan, der für die meisten Self-Hosted-Setups funktioniert:

Automatisieren Sie dies mit systemd-Timern oder einem cron-ähnlichen Tool:

# /etc/systemd/system/restic-backup.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh
Nice=19
IOSchedulingClass=idle

# /etc/systemd/system/restic-backup.timer
[Timer]
OnCalendar=*-*-* 02,10,18,22:00:00
RandomizedDelaySec=600
Persistent=true

Disaster Recovery Playbook

Szenario: Versehentliches rm -rf / im Docker-Datenverzeichnis

# 1. Alle Container stoppen, um Schreibvorgänge zu verhindern
docker stop $(docker ps -q)

2. /var/lib/docker/volumes mit Restic wiederherstellen

restic restore latest
--path /var/lib/docker/volumes
--target /
--repo s3:...

3. Datenbank-Integrität prüfen

docker exec db pgbackrest --stanza=main check

4. Dienste starten und validieren

docker start $(docker ps -aq)

### Scenario: Database corruption from a failed upgrade

```bash
# 1. Datenbank-Container stoppen
docker stop postgres

# 2. Wiederherstellung mit pgBackRest auf einen Zeitpunkt vor dem Upgrade
pgbackrest --stanza=main --type=time \
  --target="2026-07-09 03:00:00+02" restore

# 3. Starten und Verifizieren
docker start postgres
psql -c "SELECT count(*) FROM pg_catalog.pg_tables;"

Scenario: Complete server loss (building fire / theft)

1. Provision new server from your IaC (Terraform/Ansible — yours is version-controlled, right?)
2. Restore system configs from Restic off-site repo
3. Restore databases from pgBackRest off-site repo
4. Verify DNS propagation, TLS certificates, health endpoints

This should take < 4 hours for a medium setup.

Real-World DR Plan: tobias-weiss.org

This site runs on a single-node Docker swarm with the following stack. Here's the actual backup posture for production:

Critical distinction: docker-compose.yml and all .env files live in a private git repo. Losing the server without this repo means rebuilding from memory. Keep your config repo backed up independently.

Backup Script

#!/bin/bash
# /usr/local/bin/daily-backup.sh - wird täglich um 03:00 Uhr via systemd timer ausgeführt
set -euo pipefail

BACKUP_DIR="/backup/$(date +%Y-%m-%d)"
RESTIC_REPO="s3:https://s3.eu-central-1.wasabisys.com/tobias-backup"
RESTIC_PW="/etc/restic/pw"

mkdir -p "$BACKUP_DIR"

# 1. PostgreSQL Dump
docker exec postgres pg_dumpall -U postgres > "$BACKUP_DIR/postgres-full.sql"

# 2. n8n Workflows exportieren
docker exec n8n n8n export:workflow --all --output=/backup/n8n-workflows

# 3. Docker Volumes via Restic sichern
restic backup /var/lib/docker/volumes \
  --repo "$RESTIC_REPO" \
  --password-file "$RESTIC_PW" \
  --tag "$(hostname)-daily-$(date +%Y-%m-%d)" \
  --exclude '*/postgres/data/*'   # ausgeschlossen — wir haben den SQL-Dump

# 4. Healthchecks benachrichtigen
curl -fsS -m 10 --retry 3 "https://hc-ping.com/YOUR-UUID"

Recovery Runbook

## Notfall-Wiederherstellung: Vollständiger Serververlust

**Ziel-Wiederherstellungszeit: 4 Stunden**

### Phase 1: Infrastruktur (30 Min.)

- [ ] Neuen VPS / Bare Metal bereitstellen (Intel/AMD, 32GB+ RAM, NVMe)
- [ ] Docker + Docker Compose Plugin installieren
- [ ] Config-Repo klonen: `git clone git@codeberg:user/server-config`
- [ ] `.env` Dateien aus 1Password / Bitwarden wiederherstellen

### Phase 2: Daten wiederherstellen (1 Std.)

- [ ] S3-Bucket mit Restic-Key mounten
- [ ] `restic restore latest --target / --repo s3:...`
- [ ] Volume-Checksummen prüfen

### Phase 3: Datenbanken (30 Min.)

- [ ] PostgreSQL-Container ohne Datenverzeichnis starten
- [ ] `pg_restore -U postgres -d postgres /backup/postgres-full.sql`
- [ ] Verifizieren: `docker exec postgres psql -c "SELECT count(*) FROM users;"`

### Phase 4: Dienste (1 Std.)

- [ ] `docker compose up -d` — prüfen, ob alle Dienste gesund sind
- [ ] Traefik-Dashboard prüfen: TLS-Zertifikate ausgestellt?
- [ ] Im Store anmelden: Transaktionshistorie intakt?
- [ ] listmonk prüfen: Kampagnenlisten geladen?

### Phase 5: Verifizierung (30 Min.)
- [ ] curl -I https://tobias-weiss.org — gibt 200 zurück
- [ ] Test-Stripe-Checkout bis zum Redirect durchführen
- [ ] Logs überwachen: keine ERROR-Einträge in den ersten 15 Minuten
- [ ] DR-Log aktualisieren: Datum, tatsächliche Uhrzeit, aufgetretene Probleme

Quarterly DR Drill

Schedule a 2-hour slot every quarter. The drill:

1. Clone the production repo to a staging VPS (DigitalOcean $6 droplet works)
2. Run the recovery runbook start-to-finish
3. Time each phase — if any exceeds the RTO target, update the runbook
4. Test a Stripe payment flow end-to-end
5. Document what broke and fix it before next quarter

Each quarter you don't test, you're accumulating risk. This is not theoretical — a silent Postgres upgrade or an expired S3 credential will only reveal itself during a drill or an actual disaster.

Validating Your Backup

A backup you never test is a disaster waiting to happen. Schedule a quarterly DR drill:

1. Spin up a disposable VM/container
2. Restore the full backup
3. Verify: can the application start? Can you log in? Is data current?
4. Measure: how long did it take? What failed? Update the runbook.

# Schneller Integritätscheck zwischen Backups
restic check --repo s3:... --password-file /etc/restic/pw
pgbackrest --stanza=main check

Monitoring

Don't rely on "it ran silently." For a deeper look at how production monitoring works across the full stack, see Production Observability Stack and Grafana Dashboards. Monitor your backups:

• Healthchecks.io (or self-hosted Uptime Kuma) — cron sends a ping after each successful backup; if it misses, you get an alert.
• Prometheus + Loki — log backup output to Loki, alert on ERROR in backup logs.
• Simple email — mail -s "Backup failed" in the error path. Better than nothing.

# Dem Backup-Skript voranstellen
trap 'curl -fsS -m 10 --retry 5 \
  https://hc-ping.com/YOUR-UUID/fail' ERR
curl -fsS -m 10 --retry 5 \
  https://hc-ping.com/YOUR-UUID/start

Was NICHT zu tun ist

• Nicht Backups auf demselben Disk-Array wie die Produktionsdaten speichern
• Nicht RAID als Backup verwenden (RAID dient der Verfügbarkeit, nicht der Durability oder Integrität)
• Nicht davon ausgehen, dass Docker-Volumes allein ausreichen — Volume-Backups sichern auch korrupte Zustände; immer mit Application-Level-Dumps kombinieren
• Nicht unverschlüsselte Backups verwenden (selbst bei „privatem“ Cloud-Speicher)
• Nicht das Testen der Wiederherstellung überspringen — der erste Versuch eines Restores sollte nicht während eines tatsächlichen Desasters stattfinden
• Nicht vergessen, die Backup-Konfiguration zu sichern (restic repo keys, pgBackRest-Konfiguration, vaultwarden secrets)

### Cross-Links

• Production Observability Stack — Infrastruktur-Sichtbarkeit für self-hosted Services
• Grafana Dashboards — effektive Monitoring-Dashboards erstellen
• Container Hardening Guide — sichere Container-Images reduzieren die Disaster-Angriffsfläche
• MinIO S3 Storage — Backup-Ziel für den Off-site-Layer
• Database Foundation — PostgreSQL Point-in-Time Recovery Setup
• Docker Multistage Builds — CI/CD-Pipeline-Integration
• SSL/TLS with Traefik — Zertifikats-Wiederherstellung während des DR

Zusammenfassung

Self-hosting bedeutet, Verantwortung zu übernehmen. Ein ordentlicher DR-Plan verwandelt ein „alles stehen und liegen lassen und in Panik geraten“-Ereignis in ein „dem Runbook folgen“-Verfahren. Das ist der Unterschied zwischen Operatoren und Opfern.