Datenbank Backup und Wiederherstellung mit mysqldump und pg_dump

Was ist ein Datenbank Backup und wie erstellt mysqldump es?

Ein Datenbank Backup ist eine Kopie Ihrer Tabellen und ihrer Daten, die außerhalb der laufenden Datenbank liegt. Für MySQL und MariaDB schreibt mysqldump diese Kopie als Textdatei mit SQL Befehlen. PostgreSQL bietet dafür zudem pg_dump. Führen Sie die Datei später aus, bauen Sie die Datenbank neu auf.

Dieser Leitfaden richtet sich an Website Betreiber und Entwickler, die ihren eigenen VPS oder ihr cPanel Konto verwalten. Daher können Sie die Befehle Schritt für Schritt nachvollziehen. Den Schutz der gesamten Website behandeln wir allerdings getrennt. Für Dateisicherung, Aufbewahrung und die Idee hinter 3-2-1 lesen Sie unsere Website Backup Strategie. Hier geht es also nur um die Datenbank.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hosting Anbieter. Deshalb stützen sich die Erklärungen auf die offizielle Dokumentation. Wir haben jede Option in den Handbüchern von MySQL und PostgreSQL geprüft. Versionsnummern nennen wir nicht, weil sich Optionen ändern. Öffnen Sie daher vor jedem Befehl das Handbuch Ihrer eigenen Version.

Was ist der Unterschied zwischen logischem und physischem Backup?

Ein logisches Backup schreibt Ihre Daten als SQL Anweisungen. Ein physisches Backup kopiert dagegen die Dateien der Datenbank Engine auf der Festplatte. mysqldump und pg_dump erzeugen logische Backups. Diese sind in der Praxis lesbar, übertragbar und für kleine und mittlere Websites meist ausreichend.

Physische Backups stellen sehr große Datenbanken oft schneller wieder her. Andererseits binden sie Sie an dieselbe Engine und eine kompatible Version. Für die meisten Websites ist ein logisches Backup deshalb der sinnvolle erste Schritt. Die Tabelle fasst den Unterschied zusammen.

Was sollten Sie vor dem Datenbank Backup prüfen?

Zunächst legen Sie genau fest, was Sie sichern. Datenbank, Engine und Benutzer bestimmen den Befehl. Außerdem müssen Sie wissen, wohin die Datei geht und ob genug Speicherplatz frei ist.

• Finden Sie zuerst die Engine heraus: MySQL, MariaDB oder PostgreSQL.
• Prüfen Sie die Tabellen Engines: InnoDB oder MyISAM.
• Legen Sie einen eigenen Backup Benutzer mit den nötigen Rechten an.
• Achten Sie auf freien Platz im Backup Ordner, denn eine volle Platte stoppt den Auftrag.
• Bereiten Sie eine Testumgebung für die Wiederherstellung vor.

Der Backup Benutzer braucht ein starkes Passwort. Dafür können Sie unseren Passwort Generator nutzen und das Ergebnis in einem Passwortmanager speichern. Schreiben Sie es daher nie direkt in Befehle.

Bei MariaDB gibt es den Client auch als mariadb-dump. Laut MariaDB Dokumentation bleibt der alte Name mysqldump als symbolischer Link erhalten, gilt aber ab Version 11.0 als veraltet. Prüfen Sie also, welchen Namen Ihr Server hat, denn beide Namen sind im Umlauf.

Wie sichern Sie eine einzelne Datenbank mit mysqldump?

Die einfachste Form nennt den Datenbanknamen und leitet die Ausgabe in eine Datei um. Das Beispiel sichert eine Datenbank namens beispiel_db. Für das Passwort nutzt es eine Optionsdatei, die wir gleich erklären.

mysqldump --defaults-extra-file=/home/benutzer/.backup.cnf \
  --single-transaction --routines --triggers --events \
  beispiel_db > beispiel_db.sql

Beachten Sie, dass wir die Option --databases absichtlich weggelassen haben. Laut MySQL Handbuch fügt sie der Ausgabe CREATE DATABASE Anweisungen hinzu. Laden Sie eine solche Datei zum Test, können Sie eine gleichnamige Live Datenbank überschreiben. Nennen Sie den Namen im Befehl, wählen Sie das Ziel erst bei der Wiederherstellung.

