Backup-Strategien: Webhosting-Daten richtig sichern 2026

Warum Backups scheitern (und wie du es vermeidest)

Die meisten Websites haben ein Backup — aber es ist nutzlos. Warum? Die häufigsten Fehler:

Backup auf demselben Server — Wenn der Server abraucht, ist das Backup weg. Ein lokales Backup auf derselben Maschine ist kein Backup.
Nie getestet — Du hast das Backup nie zurückgespielt. Wenn du es brauchst, funktioniert es vielleicht nicht. Zeige mir eine Website ohne getestetes Backup — ich zeige dir eine Website in Gefahr.
Zu selten — Tägliches Backup klingt gut, aber wenn deine Datenbank 5 GB groß ist und das Backup nur nachts läuft, gehen bei einem Ausfall um 14:00 Uhr 18 Stunden Daten verloren.
Keine Differenzierung — MySQL-Datenbank und Dateien müssen getrennt gesichert werden. Ein vollständiges Webbackup ohne Datenbank ist unvollständig.

Statistik

60% der Unternehmen, die ihre Daten verlieren, geben innerhalb von 6 Monaten auf. Für private Website-Betreiber ist das Risiko nicht geringer — nur weniger sichtbar. Ein einziges funktionierendes Backup ist mehr wert als drei versprochene.

Die 3-2-1 Backup-Regel

Das INDUSTRIESTANDARD für Backup-Strategien: 3 Kopien deiner Daten, auf 2 verschiedenen Medien, davon 1 Off-Site.

3 Kopien — Original-Daten + 2 Sicherungskopien. Das schützt gegen versehentliches Löschen und Hardware-Ausfälle.
2 verschiedene Medien — Zum Beispiel: SSD auf dem Server + NAS zu Hause. Oder: Lokales Backup + Cloud-Bucket. Niemand sollte alle Backups auf derselben Technologie lagern.
1 Off-Site — Eine Kopie muss geographically getrennt sein. Wenn dein Rechenzentrum abbrennt, hilft das lokale Backup nicht. Cloud-Speicher (R2, S3, Backblaze B2) ist die einfachste Lösung.

RTO und RPO: Wie schnell musst du恢复?

Bevor du eine Backup-Strategie baust, definiere deine Ziele. Zwei Metriken sind entscheidend:

RPO (Recovery Point Objective) — Wie viel Datenverlust ist akzeptabel? Wenn du alle 24 Stunden backupst, ist dein maximales Datenverlust 24 Stunden. RPO = Backup-Intervall.
RTO (Recovery Time Objective) — Wie lange darf die Website offline sein? Wenn 1 Stunde Ausfall 1.000 € kostet, ist eine 4-Stunden-Wiederherstellung keine Option.

Website-Typ	Empfohlenes RPO	Empfohlenes RTO	Backup-Frequenz
Statische Website / Portfolio	24 Stunden	4 Stunden	Täglich
WordPress Blog	6–12 Stunden	2 Stunden	Alle 6 Stunden
E-Commerce / Online-Shop	1–4 Stunden	30 Minuten	Stündlich (MySQL) + täglich (Dateien)
SaaS / Online-Dienst	15 Minuten	15 Minuten	Continuous (Binlog-Replication)
Critical Business Application	5 Minuten	5 Minuten	Real-time replication

MySQL-Datenbank sichern: Vollbackup & inkrementell

Für die meisten Webhosting-Setups (WordPress, Moodle, ownCloud etc.) brauchst du eine zuverlässige MySQL-Datensicherung. Hier die richtigen Ansätze:

Vollbackup mit mysqldump

# Vollständiges MySQL-Backup erstellen (komprimiert)
mysqldump --single-transaction --quick --lock-tables=false \n  -u DEIN_USER -pDEIN_PASSWORT DEINE_DATENBANK | gzip > /backup/mysql/$(date +%Y%m%d)_full.sql.gz

# Wiederherstellung aus Backup
gunzip < /backup/mysql/20260604_full.sql.gz | mysql -u DEIN_USER -pDEIN_PASSWORT DEINE_DATENBANK

# Tipp: --single-transaction für InnoDB ohne Tabellen-Sperre
          

Für große Datenbanken (>1 GB) nutze --single-transaction (InnoDB) statt --lock-tables (MyISAM), um die Datenbank während des Backups lesbar zu halten.

Inkrementelles MySQL-Backup mit Binlog

