DevOps 8 Min Lesezeit

VPS Backup-Strategie 2026 – 3-2-1-Regel richtig umsetzen

Warum VPS-Backups 2026 wichtiger sind als je zuvor

Die Zahl der VPS-Instanzen ist in den letzten Jahren explodiert – parallel dazu ist die Angriffsfläche gewachsen. Ransomware-Gruppen haben 2025 erstmals massenhaft virtuelle Maschinen bei kleineren Hostern verschlüsselt, weil dort Snapshots und Backups oft im selben Rechenzentrum wie die Produktionsdaten lagen. Wer nur auf den Hoster-Snapshot vertraut, hat im Ernstfall kein Backup, sondern eine Kopie – und die verschwindet mit dem Account.

Gleichzeitig sind die Preise für Object Storage gefallen. Backblaze B2 liegt 2026 bei rund 6 US-Dollar pro TB und Monat, Wasabi bei etwa 6,99 US-Dollar, Hetzner Object Storage startet bei 4,99 € für 1 TB. Eine saubere 3-2-1-Strategie kostet damit für einen typischen 80-GB-VPS weniger als 5 € im Monat – ein Bruchteil dessen, was ein Datenverlust kostet.

Dieser Guide zeigt dir, wie du die 3-2-1-Regel auf einem VPS konkret umsetzt: mit restic oder borg, systemd-Timern, Verschlüsselung, Restore-Tests und einem belastbaren Disaster-Recovery-Playbook. Alle Befehle sind kopierfertig und für Debian 13 / Ubuntu 24.04 LTS getestet.

Die 3-2-1-Regel – und warum 3-2-1-1-0 heute Standard ist

Die klassische 3-2-1-Regel besagt: 3 Kopien der Daten, auf 2 verschiedenen Medientypen, davon 1 Kopie offsite. Für einen VPS heißt das konkret: die Produktionsdaten auf dem Server, ein lokaler Snapshot oder Backup-Dump auf einem zweiten Volume, und ein verschlüsseltes Repository in einem Object Storage eines anderen Anbieters.

2026 reicht das vielen Compliance-Anforderungen nicht mehr. Die erweiterte 3-2-1-1-0-Regel ergänzt zwei Punkte: eine zusätzliche Kopie offline oder immutable (Air Gap, WORM-Storage, Band) und 0 Fehler bei der Verifikation – also regelmäßig getestete Restores.

RegelBedeutungUmsetzung auf dem VPS
3 KopienProduktiv + 2 BackupsLive-Daten, lokales Repo, Offsite-Repo
2 MedienKein Single Point of FailureNVMe-Volume + Object Storage (S3)
1 OffsiteGeografisch getrenntAnderer Provider, andere Region
1 ImmutableNicht löschbar/änderbarS3 Object Lock, Hetzner Immutability
0 FehlerRestore verifiziertMonatlicher Restore-Test, restic check

Wichtig: Ein Snapshot beim Hoster zählt nicht als eigenständige Kopie, wenn er im selben Storage-Cluster liegt. Er schützt gegen Fehlkonfiguration, nicht gegen Account-Sperrung, Ransomware oder einen RZ-Ausfall.

RPO und RTO festlegen, bevor du ein Tool wählst

Bevor du irgendein Backup-Tool installierst, definiere zwei Zahlen: RPO (Recovery Point Objective – wie viel Datenverlust ist akzeptabel?) und RTO (Recovery Time Objective – wie lange darf die Wiederherstellung dauern?). Ohne diese Werte ist jede Backup-Strategie geraten.

WorkloadTypisches RPOTypisches RTOBackup-Intervall
Statische Website24 h4 htäglich
WordPress / Shop1 h1 hstündlich DB, täglich Files
Gameserver (Minecraft)15 min30 minalle 15 min Welt-Save
PostgreSQL-Produktion5 min30 minWAL-Archiv + tägl. Basebackup
CI/CD-Runner24 h8 hwöchentlich (Config only)

