Website-Backup beim Hosting: 3-2-1-Regel, Tools und Restore-Test

Ein vollständiges Website-Backup besteht aus einem Datenbank-Dump und einem Archiv der Dateien inklusive Upload-Ordner: konsistent erstellt, an mindestens zwei Orten gespeichert, davon einer außerhalb des Webservers, und durch eine Test-Wiederherstellung geprüft. Auf unserem Testserver lieferten die meisten klassischen Fehler ein Backup, das ohne eine einzige Warnung entstand; das Problem zeigte sich erst beim Wiederherstellen. Im Folgenden: die 3-2-1-Regel verständlich erklärt, eine Tabelle „was, womit, wie oft sichern und wie prüfen“, Messwerte zu mysqldump, Kompression und restic sowie ein Restore-Test Schritt für Schritt.

Die 3-2-1-Regel für eine Website auf Shared Hosting

Die 3-2-1-Regel bedeutet: drei Kopien Ihrer Daten auf zwei verschiedenen Medien oder Systemen, eine davon an einem anderen Ort. Für eine Website auf Shared Hosting sieht das so aus. Kopie eins: die laufende Website selbst. Kopie zwei: das Backup, das Ihr Hoster erstellt und außerhalb des Webservers aufbewahrt. Kopie drei: Ihr eigenes Backup bei einem anderen Anbieter, in einem Cloud-Speicher oder auf Ihrem Computer. Entscheidend ist nicht die Zahl der Kopien, sondern ihre Unabhängigkeit: Liegen alle drei auf einer Festplatte oder sind sie über ein einziges Konto erreichbar, haben Sie eine Kopie, nur dreifach.

Zwei weitere Bedingungen machen die Regel wirksam. Bewahren Sie Backups mehrerer Tage oder Wochen auf, nicht nur das letzte, denn einen Hack oder beschädigte Daten bemerkt man oft spät. Und prüfen Sie jede Einrichtung mit mindestens einer Wiederherstellung, sonst wissen Sie nicht, ob Sie überhaupt ein Backup haben.

Was, womit, wie oft sichern und wie prüfen

Log-, Statistik- und Plugin-Cache-Tabellen wiegen oft mehr als der gesamte Inhalt. Auf dem Testserver machte die Log-Tabelle etwa 350 MB des 404 MB großen Dumps aus. Wer sie bereinigt, bekommt kleinere und schnellere Backups; mehr dazu in unserem Ratgeber Datenbank auf dem Hosting optimieren.

Datenbank: warum --single-transaction wichtig ist

Ein Skript legte laufend „Bestellungen“ an: eine Zeile in wp_posts und vier Zeilen in wp_postmeta in einer Transaktion, etwa 45 Bestellungen pro Sekunde. Zwei Sekunden später startete ein Dump in einem von drei Modi.

Ohne Sperren liest der Dump die Tabellen nacheinander: wp_postmeta vor wp_posts. Bestellungen, die zwischen diesen beiden Lesevorgängen gespeichert wurden, landeten ohne Summe, E-Mail-Adresse und Zahlungsart im Backup. Ein solcher Dump lässt sich fehlerfrei importieren, und Sie merken es erst, wenn ein Kunde nach seiner Bestellung fragt. Der Standardmodus hält das Backup konsistent, blockiert aber Schreibvorgänge während des gesamten Dumps: Bei einer größeren Datenbank bedeutet das Minuten, in denen der Shop keine Bestellungen annehmen kann. --single-transaction erstellt einen konsistenten InnoDB-Snapshot ohne Sperren. Bei MyISAM-Tabellen hilft es nicht, stellen Sie alte Tabellen also auf InnoDB um.

mariadb-dump --single-transaction --quick --default-character-set=utf8mb4 wp > db.sql
tail -1 db.sql
-- Dump completed on 2026-11-10 14:51:46

Ohne Last brauchten beide Modi gleich lang: 3,2-3,9 Sekunden für 404 MB. Der Unterschied zeigt sich nur, solange in die Datenbank geschrieben wird, und das heißt bei einem Shop: während der Geschäftszeiten.

Dateien: welcher Kompressor sich lohnt

Jeder Kompressor lief mit einem Thread auf denselben Daten.

JPEG-Fotos sind bereits komprimiert, daher schrumpft das Dateiarchiv kaum, egal womit. Der Dump schrumpft auf ein Fünftel. zstd -3 bot den besten Kompromiss: 5- bis 11-mal schneller als gzip bei etwas kleinerer Datei. Die Höchststufen von zstd und xz sparten beim Dump rund 15 MB mehr, kosteten dafür aber fünf Minuten CPU-Zeit, auf Shared Hosting eine verschwendete Last.

Inkrementelle Backups: was die Deduplizierung von restic bringt