Zwar landen mit --all-databases alle Datenbanken in einer Datei. Einzelne Dateien erleichtern allerdings die Wiederherstellung einer einzelnen Website. Deshalb empfehlen wir einen eigenen Befehl pro Datenbank.

Was bewirkt --single-transaction und wann reicht es nicht?

Laut MySQL Handbuch sendet --single-transaction vor dem Auslesen ein BEGIN. Bei InnoDB Tabellen erhalten Sie so einen konsistenten Stand, ohne die Website zu sperren. Das heißt, Bestellungen oder Kommentare dürfen während der Sicherung weiterlaufen, und die Datei zeigt trotzdem genau einen Zeitpunkt.

Die Option hat allerdings Grenzen, und das Handbuch nennt zwei. Erstens können Anweisungen, die während des Dumps die Tabellenstruktur ändern, die Konsistenz stören. Führen Sie zum Beispiel in dieser Zeit kein ALTER TABLE und kein TRUNCATE TABLE aus. Zweitens liefert die Option bei Tabellen ohne Transaktionen, etwa MyISAM, keine Konsistenz.

Für gemischte Engines verweist das Handbuch auf --lock-tables. Dann warten Schreibzugriffe während der Sicherung. Meiden Sie deshalb Stoßzeiten und besprechen Sie mit einer Fachperson, ob sich Tabellen auf InnoDB umstellen lassen.

Landen Stored Procedures, Trigger und Events im Backup?

Am sichersten fordern Sie alle ausdrücklich an. Laut MySQL Handbuch brauchen Stored Procedures die Option --routines und Events die Option --events. Beide landen standardmäßig nicht im Dump. Für Trigger gibt es --triggers. Wir schreiben in allen Beispielen alle drei, denn wer sich auf Standardwerte verlässt, erlebt am Tag der Wiederherstellung Überraschungen.

Nutzen Sie diese Objekte nicht, schadet die Angabe dennoch nicht. Nutzen Sie sie, kann eine fehlende Prozedur einen Teil der Website lahmlegen. Fertige Systeme wie WordPress haben davon meist wenige, individuelle Software dagegen oft viele.

Bei individueller Software sollten Sie Datenbankobjekte zusätzlich im Code Repository halten. So bauen Sie die Struktur auch dann neu auf, wenn ein Backup versagt. Wenn Sie dabei Unterstützung wünschen, schauen Sie sich unsere individuelle Softwareentwicklung an.

Welche Rechte braucht der Backup Benutzer?

Das MySQL Handbuch listet die nötigen Rechte auf. Sie brauchen SELECT für die Tabellen, SHOW VIEW für Views und TRIGGER für Trigger. Ohne --single-transaction kommt LOCK TABLES hinzu. Somit können Sie mit einem schmalen Konto arbeiten statt mit dem Administrator Konto.

Zwei Details sind wichtig. Das Handbuch verlangt das Recht PROCESS, sofern Sie --no-tablespaces nicht verwenden. Auf Servern mit GTID kann --single-transaction außerdem RELOAD oder FLUSH_TABLES verlangen. Für Routinen und Events können weitere Rechte nötig sein, lesen Sie deshalb das Handbuch Ihrer Version.

GRANT SELECT, SHOW VIEW, TRIGGER ON beispiel_db.* TO 'backup_benutzer'@'localhost';

Diese Anweisung führen Sie daher mit einem berechtigten Konto aus, zum Beispiel dem Administrator. Benutzer und Datenbankname sind frei erfunden. Das Administrator Passwort gehört nicht in das Backup Skript, denn so bleibt ein Leck klein. Außerdem sollten Sie das Recht auf die nötige Datenbank begrenzen.

Geht ein Backup ohne Passwort in der Befehlszeile?

Ja, und Sie sollten es so machen. Das MySQL Handbuch nennt ein Passwort in der Befehlszeile unsicher und empfiehlt eine Optionsdatei. Ein Passwort im Befehl kann nämlich in der Prozessliste und im Verlauf der Shell auftauchen.

Legen Sie zunächst eine Optionsdatei an, denn sie enthält die Zugangsdaten. Das Format ist einfach: Sie schreiben einen Gruppennamen in eckigen Klammern und darunter die Zeilen user und password. Die Werte unten sind reine Beispiele.

