Backup-Strategie für Self-Hosted-Server

Viele Self-Hosted-Server laufen erstaunlich stabil, bis plötzlich genau der Moment kommt, in dem ein Backup wirklich gebraucht wird. Dann zeigt sich sehr schnell, ob überhaupt eine brauchbare Backup-Strategie vorhanden ist oder ob bisher nur Daten irgendwo kopiert wurden.

In dieser Anleitung bauen wir eine praxistaugliche Backup-Strategie für Self-Hosted-Server auf: Was gesichert werden muss, wie du Restic sinnvoll einsetzt, warum Offsite-Backups wichtig sind, wie Restore-Tests aussehen sollten und weshalb ein Notfallplan fast genauso wichtig ist wie das Backup selbst.

1. Was eine gute Backup-Strategie leisten muss

Ein gutes Backup ist nicht einfach nur eine Kopie von Daten. Es muss dir helfen, nach einem Fehler oder Ausfall wirklich wieder arbeitsfähig zu werden.

Eine brauchbare Strategie beantwortet mindestens diese Fragen:

• Welche Daten sind kritisch?
• Wie oft werden sie gesichert?
• Wo liegen die Sicherungen?
• Wie lange werden ältere Stände aufbewahrt?
• Wie läuft die Wiederherstellung konkret ab?
• Wer hat Zugriff auf Backup-Zugangsdaten und Wiederherstellungsschlüssel?

Wenn diese Punkte nicht klar sind, hast du meist keine echte Strategie, sondern eher eine Hoffnung.

2. Die 3-2-1-Regel als saubere Grundlage

Für kleinere und mittlere Self-Hosted-Umgebungen ist die klassische 3-2-1-Regel weiterhin sehr sinnvoll:

• 3 Kopien deiner Daten
• 2 verschiedene Speichermedien oder Speicherorte
• 1 Kopie ausserhalb des eigentlichen Servers oder Standorts

Ein praktisches Beispiel:

• Produktivdaten auf dem Server
• lokales Backup auf zweitem Datenträger oder NAS
• verschlüsseltes Offsite-Backup in ein externes Storage-Ziel

Gerade bei Brand, Hardware-Defekt, Fehlbedienung oder Ransomware-artigen Schäden ist die externe Kopie entscheidend.

3. Was auf einem Self-Hosted-Server überhaupt gesichert werden muss

Viele sichern nur Dateien und vergessen die eigentliche Konfiguration. Für einen Wiederaufbau brauchst du aber meist mehr.

Typische Sicherungsbereiche sind:

• Compose-Dateien, Systemdienste und Konfigurationsdateien
• .env-Dateien und andere geheime Variablen
• Datenbanken
• persistente App-Daten wie Uploads, Medien oder Dokumente
• Reverse-Proxy-Konfigurationen und Zertifikate
• Automatisierungs-Skripte, Cronjobs und Wartungsskripte
• Dokumentation, Zugangsdaten-Hinweise und Wiederherstellungsanweisungen

Ein Docker-Host ist also nicht nur ein Verzeichnis mit Volumes, sondern immer ein Zusammenspiel aus Daten, Konfiguration und Betriebswissen.

4. Restic als sehr gute Basis für Backups

Restic ist für viele Ubuntu- und Self-Hosted-Setups eine sehr gute Wahl. Es ist schnell einsatzbereit, verschlüsselt standardmässig, arbeitet mit Snapshots und unterstützt viele Ziele wie lokale Pfade, SFTP, Backblaze B2, S3-kompatiblen Speicher oder andere Backends.

Auf Ubuntu kannst du Restic in der Regel einfach installieren:

sudo apt update
sudo apt install restic

Danach definierst du ein Ziel, zum Beispiel ein lokales Repository:

export RESTIC_REPOSITORY=/backup/restic
export RESTIC_PASSWORD='ein-sehr-langes-backup-passwort'
restic init

Oder ein Offsite-Ziel per SFTP:

export RESTIC_REPOSITORY=sftp:backup@example.com:/srv/restic/server01
export RESTIC_PASSWORD='ein-sehr-langes-backup-passwort'

Wichtig: Das Restic-Passwort ist zentral. Ohne dieses Passwort sind die Backups praktisch wertlos. Bewahre es deshalb separat und sicher auf.

5. Was genau in Restic gesichert werden sollte

Du musst nicht blind das ganze System sichern. Oft ist es besser, gezielt die kritischen Bereiche aufzunehmen.

Ein typisches Beispiel für einen Docker-Host:

sudo restic backup \
  /etc \
  /home/ubuntu/stacks \
  /var/lib/docker/volumes \
  /root/scripts \
  /srv/data

Ob du /var/lib/docker/volumes direkt sichern willst, hängt von deinem Aufbau ab. Wenn du stattdessen mit klaren bind mounts arbeitest, ist das häufig übersichtlicher, weil du gezielt definierte Projektordner sicherst.

Für Datenbanken gilt: Ein Dateibackup kann reichen, aber ein zusätzlicher konsistenter Dump ist oft noch besser. Besonders bei PostgreSQL oder MySQL ist das sinnvoll.

6. Datenbank-Dumps vor dem eigentlichen Backup

Gerade bei produktiven Diensten würde ich vor dem eigentlichen Restic-Lauf wichtige Datenbanken exportieren. Das macht Restores oft deutlich einfacher.

Ein Beispiel für PostgreSQL:

mkdir -p /srv/backups/db
docker exec -t postgres pg_dumpall -U postgres > /srv/backups/db/postgres-all.sql

Oder gezielt eine einzelne Datenbank:

docker exec -t postgres pg_dump -U app appdb > /srv/backups/db/appdb.sql