restic und borg zerlegen Daten in Blöcke und speichern nur neue. Das erste Backup der Website samt Dump umfasste 791 MB (427 MB im Repository, weil restic komprimiert). Danach:

• Ein neuer Beitrag, ein Foto mit 454 KB und 20 Bestellungen: Das zweite Backup fügte 4,6 MB hinzu.
• Die 1.000 ältesten Zeilen der Log-Tabelle gelöscht, wie es Bereinigungs-Plugins tun: Das dritte Backup fügte 359,6 MB hinzu, fast den ganzen Dump.
• Dieselbe Änderung, aber ein Dump mit einer Zeile pro INSERT (--skip-extended-insert): 7,6 MB hinzugefügt.

Ein normaler Dump packt Hunderte Zeilen in jede INSERT-Anweisung. Werden Zeilen am Anfang einer Tabelle gelöscht, verschieben sich die Grenzen aller folgenden Anweisungen, und restic hält den Rest der Datei für neu. Ein Dump mit einer Zeile pro INSERT lässt sich gut deduplizieren, hat aber seinen Preis: Der Import dauerte auf dem Testserver 507 statt 35 Sekunden. Wenn Sie Speicher nach Volumen bezahlen und selten wiederherstellen, lohnt sich das; zählt die Geschwindigkeit der Wiederherstellung, bleiben Sie beim normalen Dump und halten weniger Versionen vor. borg haben wir nicht gemessen: Es startete im Testcontainer wegen einer inkompatiblen Python-Version nicht, die Zahlen gelten also nur für restic.

export RESTIC_REPOSITORY=sftp:backup@storage.example.net:/restic
export RESTIC_PASSWORD_FILE=~/.restic-pass
restic init
restic backup ~/backup/db.sql ~/web/example.com/public_html
restic forget --keep-daily 14 --keep-weekly 8 --prune
restic check

Ersetzen Sie die Repository-Adresse durch Ihre eigene. Bewahren Sie das Repository-Passwort nicht auf dem Server auf: Ohne es kann niemand das Backup entschlüsseln, auch Sie nicht.

Test-Wiederherstellung: so prüfen Sie, ob ein Backup funktioniert

Wir haben den schlimmsten Fall nachgestellt: die Datenbank gestoppt, das gesamte „Server“-Verzeichnis samt lokaler Backups gelöscht und die Website aus restic in eine neue MariaDB-Instanz mit leerem Website-Ordner wiederhergestellt.

restic restore latest --target /srv/restore
Summary: Restored 3523 files/dirs (789.971 MiB) in 0:02
mariadb -e "CREATE DATABASE wp"
mariadb wp < db.sql
curl -s -o /dev/null -w "%{http_code}\n" http://bench.test:8122/
200
curl -sI "http://bench.test:8122/wp-json/wp/v2/posts?per_page=1" | grep -i x-wp-total
X-WP-Total: 6002

Vom Start bis zur Antwort 200 vergingen 23 Sekunden: 4 für die Dateien, 19 für den Datenbankimport. Die Anzahl der Beiträge und Bestellungen sowie die höchste ID stimmten mit der Live-Website überein, das neue Foto kam mit derselben Prüfsumme zurück, und nicht lateinische Titel waren intakt. Unser erster Versuch scheiterte übrigens an unserem eigenen Fehler: restic speicherte die Pfade genau so, wie wir sie übergeben hatten, und die Dateien landeten in einem anderen Ordner, als das Skript erwartete. Genau solche Details deckt eine Test-Wiederherstellung auf.

Eine minimale monatliche Prüfung:

1. Integrität des Archivs prüfen: zstd -t, gzip -t oder restic check.
2. Sicherstellen, dass der Dump mit „Dump completed“ endet.
3. Den Dump in eine separate Testdatenbank importieren und die Anzahl von Beiträgen, Bestellungen und Benutzern mit der Live-Website vergleichen.
4. Die Dateien auf einer Test-Subdomain bereitstellen, Antwort 200, Admin-Login und einige alte Bilder prüfen.
5. Notieren, wie lange es gedauert hat: Das ist Ihre tatsächliche Wiederherstellungszeit.

Im Grunde ist es dasselbe Vorgehen wie beim Umzug von WordPress zu einem anderen Hoster, nur ohne die Domain umzustellen.

Vier Fehler, die wir auf dem Testserver nachgestellt haben

Backup ohne Upload-Ordner

Ein Archiv mit --exclude=wp-content/uploads war 15 MB statt 361 MB groß. Nach der Wiederherstellung lieferte die Startseite 200 und die REST-API listete alle 6.002 Beiträge, aber jedes Foto ergab 404: 450 Anhänge in der Datenbank, 0 Dateien auf der Festplatte. Die Website wirkt lebendig, bis man einen beliebigen Beitrag öffnet. Uploads werden oft ausgeschlossen, um ein Größenlimit einzuhalten; prüfen Sie daher die Dateianzahl in Ihrem Backup.