[client]
user=backup_benutzer
password=PASSWORT_HIER_EINTRAGEN

Danach machen Sie die Datei nur für sich lesbar. Das Handbuch ist hier eindeutig: Nur der Besitzer soll Zugriff haben. Der Befehl lautet:

chmod 600 /home/benutzer/.backup.cnf

Schließlich übergeben Sie die Datei mit --defaults-extra-file. Laut Handbuch muss das die erste Option im Befehl sein. Deshalb steht sie in unseren Beispielen immer ganz vorn.

Wie erstellen Sie ein PostgreSQL Backup mit pg_dump?

Laut PostgreSQL Handbuch exportiert pg_dump konsistent, auch wenn die Datenbank gerade genutzt wird, und blockiert weder Lese noch Schreibzugriffe. Eine eigene Sperroption brauchen Sie somit nicht. Das gängigste Format ist das Custom Archiv.

pg_dump --format=custom --file=beispiel_db.dump \
  --host=localhost --username=backup_benutzer beispiel_db

Für das Passwort können Sie die Umgebungsvariable PGPASSWORD oder eine .pgpass Datei nutzen. Das Handbuch unterstützt beide Wege. Wir bevorzugen die Datei, weil auch eine Umgebungsvariable über Prozessinformationen sichtbar sein kann. Jede Zeile hat die Form Host:Port:Datenbank:Benutzer:Passwort. Beschränken Sie auch hier die Dateirechte auf den Besitzer.

Einen Punkt dürfen Sie nicht übersehen: pg_dump sichert keine Rollen und Benutzer. Laut Handbuch nutzen Sie dafür pg_dumpall mit der Option --globals-only. Falls Sie den Server einmal neu aufbauen müssen, bewahren Sie auch diese Datei auf.

Welches pg_dump Format sollten Sie wählen?

Ihre Wahl bestimmt, wie Sie wiederherstellen. Klartext laden Sie mit psql, die anderen Formate mit pg_restore. Außerdem unterstützt nur das Verzeichnisformat parallele Sicherungen. Die Tabelle fasst die Angaben aus dem PostgreSQL Handbuch zusammen.

Für die meisten Websites genügt dann das Custom Archiv. Bei einer sehr großen Datenbank kann das Verzeichnisformat mit --jobs die Zeit verkürzen. Allerdings öffnet paralleles Arbeiten zusätzliche Verbindungen, laut Handbuch eine mehr als Jobs. Fragen Sie auf Shared Hosting zuerst Ihren Anbieter.

Wie komprimieren Sie die Datei eines Datenbank Backups?

mysqldump schreibt Text, und Text lässt sich gut komprimieren. Leiten Sie die Ausgabe deshalb an gzip weiter, sparen Sie Speicherplatz. Außerdem übertragen Sie weniger Daten, wenn Sie die Datei vom Server kopieren.

mysqldump --defaults-extra-file=/home/benutzer/.backup.cnf \
  --single-transaction --routines --triggers --events beispiel_db \
  | gzip > beispiel_db.sql.gz

Bei Pipes lauert allerdings eine kleine Falle. Schlägt mysqldump fehl, beendet gzip trotzdem erfolgreich, und es entsteht eine gültige, aber fast leere Datei. Schalten Sie deshalb in Bash Skripten die Option pipefail ein. Dann bricht das Skript mit einem Fehlercode ab, sobald ein Befehl der Pipe scheitert.

Bei PostgreSQL komprimieren das Custom und das Verzeichnisformat bereits. Laut Handbuch wählen Sie mit -Z gzip, lz4 oder zstd als Methode. Bei Klartext leiten Sie wie bei MySQL an gzip weiter.

Wie automatisieren Sie das Datenbank Backup mit Cron?

Manuelle Backups geraten in Vergessenheit, also planen Sie das Datenbank Backup ein. Legen Sie den Befehl zuerst in ein Skript und starten Sie es dann per Cron. Das folgende Skript ist ein Beispiel. Passen Sie Pfade und Datenbanknamen an Ihre Umgebung an.