Ein RPO von 5 Minuten bedeutet zwingend kontinuierliche Archivierung (WAL-Shipping, Binlogs) – kein nächtliches Vollbackup kann das leisten. Umgekehrt ist für einen statischen Webserver ein tägliches restic-Backup völlig ausreichend und spart Storage-Kosten.

Schreibe RPO/RTO in dein Runbook und überprüfe sie nach jedem Restore-Test. Wenn der gemessene Restore 4 Stunden dauert, dein RTO aber 1 Stunde beträgt, hast du ein Problem – kein Backup-Problem, sondern ein Prozessproblem.

Backup-Typen im Vergleich: Full, Incremental, Differentiell, Snapshot

Full Backups kopieren alles, sind einfach zu restoren, brauchen aber viel Platz und Bandbreite. Incrementals sichern nur Änderungen seit dem letzten Backup – klein und schnell, aber die Restore-Kette ist lang. Differentielle Backups sichern alles seit dem letzten Full – Kompromiss aus Größe und Restore-Aufwand.

Moderne Tools wie restic und borg arbeiten deduplizierend und content-addressed: Jeder Chunk wird per Hash identifiziert, identische Blöcke nur einmal gespeichert. Ein 80-GB-VPS mit 60 GB unveränderlichen Mediendateien erzeugt dadurch tägliche Increments von oft nur 200–800 MB statt 80 GB.

Snapshots (LVM, ZFS, Btrfs, Proxmox) sind kein Backup, aber ein hervorragendes Werkzeug für konsistente Backups: Du erzeugst einen Snapshot, sicherst daraus, löschst ihn wieder. So bekommst du ein konsistentes Filesystem-Abbild, ohne den Dienst zu stoppen.

# LVM-Snapshot für konsistentes Backup (5 GB Puffer)
lvcreate --size 5G --snapshot --name snap_root /dev/vg0/root
mount /dev/vg0/snap_root /mnt/snapshot -o ro
restic backup /mnt/snapshot --tag lvm-snapshot
umount /mnt/snapshot && lvremove -f /dev/vg0/snap_root

Achtung bei Datenbanken: Ein reiner Filesystem-Snapshot einer laufenden MySQL-Instanz ist nur konsistent, wenn du vorher FLUSH TABLES WITH READ LOCK ausführst oder das InnoDB-Redo-Log mitsicherst. Sauberer ist immer ein logischer Dump.

Tool-Vergleich 2026: restic, borg, rsync, Kopia, PBS

Die Tool-Wahl entscheidet über Restore-Geschwindigkeit, Speicherbedarf und Betriebsaufwand. Hier ein praxisnaher Vergleich für VPS-Setups:

ToolDeduplizierungVerschlüsselungBackendsStärke
resticJa (Content-defined)AES-256, repokeyS3, B2, SFTP, REST, rcloneEinfach, viele Backends
borgbackupJa (sehr effizient)AES-256, repokey-blake2SSH, lokale PfadeBeste Dedup-Rate
KopiaJaAES-256-GCMS3, B2, SFTP, WebDAVGUI, Policies, schnelle Restores
rsync + tarNeinNur via GPGAllesUniversell, keine Abhängigkeiten
Proxmox Backup ServerJa (Chunk-basiert)AES-256Eigenes RepoVM/Container-Backups, Verify

Für einen einzelnen VPS mit Offsite-S3 ist restic 2026 die pragmatischste Wahl: statisches Binary, keine Abhängigkeiten, exzellente S3-Unterstützung. Läuft dein Backup-Ziel per SSH (z. B. eine Hetzner Storage Box), ist borg wegen der besseren Dedup-Rate oft sparsamer.

Bei mehreren VMs auf einem Proxmox-Host ist PBS klar überlegen: inkrementelle VM-Backups, integrierte Verifikation und ein Restore-UI. Für Container-Workloads auf Kubernetes nutzt du besser Velero mit einem S3-Backend.