Backups nur auf demselben Server

Als das „Server“-Verzeichnis verschwand, verschwanden mit der Website auch der Dump, das Dateiarchiv und die Prüfsummen daneben: No such file or directory. Nur die Kopie im separaten Speicher rettete die Website. Lagern Sie Archive außerdem nie im Web-Root der Website, wo jeder sie per URL herunterladen kann. Rechte 700 für den Ordner und 600 für Dateien genügen für ein Backup-Verzeichnis.

Abgeschnittene Datei

Ein bei 60 % abgebrochenes Backup (volle Festplatte oder unterbrochene Übertragung) fällt bei zstd -t mit „Read error (39) : premature end“ durch; gzip meldet „unexpected end of file“. Schlimmer ist ein unkomprimierter Dump: Der Import stoppte mit ERROR 1064, hatte bis dahin aber 7 von 13 Tabellen und 3.825 von 9.304 Zeilen in wp_posts angelegt. Die Tabellen für Benutzer und Kategorien fehlten, also konnte sich niemand anmelden. Einen abgeschnittenen Dump erkennt man leicht: Am Ende fehlt die Zeile „Dump completed“.

Falscher Zeichensatz oder falsche Kollation

Ein Dump mit --default-character-set=latin1 lief fehlerfrei durch, doch in 5.986 von 6.001 Titeln wurde der kyrillische Text zu Fragezeichen. Dieser Verlust ist endgültig: Die richtigen Bytes stehen schlicht nicht in der Datei. Eine weitere Variante: ein Dump ohne SET-NAMES-Zeile, importiert von einem Client, der in latin1 läuft (wie der mariadb-Client auf dem Testserver in einer Sitzung ohne UTF-8-Locale). Die Titel erschienen als Zeichensalat wie „ДоÑтавка“, während dieselbe Datei mit --default-character-set=utf8mb4 korrekt importiert wurde. Den dritten Fall haben wir emuliert, indem wir im Dump die Kollation eingesetzt haben, die MySQL 8 standardmäßig anlegt: MariaDB 10.11 antwortete mit ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' und legte keine Tabellen an. Die Lösung: die Kollation durch eine unterstützte ersetzen, zum Beispiel utf8mb4_unicode_520_ci, und erneut importieren.

Wenn das Ihre Situation ist, tun Sie Folgendes

Ist die Website bereits ausgefallen, suchen Sie zuerst die Ursache in den Server-Logs: Oft ist es ein Plugin oder eine volle Festplatte, und ein Rollback auf das gestrige Backup würde nur neue Bestellungen löschen. Lassen Sie Ihr Backup-Skript per Cronjob auf dem Hosting zeitgesteuert laufen, ergänzen Sie eine Prüfung auf „Dump completed“ und zstd -t und lassen Sie sich vom Server-Monitoring alarmieren, wenn etwas fehlschlägt.

Backups bei RichHost

Alle Hosting-Tarife von RichHost enthalten kontinuierliche Cloud-Backups: eine Kopie außerhalb des Webservers. Nach der 3-2-1-Regel ergänzen Sie ein eigenes Backup an einem anderen Ort und testen es ab und zu durch eine Wiederherstellung auf einer Test-Subdomain. Der Support beantwortet Fragen zu Backups von 10:00 bis 20:00 Uhr Kyiver Zeit, in der Regel innerhalb von etwa 30 Minuten.

Häufige Fragen

Reichen die Backups meines Hosters aus?

Für die meisten Vorfälle ja, doch die 3-2-1-Regel verlangt eine weitere unabhängige Kopie. Sie rettet Sie, wenn das Problem Ihr Konto oder die Abrechnung betrifft oder wenn Sie eine ältere Version brauchen, als der Hoster aufbewahrt.

Wie oft sollte ich meine Website sichern?

So oft, wie es der Datenmenge entspricht, die Sie verlieren können. Für einen Blog genügen tägliche oder wöchentliche Backups, ein Shop braucht mehrere Datenbank-Dumps am Tag. Dateien ändern sich seltener als die Datenbank und können seltener gesichert werden.

Kann ich die Datenbank sichern, während die Website läuft?

Ja, mit --single-transaction für InnoDB-Tabellen. Auf dem Testserver verlor ein solcher Dump keine Bestellungen und blockierte keine Schreibvorgänge, während ein Dump ohne Sperren pro Durchlauf die Daten von 3-7 Bestellungen verlor.

Wie teste ich ein Backup, ohne die Live-Website zu gefährden?

Stellen Sie es in eine separate Datenbank und auf einer Test-Subdomain wieder her, niemals über die Live-Website. Vergleichen Sie die Anzahl von Beiträgen und Bestellungen, öffnen Sie einige Seiten und Bilder und melden Sie sich im Admin-Bereich an.