#!/bin/bash
set -euo pipefail
ZIEL=/home/benutzer/backups/db
STAMP=$(date +%Y%m%d-%H%M)
mkdir -p "$ZIEL"
mysqldump --defaults-extra-file=/home/benutzer/.backup.cnf \
  --single-transaction --routines --triggers --events beispiel_db \
  | gzip > "$ZIEL/beispiel_db-$STAMP.sql.gz"
find "$ZIEL" -name 'beispiel_db-*.sql.gz' -mtime +14 -delete

Machen Sie das Skript ausführbar, öffnen Sie crontab -e und tragen Sie die folgende Zeile ein. Sie läuft jede Nacht um 03:30 Uhr und schreibt die Ausgabe in ein Protokoll.

30 3 * * * /home/benutzer/backup-db.sh >> /home/benutzer/backups/backup.log 2>&1

Die Prozentzeichen des Datumsformats haben wir im Skript gelassen. In Crontab Zeilen hat ein Prozentzeichen eine besondere Bedeutung und braucht eine Maskierung. Deshalb ist eine eigene Skriptdatei sicherer.

Wie lange bewahren Sie alte Backups auf und wie löschen Sie sie?

Bewahren Sie jedes Backup ewig auf, läuft die Platte voll, und der Sicherungsauftrag scheitert eines Tages. Die find Zeile im Skript verhindert das, denn sie löscht Dateien, die älter als 14 Tage sind. Die Zahl wählen Sie trotzdem passend zu Ihrem Bedarf.

Drei Fragen bestimmen die Aufbewahrung. Wie spät bemerken Sie einen Fehler? Müssen Sie Bestell oder Nutzerdaten gesetzlich aufbewahren? Wie viel Platz haben Sie? Bemerken Sie einen Fehler zum Beispiel erst nach drei Wochen, reichen zwei Wochen Aufbewahrung nicht.

• Tägliche Backups halten Sie kurz, wöchentliche länger.
• Führen Sie den Löschbefehl zuerst ohne -delete aus und prüfen Sie die Liste.
• Vergewissern Sie sich vor dem Löschen, dass das neue Backup erfolgreich war.

Eine feste Zahl nennen wir hier deshalb nicht. Die richtige Regel hängt davon ab, wie schnell sich Ihre Daten ändern und welche rechtlichen Pflichten gelten. Das allgemeine Prinzip gestaffelter Aufbewahrung finden Sie in der Strategie Anleitung.

Bremst ein Datenbank Backup Ihren Server aus?

Das kann tatsächlich passieren, denn Lesen kostet Leistung. Bei der Sicherung liest die Datenbank ihre Tabellen von vorn bis hinten. Das beansprucht CPU und Festplatte, daher kann ein Backup zur Stoßzeit die Website verlangsamen. Legen Sie den Auftrag deshalb in eine Zeit mit wenigen Besuchern. Schauen Sie in Ihre Traffic Auswertung und wählen Sie die ruhigste Stunde.

Laut MySQL Handbuch ist --opt standardmäßig aktiv und schaltet auch --quick ein. Diese Option liest eine Tabelle zeilenweise, sodass keine riesige Tabelle im Speicher landet. Kurz gesagt: mysqldump arbeitet schon speicherschonend. Die Priorität des Auftrags können Sie trotzdem mit nice und ionice senken.

nice -n 19 ionice -c3 /home/benutzer/backup-db.sh

Diese Zeile startet das Skript mit der niedrigsten CPU Priorität und der Leerlauf Klasse für die Platte. Auf Shared Hosting laufen diese Befehle eventuell nicht, oder Ihr Kontingent bremst Sie trotzdem. Dauert das Backup immer länger, ist das ein Warnsignal. Prüfen Sie dann die Datenbankgröße und fragen Sie Ihren Anbieter nach einer Sicherung von einer Replik.

Gehen Umlaute im Datenbank Backup kaputt?

Mit den richtigen Einstellungen nicht. Das Problem entsteht meist, wenn der Client beim Sichern und der Client beim Laden verschiedene Zeichensätze nutzen. Dann können ä, ö, ü und ß als Fragezeichen oder seltsame Symbole enden. Ermitteln Sie deshalb zuerst den Zeichensatz Ihrer Datenbank.