Bei MySQL oder MariaDB funktioniert das sinngemäss ähnlich mit mysqldump.

Diese Dump-Dateien nimmst du anschliessend mit in das Restic-Backup auf.

7. Ein einfacher täglicher Backup-Ablauf

Ein pragmatischer Ablauf für kleinere Setups sieht so aus:

1. Datenbank-Dumps erzeugen
2. wichtige Konfigurations- und Datenverzeichnisse mit Restic sichern
3. alte Snapshots mit Retention-Regeln aufräumen
4. Erfolg oder Fehler per Mail oder Monitoring melden

Ein einfaches Beispielskript:

#!/usr/bin/env bash
set -euo pipefail

export RESTIC_REPOSITORY=sftp:backup@example.com:/srv/restic/server01
export RESTIC_PASSWORD='ein-sehr-langes-backup-passwort'

mkdir -p /srv/backups/db
docker exec -t postgres pg_dumpall -U postgres > /srv/backups/db/postgres-all.sql

restic backup /etc /home/ubuntu/stacks /srv/backups/db
restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Das ist bewusst einfach gehalten. Für grössere Umgebungen kommen oft Logging, Locking, Fehlerbehandlung und Alarmierung dazu.

8. Backups automatisieren

Ein manuelles Backup wird fast immer irgendwann vergessen. Nutze deshalb einen Cronjob oder einen systemd-Timer.

Beispiel mit Cron:

sudo crontab -e

Dann zum Beispiel:

30 2 * * * /root/scripts/backup.sh >/var/log/backup.log 2>&1

Noch sauberer ist oft ein systemd-Service mit Timer, weil du Status, Logs und Fehler besser verfolgen kannst. Für viele kleine Server reicht Cron aber völlig aus, solange du den Erfolg kontrollierst.

9. Offsite-Backups sind keine Kür

Ein Backup auf derselben Maschine oder im selben Rack schützt nicht gegen alle Risiken. Wenn der Server komplett ausfällt, kompromittiert wird oder das Dateisystem beschädigt ist, hilft dir ein lokales Backup oft nur begrenzt.

Gute Offsite-Ziele sind zum Beispiel:

• ein externer Linux-Server per SFTP
• Backblaze B2
• ein S3-kompatibler Objektspeicher
• ein zweiter Standort oder ein separates NAS

Wichtig ist dabei weniger das konkrete Produkt als die Trennung vom Primärsystem und die saubere Verschlüsselung.

10. Retention-Regeln bewusst festlegen

Backups ohne Aufbewahrungsstrategie wachsen irgendwann unkontrolliert. Definiere deshalb klar, wie lange du welche Stände behalten willst.

Ein vernünftiger Start ist oft:

• 7 tägliche Sicherungen
• 4 wöchentliche Sicherungen
• 6 monatliche Sicherungen

Mit Restic sieht das so aus:

restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Je nach Datenmenge, regulatorischen Anforderungen oder Kundenerwartungen kann das natürlich anders aussehen.

11. Restore-Tests sind Pflicht

Das vielleicht wichtigste Kapitel: Ein Backup, das nie testweise wiederhergestellt wurde, ist nicht verlässlich. Genau hier trennt sich Theorie von Praxis.

Ein sinnvoller Restore-Test kann so aussehen:

1. separates Testverzeichnis oder Testserver bereitstellen
2. einen definierten Snapshot zurückholen
3. Konfiguration und Daten prüfen
4. Datenbank-Dump testweise importieren
5. Anwendung oder Dienst kurz starten
6. dokumentieren, wie lange der Restore gedauert hat und welche Stolpersteine es gab

Mit Restic kannst du zum Beispiel in ein Zielverzeichnis wiederherstellen:

mkdir -p /tmp/restore-test
restic restore latest --target /tmp/restore-test

Schon dieser einfache Test zeigt oft sehr schnell, ob Pfade, Rechte und Datenstände wirklich so vorliegen, wie du es erwartest.

12. Einen Notfallplan mitdenken

Zur Backup-Strategie gehört immer auch ein Mini-Runbook für den Ernstfall. Halte mindestens fest:

• wo die Backups liegen
• welches Passwort oder welcher Schlüssel benötigt wird
• welche Dienste in welcher Reihenfolge wiederhergestellt werden
• welche DNS-, Proxy- oder Mail-Einstellungen danach geprüft werden müssen
• wer im Ernstfall informiert wird

Das klingt banal, spart im Stress aber sehr viel Zeit und verhindert hektische Fehlentscheidungen.

13. Was ich in der Praxis mindestens empfehlen würde

• tägliche automatisierte Backups
• zusätzliche Datenbank-Dumps
• verschlüsseltes Offsite-Ziel
• monatlicher Restore-Test für kritische Systeme
• klar dokumentierter Wiederherstellungsablauf
• sichere Ablage der Backup-Credentials ausserhalb des Servers

Damit hast du für viele kleine bis mittlere Self-Hosted-Umgebungen bereits eine deutlich professionellere Basis als nur mit gelegentlichen Kopieraktionen.

14. Fazit

Eine gute Backup-Strategie für Self-Hosted-Server besteht nicht nur aus einem Tool, sondern aus einem ganzen Ablauf: passende Sicherungsziele, klare Prioritäten, Automatisierung, Offsite-Kopien, Restore-Tests und dokumentierte Notfallschritte.

Restic ist dafür eine sehr starke Grundlage, weil es einfach genug für kleine Setups und gleichzeitig leistungsfähig genug für ernsthafte Betriebsumgebungen ist.

Tipp:
Wenn du heute nur einen einzigen Schritt umsetzt, dann plane einen echten Restore-Test ein. Genau dieser Test zeigt dir am schnellsten, wo deine aktuelle Strategie noch Lücken hat.