Ein Site auf einem VPS selbst zu hosten kostet ein paar Euro im Monat und gibt die Kontrolle über den gesamten Stack zurück. Im Gegenzug wird das Backup zur vollen Verantwortung: Kein Shared-Hosting wacht im Hintergrund. Ein Server ohne getestetes Backup ist nicht bloß „gefährdet“, er ist ein aufgeschobener Ausfall. Dieser Leitfaden beschreibt eine vollständige, reproduzierbare Methode für eine WordPress- oder PHP-Site: Datenbank, Dateien, verschlüsselte externe Kopie, Rotation und vor allem eine geprüfte Wiederherstellung.
Warum das Backup „wenn ich dran denke“ immer scheitert
Ein manuelles Backup beruht auf einer wiederholten menschlichen Entscheidung — genau die Art Aufgabe, die ein voller Terminplan zuerst fallen lässt. Es scheitert auf drei vorhersehbare Weisen: Es läuft nicht oft genug, es liegt auf derselben Platte wie die Site — verschwindet also mit ihr — und es wird nie wiederhergestellt, um zu prüfen, dass es funktioniert. Ein nie getestetes Backup ist nur eine Annahme. Eine gute Methode holt den Menschen aus der täglichen Schleife und ruft ihn nur für einen monatlichen Wiederherstellungstest zurück.
Die 3-2-1-Regel, Version kleiner Server
Die 3-2-1-Regel bleibt der solideste Bezugspunkt: drei Kopien der Daten, auf zwei verschiedenen Medien, davon eine außer Haus. Auf einem bescheidenen VPS funktioniert sie ohne teure Hardware.
| Kopie | Ort | Rolle |
|---|---|---|
| Produktionsdaten | VPS-Platte | Die laufende Quelle |
| Lokales Backup | Zweites Volume oder eigener Ordner | Schnelle Wiederherstellung |
| Externes Backup | Verschlüsselter Objektspeicher (S3, B2) | Übersteht den Verlust des VPS |
Zwei Punkte zählen mehr als der Rest: Die externe Kopie muss verschlüsselt werden, bevor sie den Server verlässt, und die lokale Kopie ersetzt nie die externe. Ein Vorfall, der den VPS zerstört, nimmt beide Volumes mit, wenn sie auf derselben Maschine liegen.
Die Datenbank sauber sichern
Bei einer dynamischen Site enthält die Datenbank das Wesentliche: Inhalte, Konten, Bestellungen. Ein konsistenter Dump läuft ohne Sperren der Tabellen, mit einer einzigen Transaktion auf einer transaktionalen Engine wie InnoDB.
#!/usr/bin/env bash
# Sauvegarde de la base : dump compresse, date dans le nom
set -euo pipefail
STAMP=$(date +%F_%H%M)
DEST=/var/backups/db
mkdir -p "$DEST"
mariadb-dump --single-transaction --quick --lock-tables=false \
--defaults-extra-file=/root/.my.cnf ma_base \
| gzip -9 > "$DEST/ma_base_$STAMP.sql.gz"
Die Zugangsdatei ~/.my.cnf hält das Passwort aus dem Befehl heraus und damit aus der Shell-Historie und der Prozesstabelle. Sie sollte nur für das sichernde Konto lesbar sein, mit Rechten 600.
Die Dateien der Site sichern
Nicht jede Datei ist gleich viel wert: Code und hochgeladene Medien müssen gesichert werden, während Caches und Logs nichts beitragen und das Archiv unnötig aufblähen. Ein inkrementelles rsync auf ein lokales Volume ist schnell und übersichtlich.
# Fichiers du site : incrementiel via rsync vers un disque local
rsync -aH --delete \
--exclude 'wp-content/cache' \
--exclude '*.log' \
/var/www/monsite/ /var/backups/files/monsite/
Die Option --delete hält den lokalen Spiegel streng an der Quelle ausgerichtet; bewusst einzusetzen, denn eine Löschung auf der Site überträgt sich auf die lokale Kopie. Genau deshalb reicht die lokale Kopie nicht: Die Aufbewahrung entscheidet sich auf der externen Ebene.
Auslagern und verschlüsseln mit restic
Die externe Kopie rettet vor einem Brand im Rechenzentrum oder einem kompromittierten Konto. restic verschlüsselt clientseitig, dedupliziert und spricht nativ mit Objektspeicher — das Archiv verlässt den Server unlesbar für den Repository-Host.
# Externaliser + chiffrer avec restic (depot sur stockage objet S3)
export RESTIC_REPOSITORY="s3:https://s3.example.com/backups-monsite"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
restic backup /var/backups/db /var/backups/files --tag nightly
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
Der Befehl forget --prune wendet die Aufbewahrungsrichtlinie an und gibt den Speicher verworfener Snapshots tatsächlich frei. Das Repository-Passwort liegt in einer Datei außerhalb des Repositorys: geht es verloren, sind die Backups dauerhaft unlesbar.
Wo die externe Kopie speichern
Die Wahl des externen Repositorys wirkt sich auf Kosten und Wiederherstellungsgeschwindigkeit aus. Für eine selbst gehostete Site stechen drei Familien hervor. S3-kompatibler Objektspeicher — Backblaze B2, Scaleway, OVH, Wasabi — rechnet pro gespeichertem Gigabyte ab und bleibt am flexibelsten; die Ausgangspreise schwanken stark zwischen Anbietern und sollten vor einer Festlegung gelesen werden. Ein auf Backups spezialisierter Dienst wie rsync.net bietet SSH-Zugang und passt gut zu restic oder einem einfachen rsync. Schließlich kann ein zweiter Server, den man bereits kontrolliert, als Repository dienen, sofern er physisch vom ersten getrennt ist. Die entscheidende Regel bleibt dieselbe: Der Anbieter darf den Inhalt nie lesen können, was die clientseitige Verschlüsselung von restic unabhängig vom Repository garantiert.
Mit cron automatisieren und die Aufbewahrung festlegen
In einem einzigen Skript vereint, lassen sich diese Schritte in einer Zeile planen. Eine ruhige Nacht begrenzt die Wirkung des Dumps auf die Produktionsdatenbank.
# /etc/cron.d/backup-monsite -> 3h15 chaque nuit, journalise la sortie
15 3 * * * root /usr/local/sbin/backup-monsite.sh >> /var/log/backup.log 2>&1
Die Aufbewahrung wägt Speicherkosten gegen Verlaufstiefe ab. Die folgende Tabelle passt zu einer typischen Content-Site.
| Behaltene Frequenz | Dauer |
|---|---|
| Täglich | 7 Tage |
| Wöchentlich | 4 Wochen |
| Monatlich | 6 Monate |
Diese Richtlinie behält rund dreißig Snapshots — genug, um sich von einer spät entdeckten Beschädigung zu erholen, ohne die Objektspeicher-Rechnung zu sprengen.
Die Wiederherstellung testen: der Schritt, den alle überspringen
Es ist die einzige Prüfung, die beweist, dass die Kette funktioniert. Einmal im Monat genügt eine Wiederherstellung in einen Wegwerf-Ordner, um die Archivintegrität zu bestätigen und den Handgriff wach zu halten, damit er nicht an einem echten Ausfalltag erst entdeckt wird.
# Tester la restauration dans un dossier jetable, une fois par mois
restic snapshots
restic restore latest --target /tmp/restore-test
gunzip Ein Backup, das nie wiederhergestellt wird, ist kein Backup, sondern eine Annahme.
Orientierung. Zwei Kennzahlen rahmen jeden Wiederherstellungsplan: der RPO, wie viele Daten man zu verlieren akzeptiert (hier bis zu 24 h bei täglichem Rhythmus), und der RTO, die angestrebte Zeit bis zur Rückkehr in den Betrieb. Sie zu halbieren kostet mehr — häufigere Backups, wiederholte Wiederherstellungen — und dieser Kompromiss wird vor dem Vorfall entschieden, nicht währenddessen.
Was bleibt
Ein zuverlässiges Backup lässt sich auf vier Anforderungen bringen: automatisiert, damit es von niemandem abhängt; vom Server getrennt, damit es seinen Verlust übersteht; verschlüsselt, bevor es hinausgeht; und regelmäßig wiederhergestellt, um zu beweisen, dass es etwas wert ist. Die 3-2-1-Regel, ein cron-Skript und ein monatlicher Test decken die meisten Fälle einer selbst gehosteten Site ab.
Der einzige echte Backup-Schreck, den ich erlebt habe, kam nicht von einer toten Platte, sondern von einem beschädigten Dump, den nie jemand wieder geöffnet hatte: Die Datei existierte, sie war leer. Seither gilt mir ein ungetestetes Backup als nicht vorhanden, und in Kundeninstallationen setze ich die monatliche Wiederherstellungs-Erinnerung noch vor die Automatisierung selbst. Für eine Content-Site ist restic auf Objektspeicher für ein paar Euro im Monat die beste Ruhe-pro-Euro, die ich kenne. — Simon Janvier
Zum Weiterlesen
Offizielle restic-Dokumentation, Repositories und Aufbewahrungsrichtlinien: restic.readthedocs.io.