Dafür dient konkret die Anweisung SHOW CREATE DATABASE, deren Ausgabe den Zeichensatz zeigt. mysqldump kennt die Option --default-character-set. Nutzt Ihre Datenbank utf8mb4, ist es sicher, denselben Wert beim Sichern und beim Laden anzugeben. Prüfen Sie nach dem Testlauf einige Zeilen mit Umlauten mit bloßem Auge.

Bei PostgreSQL ist das Risiko kleiner, weil das Archiv die Kodierung der Datenbank mitführt. Trotzdem sollten Sie aufpassen, wenn Sie in eine Datenbank mit anderer Kodierung laden. Vor allem alte Websites verbergen oft gemischte Kodierungen, die erst beim Umzug sichtbar werden.

Wie sichern Sie nur einzelne Tabellen oder nur die Struktur?

Manchmal brauchen Sie nicht die ganze Datenbank. mysqldump erlaubt es, nach dem Datenbanknamen Tabellennamen anzugeben. Dann sichert es nur diese Tabellen. Für eine Entwicklungskopie wollen Sie zum Beispiel nur die Tabellen für Produkte und Kategorien.

mysqldump --defaults-extra-file=/home/benutzer/.backup.cnf \
  --single-transaction beispiel_db produkte kategorien > produkte.sql

Die Option --ignore-table macht das Gegenteil. Sie lassen große und unnötige Tabellen weg, etwa Protokolldaten. Außerdem schreibt --no-data nur die Tabellenstruktur. Das hilft beim Aufbau einer leeren Testumgebung.

Dennoch sollten Sie einen Teil Dump nicht als sicheres Backup betrachten. Beziehungen zwischen Tabellen können unvollständig bleiben. Sichern Sie deshalb regelmäßig immer die vollständige Datenbank und nutzen Sie Teil Dumps nur für besondere Aufgaben.

Wie stellen Sie ein MySQL Backup wieder her?

Laut MySQL Handbuch stellen Sie einen Dump wieder her, indem Sie die Datei an den mysql Client übergeben. Die Zieldatenbank muss also vorher existieren. Legen Sie sie also an und laden Sie dann die Datei.

mysql --defaults-extra-file=/home/benutzer/.backup.cnf \
  -e "CREATE DATABASE test_wiederherstellung"
gunzip < beispiel_db.sql.gz | mysql \
  --defaults-extra-file=/home/benutzer/.backup.cnf test_wiederherstellung

Ist Ihr Backup Benutzer nur zum Lesen gedacht, nutzen Sie für das Laden ein anderes Konto mit Schreibrechten. Erstellen Sie vor dem Laden in eine Live Datenbank immer ein frisches Backup. Eine Wiederherstellung ins falsche Ziel kann Daten dauerhaft verändern.

Große Dateien brauchen daher lange. Währenddessen kann die Website mit halben Daten laufen. Führen Sie deshalb eine Wiederherstellung im Live Betrieb in einem Wartungsfenster durch und zeigen Sie den Besuchern eine Wartungsseite.

Wie stellen Sie ein PostgreSQL Backup wieder her?

Das Werkzeug hängt also vom Format ab. psql lädt Klartext Dateien, pg_restore lädt Custom und Verzeichnisarchive. Im Beispiel legen wir zuerst eine leere Datenbank an und laden das Archiv dann hinein.

createdb test_wiederherstellung
pg_restore --dbname=test_wiederherstellung --no-owner --exit-on-error beispiel_db.dump

Laut PostgreSQL Handbuch hält --exit-on-error beim ersten Fehler an, und --no-owner stellt die Eigentümer der Objekte nicht wieder her. Die Option --list zeigt außerdem den Inhalt des Archivs. So sehen Sie vor dem Laden, dass die Datei lesbar ist.

Für eine Klartext Datei nutzen Sie die folgende Form. Die Variable ON_ERROR_STOP sorgt dafür, dass psql beim ersten Fehler stoppt.

gunzip -c beispiel_db.sql.gz | psql --set ON_ERROR_STOP=on \
  --dbname=test_wiederherstellung

Das Handbuch sagt zudem, dass sich --single-transaction nicht mit --jobs kombinieren lässt. Entscheiden Sie also, ob Ihnen Tempo oder Integrität in einer Transaktion wichtiger ist.

Wie prüfen Sie, ob ein Datenbank Backup wirklich funktioniert?