Praxis: restic auf einem VPS einrichten

Installation und Initialisierung dauern unter fünf Minuten. Wir nutzen Backblaze B2 als Offsite-Ziel, weil es S3-kompatibel und günstig ist.

apt install -y restic
# Passwort sicher ablegen, NICHT im Repo
openssl rand -base64 32 > /root/.restic-password
chmod 600 /root/.restic-password

export RESTIC_REPOSITORY="s3:https://s3.eu-central-003.backblazeb2.com/vps01-backup"
export RESTIC_PASSWORD_FILE=/root/.restic-password
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

restic init

Danach das erste Backup. Wichtig sind sinnvolle Excludes: Caches, Socket-Dateien, /proc, /sys und Datenbank-Verzeichnisse, die du separat dumpst.

restic backup /etc /root /home /var/www /opt /srv \
  --exclude-caches \
  --exclude '/var/lib/mysql' \
  --exclude '/var/cache' \
  --exclude '/tmp' \
  --exclude '*.sock' \
  --tag daily

Für Datenbanken erzeugst du vorher einen logischen Dump und sicherst diesen mit:

# PostgreSQL
pg_dumpall -U postgres | zstd -19 > /var/backups/pg-$(date +%F).sql.zst
# MySQL/MariaDB
mysqldump --single-transaction --quick --routines --all-databases \
  | zstd -19 > /var/backups/mysql-$(date +%F).sql.zst
# Minecraft
screen -S mc -X save-off && screen -S mc -X save-all
tar -czf /var/backups/mc-$(date +%F).tar.gz /srv/minecraft/world
screen -S mc -X save-on

Retention, Pruning und Immutability

Ohne Retention-Policy wächst dein Repository unbegrenzt. Eine bewährte Staffelung für VPS-Backups ist 7 tägliche, 4 wöchentliche, 12 monatliche Snapshots – das deckt die meisten Ransomware-Fälle ab, bei denen die Verschlüsselung erst nach Wochen auffällt.

restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2 \
  --prune

--prune entfernt nicht mehr referenzierte Datenblöcke. Bei großen Repos dauert das mehrere Minuten und kostet API-Requests – plane es maximal wöchentlich ein, nicht bei jedem Lauf.

Für die Immutability-Komponente der 3-2-1-1-0-Regel aktivierst du S3 Object Lock im Compliance-Modus mit z. B. 30 Tagen. Damit kann selbst ein Angreifer mit gültigen API-Keys die Backups der letzten 30 Tage nicht löschen. Backblaze B2 unterstützt Object Lock ebenfalls; Hetzner Object Storage bietet seit 2025 eine Immutability-Option.

Kalkuliere die Kosten: 80 GB VPS, 60 % Änderungsrate, 12 Monate Retention ergeben bei restic-Dedup typischerweise 150–250 GB im Repository – bei B2 also rund 1,50 US-Dollar pro Monat. Selbst mit Object Lock und Versionierung bleibst du unter 3 Euro.

Automatisierung mit systemd-Timer statt Cron

Cron funktioniert, aber systemd-Timer bieten Logging, Abhängigkeiten und RandomizedDelaySec – wichtig, damit nicht alle VPS gleichzeitig um 03:00 Uhr den Storage fluten.

# /etc/systemd/system/vps-backup.service
[Unit]
Description=restic backup to B2
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStartPre=/usr/local/bin/db-dump.sh
ExecStart=/usr/local/bin/restic-backup.sh
ExecStartPost=/usr/local/bin/restic-forget.sh
Nice=10
IOSchedulingClass=idle
# /etc/systemd/system/vps-backup.timer
[Unit]
Description=Run VPS backup daily

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=45m
Persistent=true

[Install]
WantedBy=timers.target

Aktiviere den Timer mit systemctl enable --now vps-backup.timer und prüfe den nächsten Lauf per systemctl list-timers vps-backup. Logs landen automatisch im Journal: journalctl -u vps-backup.service -n 100.