# MySQL Binlog aktivieren (in my.cnf)
log-bin = /var/log/mysql/mysql-bin
expire_logs_days = 7
max_binlog_size = 100M

# Tägliche Binlog-Sicherung (nach dem Vollbackup)
mysql -u root -p -e "FLUSH LOGS;"
cp /var/log/mysql/mysql-bin.* /backup/mysql/binlog/

# Punkt-in-Zeit-Wiederherstellung möglich: mysqlbinlog mysql-bin.000123 | mysql
          

Backup-Größe einschätzen

MySQL-Dumps sind komprimiert typisch 30–70% kleiner als die Roh-Daten. Ein 2 GB-Datenbank wird komprimiert ~800 MB. Wenn du mehr als 5 GB Daten hast, lohnt sich ein dediziertes Backup-Tool wie Percona XtraBackup (für MySQL 8.x mit InnoDB), das Hot-Backups ohne Locking erstellt.

Dateien sichern: rsync, Restic, BorgBackup

Für Datei-Backups (uploads, Code, Konfigurationen) gibt es drei bewährte Tools:

rsync — der Klassiker

# Inkrementelles Datei-Backup auf lokales NAS
rsync -avz --delete /var/www/ /mnt/nas/www-backup/

# SSH-basiertes Remote-Backup
rsync -avz -e ssh /var/www/ user@remote-server:/backup/www/

# Dry-Run (Test ohne Ausführung)
rsync -avz --delete --dry-run /var/www/ /mnt/nas/www-backup/
          

Restic — deduplizierendes Backup für die Cloud

# Restic initialisieren (Backend: R2, S3, oder lokal)
export RESTIC_PASSWORD="DeinSicheresPasswort"
export RESTIC_REPOSITORY="s3:https://r2.cloudflare.com/dein-bucket/"
restic init

# Backup ausführen (Restic erkennt automatisch Änderungen)
restic backup /var/www --exclude '*.log' --exclude 'node_modules'

# Backup-Liste anzeigen
restic snapshots

# Wiederherstellen
restic restore latest --target /restore/
          

Restic ist ideal für Off-Site-Backups: es dedupliziert (nur geänderte Dateien werden neu gespeichert), verschlüsselt client-seitig, und unterstützt R2/S3/Backblaze B2/SSH/SFTP als Backend.

BorgBackup — effiziente Backups mit Deduplizierung

# Borg-Repository initialisieren
borg init --encryption=repokey user@backup-server:/backup/borg/repo

# Backup erstellen (mit Kompression und Deduplizierung)
borg create user@backup-server:/backup/borg/repo::webserver-{now} /var/www

# Alte Backups aufräumen (nur die letzten 7 täglichen behalten)
borg prune --keep-daily=7 --keep-weekly=4 user@backup-server:/backup/borg/repo
          

Off-Site-Backup: R2, S3, Backblaze B2

Ein Off-Site-Backup ist die einzige Absicherung gegen Rechenzentrums-Katastrophen. Hier die relevantesten Optionen für deutschsprachige Projekte:

Service	Speicher	Preis/GByte	Egress	Ideal für
Cloudflare R2	Unbegrenzt	0,015 $/GB/Monat	Kostenlos	VPS, WordPress, kleine bis mittlere Sites
AWS S3	Unbegrenzt	0,021 $/GB/Monat	0,09 $/GB	Enterprise, große Datenmengen, komplexe Setups
Backblaze B2	Unbegrenzt	0,006 $/GB/Monat	0,01 $/GB	Budget-Bewusst, große Datenmengen
Wasabi	Unbegrenzt	0,007 $/GB/Monat	0,01 $/GB (EU: 0,02 $)	EU-Rechenzentrum (Amsterdam/Frankfurt)

Warum R2 für die meisten?

Cloudflare R2 hat kostenlose Egress — du zahlst nur für Speicher, nicht für den Download. Das macht es zur besten Wahl für regelmäßige Backup-Wiederherstellungen. Backblaze B2 ist günstiger bei Raw-Speicher, aber die Egress-Kosten summieren sich bei häufigen Restores.

Backup automatisieren mit Cron

Backups, die manuell ausgeführt werden, werden nicht ausgeführt. Automatisiere alles mit Cron:

# Cron-Jobs für tägliches Backup (crontab -e)