Ein Backup, das Sie nie wiederhergestellt haben, ist eine Datei ohne Beweis. Die Prüfung hat drei Schritte, also kein großer Aufwand. Zunächst kontrollieren Sie, dass die Datei nicht defekt ist. Danach laden Sie sie in eine Testumgebung. Schließlich zählen Sie, ob die Datenmenge der Erwartung entspricht.

1. Testen Sie die komprimierte Datei mit gzip -t.
2. Suchen Sie am Ende der mysqldump Ausgabe nach der Zeile "Dump completed".
3. Führen Sie bei einem PostgreSQL Archiv pg_restore --list aus.
4. Laden Sie in eine Testdatenbank und vergleichen Sie die Zeilenzahlen wichtiger Tabellen.
5. Verbinden Sie eine Testkopie der Website und öffnen Sie eine echte Bestell oder Beitragsseite.

Wir empfehlen, diese Prüfung einmal im Monat zu wiederholen. Ein Backup Skript kann nämlich still kaputtgehen: Ein Passwort ändert sich, die Platte läuft voll, ein Recht fehlt. Cron läuft dann weiter, und die Datei bleibt trotzdem leer.

Am sichersten testen Sie in einer Umgebung getrennt vom Live Server. Eine kurzlebige Datenbank mit Docker auf dem eigenen Rechner eignet sich gut. Grundlagen dazu finden Sie in unserem Docker Leitfaden.

Wie nutzen Sie das Backup für den Umzug auf einen neuen Server?

Die größte Stärke eines logischen Backups ist die Übertragbarkeit. Legen Sie auf dem neuen Server eine leere Datenbank und einen Benutzer an und laden Sie dann die Datei. Da die Datei SQL Text ist, läuft sie meist ohne Probleme zwischen Engine Versionen. Lesen Sie vor einem großen Versionssprung trotzdem die Hinweise zur Kompatibilität im Handbuch.

Beim Umzug zählt die Reihenfolge. Bereiten Sie zuerst die neue Umgebung vor und testen Sie das Laden. Stoppen Sie dann im Wartungsfenster die Schreibzugriffe auf der alten Website, erstellen Sie ein frisches Backup und laden Sie es in die neue Umgebung. Schließlich stellen Sie den DNS Eintrag auf den neuen Server um. Die Änderung beobachten Sie mit unserer DNS Abfrage.

Schalten Sie den alten Server nicht sofort ab. Während sich DNS verteilt, erreichen manche Besucher noch die alte Adresse. Beobachten Sie die neue Website einige Tage. Halten Sie die alte Datenbank in dieser Zeit schreibgeschützt, damit nicht an zwei Orten unterschiedliche Daten entstehen.

Wie bringen Sie das Backup vom Server weg?

Liegt das Backup auf derselben Platte wie die Datenbank, sind bei einem Defekt beide weg. Kopieren Sie die Datei deshalb an einen anderen Ort. Mit SSH Zugang ist rsync ein einfacher und verlässlicher Weg.

rsync -av -e ssh /home/benutzer/backups/db/ \
  backup@backup.example.com:/backups/beispiel-site/

Prüfen Sie nach dem Kopieren mit einer Prüfsumme, dass die Dateien gleich sind. Führen Sie sha256sum auf beiden Seiten aus und vergleichen Sie die Ausgabe. Bedenken Sie außerdem, dass das Backup Kundendaten enthält. Übertragen Sie es daher über einen verschlüsselten Kanal und beschränken Sie den Zugriff am Ziel.

Bei sensibleren Daten können Sie die Datei vor dem Senden verschlüsseln. Zum Beispiel bietet gpg eine symmetrische Verschlüsselung. Bewahren Sie Schlüssel oder Passwort nicht neben dem Backup auf. Einen größeren Rahmen bietet unser Beitrag zur Datensicherheit der Firmenwebsite.

Welche Fehler passieren beim Datenbank Backup am häufigsten?

Die meisten Fehler entstehen im Umfeld des Befehls, nicht im Befehl selbst. Die Liste fasst die Fallen zusammen, gestützt auf die Dokumentation.