Persistent=true sorgt dafür, dass ein verpasster Lauf (Server war aus) nachgeholt wird. IOSchedulingClass=idle verhindert, dass das Backup die Produktions-IO ausbremst – auf einem kleinen VPS mit Shared-NVMe ist das Gold wert.

Verschlüsselung und Schlüsselmanagement

restic und borg verschlüsseln clientseitig, bevor Daten den Server verlassen. Der Storage-Anbieter sieht nur Chiffrate. Das ist gut – macht aber das Passwort zur kritischsten Komponente deiner Strategie. Verlierst du das Passwort, sind alle Backups unwiederbringlich verloren.

Für Teams bietet sich HashiCorp Vault oder SOPS mit Age-Keys an. Bei restic kannst du zusätzlich --repository-file und Umgebungsdateien mit chmod 600 nutzen, damit Secrets nicht in der Prozessliste auftauchen.

Ein häufiger Fehler: Das Backup-Passwort liegt auf demselben VPS wie die Backups. Bei einem vollständigen Server-Kompromiss hat der Angreifer beides – und kann das Offsite-Repository löschen. Deshalb ist Object Lock (Immutability) so wichtig.

Monitoring, Verifikation und Restore-Tests

Ein Backup, das nie getestet wurde, existiert nicht. Plane drei Ebenen der Verifikation ein: technische Integrität, Vollständigkeit und echter Restore.

# 1. Integrität: 5 % der Datenblöcke pro Lauf prüfen
restic check --read-data-subset=5%

# 2. Vollständigkeit: Snapshot-Alter prüfen
restic snapshots --latest 1 --json | jq '.[0].time'

# 3. Echter Restore in ein Testverzeichnis
restic restore latest --target /tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /tmp/restore-test/etc/nginx