# Tägliches MySQL-Vollbackup um 03:00 Uhr
0 3 * * * /opt/scripts/mysql-backup.sh >> /var/log/backup.log 2>&1

# Wöchentliches vollständiges Server-Backup (Sonntag 02:00)
0 2 * * 0 /opt/scripts/full-backup.sh >> /var/log/backup.log 2>&1

# Stündliches inkrementelles Backup (jede Stunde)
0 * * * * /opt/scripts/incremental-backup.sh >> /var/log/backup.log 2>&1
          

Das Backup-Script sollte: das Backup ausführen, die Dateigröße loggen, eine Retention-Policy durchführen (alte Backups löschen), und bei Fehlern eine E-Mail-Benachrichtigung senden.

Beispiel: Vollständiges Backup-Script

#!/bin/bash
# /opt/scripts/mysql-backup.sh
set -euo pipefail

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backup/mysql"
RETENTION_DAYS=30
R2_ACCOUNT_ID="xxx"
R2_ACCESS_KEY="xxx"
R2_SECRET_KEY="xxx"
R2_BUCKET="mein-backup-bucket"

mkdir -p "$BACKUP_DIR"

# MySQL-Dump erstellen (komprimiert)
mysqldump --single-transaction --quick -u root -p"$MYSQL_ROOT_PASSWORD" all | gzip > "$BACKUP_DIR/${DATE}_mysql.sql.gz"

# Dateien mit Restic sichern
export RESTIC_PASSWORD="$RESTIC_PASSWORD"
export RESTIC_REPOSITORY="s3:https://r2.cloudflare.com/$R2_BUCKET/"
restic backup /var/www --tag mysql-backup

# Alte lokale Backups löschen (Retention)
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Erfolg loggen
echo "[$(date)] Backup erfolgreich: $BACKUP_DIR/${DATE}_mysql.sql.gz" >> /var/log/backup.log
          

Backup testen — der Schritt, den alle überspringen

Ein Backup ohne Test ist wertlos. Plane in deinem Backup-Setup fester Test-Rhythmus:

Monatlich — Backup auf eine Test-Maschine / Staging-Umgebung restored und prüfen: Sind alle Daten da? Sind die Dateien vollständig? Funktionieren die restore-Scripte?
Nach jedem Major-Update — Nach jedem WordPress-Core-Update, Server-Update, oder Datenbank-Migration: sofort ein Backup testen.
Prüfen der Monitoring-Alerts — Backup-Scripts, die keine Fehler melden, aber keine Dateien erzeugen, sind schlimmer als kein Backup (weil sie trügerische Sicherheit geben).

Test-Restore checklist

Bei jedem Test-Restore prüfe: (1) Datenbank vollständig importiert — alle Tabellen da, keine Fehler. (2) WordPress-Medien (uploads/) vollständig restored. (3) wp-config.php und andere Konfigurationsdateien an Ort und Stelle. (4) URL Rewrite/htaccess funktioniert nach Restore. (5) SSL-Zertifikate intakt.

Quick-Checkliste für dein Backup-Setup

Tägliches MySQL-Backup (Vollbackup oder inkrementell mit Binlog)
Tägliches Datei-Backup (/var/www oder htdocs/)
Mindestens eine Kopie Off-Site (R2, S3, oder anderes Rechenzentrum)
Lokales Backup auf NAS oder zweitem Server (nicht dasselbe Laufwerk)
Backup-Scripts automatisiert per Cron
Retention-Policy definiert (alte Backups automatisch löschen)
Monitored: Fehler beim Backup müssen Alarm auslösen
Test-Restore mindestens monatlich
Dokumentation: Wie restore ich? Wo sind die Backups?

Weiterführende Artikel

Fazit: Backup-Strategie 2026

Eine gute Backup-Strategie ist nicht kompliziert — sie ist nur konsequent. Tägliches MySQL-Dump + Restic auf R2, wöchentlich ein vollständiges Server-Backup, monatlich ein Test-Restore. Das ist der Mindeststandard, der für die meisten Websites funktioniert.

Das teuerste Backup-System bringt nichts, wenn du es nie testest. Das billigste System, das zuverlässig restored, ist Gold wert.

Hosting mit besserem Backup?

Vergleiche Anbieter mit automatischen täglichen Backups, Off-Site-Speicherung und Ein-Klick-Wiederherstellung.

Zum Hosting-Vergleich → Domain sichern

Backup-Strategien: Webhosting-Daten richtig sichern