• Das Passwort in die Befehlszeile schreiben. Optionsdatei und strenge Rechte lösen das.
• Die Option --databases unbemerkt nutzen und beim Testlauf Live Daten überschreiben.
• Bei einer Pipe auf pipefail verzichten und ein leeres Backup erzeugen.
• Rollen und Benutzer nicht sichern. Bei PostgreSQL braucht es dafür pg_dumpall.
• Ein Backup nie wiederherstellen, sodass der erste Versuch im Ernstfall stattfindet.
• Backups nur auf demselben Server aufbewahren.

Das alles lässt sich vermeiden. Richten Sie das Backup Skript einmal ein und tragen Sie die monatliche Prüfung in Ihren Kalender ein. Auch Sicherheitslücken verursachen Datenverlust, lesen Sie dazu unseren Beitrag zu den OWASP Top 10.

Wann sollten Sie es nicht selbst tun und Ihrem Hosting Anbieter überlassen?

Sie müssen nicht alles selbst erledigen. Haben Sie keinen Shell Zugang oder können Sie auf Shared Hosting keine Befehle ausführen, nutzen Sie die Backup Werkzeuge des Panels und den Support des Anbieters. Eine falsche Wiederherstellung kann Ihre Daten beschädigen.

• Die Datenbank ist sehr groß, und die Sicherung bremst die Website.
• Sie brauchen die Rückkehr zu einem genauen Zeitpunkt. Das erfordert meist Binärprotokolle und Betrieb durch Fachleute.
• Sie nutzen Replikation oder einen Cluster.
• Gesetzliche Aufbewahrungs und Prüfpflichten gelten für Sie.
• Sie sind unsicher, was die Befehle tun.

Fragen Sie bei der Anbieterwahl nach der Backup Richtlinie. Lassen Sie sich schriftlich geben, wie oft gesichert wird, wie viele Tage die Kopien bleiben und wie lange eine Wiederherstellung dauert. Dabei hilft unser Beitrag zur Auswahl von Webhosting.

Wie sieht eine kurze Checkliste für das Datenbank Backup aus?

Die Liste bündelt die Schritte dieses Leitfadens an einer Stelle. Sie können sie ausdrucken und zu Ihren Serverunterlagen legen. Haben Sie jeden Punkt einmal eingerichtet, wiederholen Sie nur noch die Prüfung.

1. Legen Sie einen Backup Benutzer mit nur den nötigen Rechten an.
2. Tragen Sie das Passwort in eine Optionsdatei ein und setzen Sie die Rechte auf 600.
3. Nutzen Sie für InnoDB --single-transaction sowie --routines, --triggers und --events.
4. Komprimieren Sie die Ausgabe und schalten Sie pipefail im Skript ein.
5. Starten Sie es täglich per Cron und räumen Sie alte Dateien auf.
6. Kopieren Sie das Backup vom Server weg und prüfen Sie die Prüfsumme.
7. Stellen Sie es einmal im Monat in eine Testdatenbank wieder her.

Richten Sie Ihr Datenbank Backup einmal richtig ein, wird der Rest zu einer kleinen Wartungsgewohnheit. Wollen Sie Ihre SQL Kenntnisse ausbauen, sind unser SQL Lernfahrplan und unsere SQL Abfrageszenarien gute nächste Schritte.

Unser Team kann Sie bei Web und Ecommerce Projekten unterstützen, Infrastrukturentscheidungen gemeinsam mit Ihrem Hosting Anbieter zu planen. Details finden Sie bei unserem Webdesign. Einen schriftlichen Plan für Backup und Wiederherstellung zu haben, spart in der Krise am meisten Zeit.

Optionen können sich zwischen Versionen ändern, also prüfen Sie immer das Handbuch Ihrer eigenen Version. Die offiziellen Seiten hinter diesem Leitfaden sind diese:

• MySQL Handbuch zu mysqldump.
• MySQL Handbuch zu Optionsdateien.
• PostgreSQL Handbuch zu pg_dump.
• PostgreSQL Handbuch zu pg_restore.
• MariaDB Handbuch zum Dump Client.

Der Versionsteil in Dokumentationslinks ändert sich mit der Zeit. Öffnen Sie die Seite der aktuellen stabilen Version und suchen Sie dieselbe Überschrift. Kurz gesagt: Prüfen Sie vor dem Befehl, ob die Option in Ihrer Version existiert.