Für Monitoring eignet sich ein Healthchecks.io-Ping am Ende des Backup-Skripts (curl -fsS -m 10 https://hc-ping.com/<uuid>). Bleibt der Ping aus, alarmiert der Dienst nach 30 Minuten per E-Mail, Slack oder Telegram. Alternativ: Prometheus node_exporter mit Textfile-Collector und ein Alert auf backup_last_success_timestamp > 90000.

Der wichtigste Test ist der vollständige Restore auf einen frischen VPS. Miete einmal im Quartal einen kleinen Server für 4 €, spiele das Backup ein, starte die Dienste und dokumentiere die Dauer. Nur so kennst du dein echtes RTO. Bei einem 80-GB-VPS mit restic und B2 dauert ein Full-Restore realistisch 20–45 Minuten.

Disaster-Recovery-Playbook für den Ernstfall

Im Notfall zählt jede Minute – und niemand liest dann Dokumentation. Halte das Playbook daher unter 10 Zeilen und drucke es aus.

  1. Isolieren: Kompromittierten VPS vom Netz nehmen (Firewall-Regel oder shutdown), nicht löschen – Forensik.
  2. Zugänge rotieren: SSH-Keys, API-Tokens, DB-Passwörter, Cloud-Credentials.
  3. Neuen VPS provisionieren: gleiche Distro, gleiche IP optional per Floating IP.
  4. Basis-Setup: apt update && apt install restic, Repo-Zugang konfigurieren.
  5. Restore: restic restore latest --target / (bzw. in ein Staging-Verzeichnis und dann synchronisieren).
  6. Datenbank zurückspielen: Dump entpacken, psql -f bzw. mysql <.
  7. Dienste starten und Smoke-Tests fahren: HTTP-Status, Login, Checkout, Gameserver-Join.
  8. DNS umstellen (niedrige TTL vorher setzen, 300 s statt 86400 s).
  9. Post-Mortem innerhalb von 48 h, Backup-Strategie anpassen.

Ein oft vergessener Punkt: Der Restore muss auch die Systemkonfiguration abdecken – /etc mit SSH-Keys, Firewall-Regeln, Cronjobs, systemd-Units. Wer nur /var/www sichert, verbringt Stunden mit Rekonstruktion.

Setze DNS-TTLs mindestens 24 Stunden vor geplanten Migrationen auf 300 Sekunden. Das reduziert das Failover-Fenster von Stunden auf Minuten – ein kostenloser RTO-Gewinn.

Häufige Fehler und Kostenübersicht

Die teuersten Backup-Fehler sind selten technisch. Sie sind organisatorisch:

AnbieterPreis / TB / MonatEgressObject Lock
Backblaze B2~6,00 $3× Free, dann 0,01 $/GBJa
Wasabi~6,99 $Free (Fair Use)Ja
Hetzner Object Storage4,99 € (1 TB)1 TB freeJa (seit 2025)
AWS S3 Glacier IR~4,00 $0,03 $/GBJa
Hetzner Storage Box BX113,81 € (1 TB)unbegrenztNein (SFTP)

Für einen 80-GB-VPS mit 200 GB Repository landest du bei Hetzner Object Storage bei rund 1 € pro Monat, bei Backblaze B2 bei etwa 1,20 $. Rechne zusätzlich mit 0,50–2 € Egress-Kosten pro Restore – vernachlässigbar gegenüber einem Ausfall.

Der wichtigste Kostenfaktor ist ohnehin nicht Storage, sondern Zeit. Ein sauber automatisierter Backup-Stack kostet dich einmalig 3–4 Stunden Einrichtung und danach 15 Minuten pro Monat für Monitoring und Restore-Tests.

FAQ

Reicht ein Hoster-Snapshot als Backup aus?

Nein. Snapshots liegen in der Regel im selben Storage-Cluster wie die Produktionsdaten und werden mit dem Account gelöscht. Sie schützen gegen Fehlkonfiguration und versehentliches Löschen, aber nicht gegen Ransomware, Account-Sperrung oder einen Rechenzentrumsausfall. Für die 3-2-1-Regel brauchst du mindestens eine Kopie bei einem anderen Anbieter oder in einer anderen Region.

Wie oft sollte ich ein VPS-Backup machen?

Das ergibt sich aus deinem RPO. Für statische Websites reicht täglich, für Shops und Foren stündlich (Datenbank) plus täglich (Dateien), für Gameserver alle 15 Minuten für Welt-Saves. Wichtiger als die Frequenz ist die Konsistenz: Ein stündlicher inkonsistenter Dump hilft weniger als ein täglicher sauberer.

Was kostet eine 3-2-1-Backup-Strategie für einen VPS?

Für einen typischen 80-GB-VPS mit dedupliziertem Repository (150–250 GB) zahlst du bei Hetzner Object Storage rund 1 €, bei Backblaze B2 etwa 1,20 $ pro Monat. Hinzu kommen geringe Egress-Kosten beim Restore. Insgesamt bleibst du meist unter 3 € monatlich – inklusive Immutability/Object Lock.

restic oder borg – was ist besser für VPS-Backups?

restic ist einfacher zu betreiben, unterstützt S3, B2, SFTP und REST nativ und ist ein statisches Binary ohne Abhängigkeiten. borg hat die bessere Deduplizierungsrate und ist bei SSH-Zielen wie einer Hetzner Storage Box sparsamer. Für einzelne VPS mit Object Storage ist restic 2026 die pragmatischere Wahl, für große Repos über SSH lohnt borg.

Wie teste ich mein Backup richtig?

Drei Ebenen: restic check --read-data-subset=5% für die Integrität, ein automatischer Snapshot-Alters-Check für die Vollständigkeit und mindestens quartalsweise ein vollständiger Restore auf einen frischen VPS inklusive Dienste-Start und Smoke-Tests. Dokumentiere die gemessene Dauer – nur so kennst du dein echtes RTO und merkst, ob deine Strategie im Ernstfall trägt.

📖 Ähnliche Artikel