Datenbank-Backup: MySQL und PostgreSQL sichern & wiederherstellen

1. Warum Datenbank-Backups unverzichtbar sind

Datenbanken sind das Herzstück der meisten Webanwendungen: Alle Blog-Artikel, Produkte, Bestellungen, Benutzerkonten – alles liegt dort. Ein korruptes Update, ein Programmierfehler, ein gehackter Server oder schlicht ein Hardware-Ausfall kann diese Daten unwiederbringlich zerstoeren. Hosting-Anbieter bieten zwar haeufig automatische Backups an – aber diese sind nicht garantiert vollstaendig, aktuell oder kostenlos wiederherstellbar.

2. MySQL-Datenbank sichern mit mysqldump

mysqldump ist das Standard-Werkzeug fuer MySQL- und MariaDB-Backups. Es erstellt einen SQL-Dump – eine Textdatei mit allen CREATE TABLE und INSERT-Befehlen, die noetig sind, um die Datenbank vollstaendig wiederherzustellen.

Grundlegender mysqldump-Befehl

# Einzelne Datenbank sichern
mysqldump -u benutzername -p datenbankname > backup_$(date +%Y%m%d_%H%M%S).sql

# Alle Datenbanken sichern
mysqldump -u root -p --all-databases > alle_dbs_$(date +%Y%m%d).sql

# Einzelne Datenbank mit Kompression
mysqldump -u benutzername -p datenbankname | gzip > backup_$(date +%Y%m%d).sql.gz

Sicherere Authentifizierung mit .my.cnf

Passwort in der Kommandozeile zu uebergeben ist unsicher (sichtbar in der Prozessliste). Lege stattdessen ~/.my.cnf an:

[client]
user=benutzername
password=deinpasswort
host=localhost

chmod 600 ~/.my.cnf

Dann kannst du mysqldump datenbankname > backup.sql ohne -u und -p aufrufen.

Optimierte mysqldump-Optionen fuer Produktion

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  --events \
  datenbankname | gzip > backup_$(date +%Y%m%d_%H%M).sql.gz

• --single-transaction – Konsistentes Backup ohne Tabellen zu sperren (fuer InnoDB)
• --quick – Zeilenweise statt komplett puffern – spart RAM bei grossen Tabellen
• --routines – Stored Procedures und Functions mit sichern
• --triggers – Triggers mit sichern
• --events – Event-Scheduler-Ereignisse mit sichern

3. MySQL-Backup wiederherstellen

# Aus nicht-komprimiertem SQL-Dump
mysql -u benutzername -p datenbankname < backup.sql

# Aus komprimiertem .sql.gz
gunzip -c backup.sql.gz | mysql -u benutzername -p datenbankname

4. PostgreSQL sichern mit pg_dump

Bei PostgreSQL heisst das Pendant zu mysqldump pg_dump. Es erzeugt ebenfalls einen Dump, der alle Tabellen, Daten, Sequenzen und Berechtigungen enthaelt.

Grundlegender pg_dump-Befehl

# Einzelne Datenbank als SQL-Dump
pg_dump -U datenbankbenutzer datenbankname > backup_$(date +%Y%m%d).sql

# Mit Kompression (empfohlen)
pg_dump -U datenbankbenutzer datenbankname | gzip > backup_$(date +%Y%m%d).sql.gz

# Alle Datenbanken (plus globale Objekte wie Rollen)
pg_dumpall -U postgres > alle_dbs.sql

Passwortfreie Authentifizierung mit .pgpass

# ~/.pgpass erstellen
echo "localhost:5432:datenbankname:benutzer:passwort" >> ~/.pgpass
chmod 600 ~/.pgpass

Dann laeuft pg_dump ohne Passwortabfrage – ideal fuer Cronjobs.

Benutzerdefiniertes Format (empfohlen)

# Custom Format: schneller, komprimiert, selektiv wiederherstellbar
pg_dump -U benutzer -Fc datenbankname > backup.dump

Das Custom Format (-Fc) ist komprimiert, ermoeglicht parallele Wiederherstellung und erlaubt es, einzelne Tabellen selektiv zu restoren. Fuer grosse Datenbanken klar die bessere Wahl gegenueber einfachen SQL-Dumps.

5. PostgreSQL-Backup wiederherstellen

# Aus SQL-Dump
psql -U benutzer datenbankname < backup.sql

# Aus komprimiertem SQL
gunzip -c backup.sql.gz | psql -U benutzer datenbankname

# Aus Custom Format (mit pg_restore)
pg_restore -U benutzer -d datenbankname backup.dump

# Parallel wiederherstellen (schneller bei grossen Dumps)
pg_restore -U benutzer -d datenbankname -j 4 backup.dump

6. Eine solide Backup-Strategie entwickeln

Die 3-2-1-Regel

Die Branchenregel fuer Backups: 3 Kopien deiner Daten auf 2 verschiedenen Medien/Orten, davon 1 ausserhalb des Rechenzentrums. Fuer Webhosting bedeutet das in der Praxis:

• Kopie 1: Automatisches Backup des Hosting-Anbieters (falls vorhanden)
• Kopie 2: Dein eigener mysqldump/pg_dump auf dem gleichen Server oder NAS
• Kopie 3: Offsite-Backup auf Cloud-Speicher (S3, Backblaze B2, Google Cloud Storage)

Backup-Haeufigkeit nach Datenaenderungsrate

Vollstaendiges automatisches Backup-Skript (MySQL)

#!/bin/bash
# backup-db.sh - Taeglich ausgefuehrt via Cronjob

BACKUP_DIR="/backup/db"
DB_NAME="meinedatenbank"
RETENTION_DAYS=30
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.sql.gz"

# Verzeichnis erstellen falls nicht vorhanden
mkdir -p "$BACKUP_DIR"

# Backup erstellen
mysqldump --single-transaction --quick --routines --triggers "$DB_NAME" \
  | gzip > "$BACKUP_FILE"

# Pruefe ob Backup erfolgreich war
if [ $? -eq 0 ]; then
  echo "[$(date)] Backup erstellt: $BACKUP_FILE ($(du -sh $BACKUP_FILE | cut -f1))"
else
  echo "[$(date)] FEHLER: Backup fehlgeschlagen!" >&2
  exit 1
fi

# Alte Backups loeschen
find "$BACKUP_DIR" -name "${DB_NAME}_*.sql.gz" -mtime +$RETENTION_DAYS -delete
echo "[$(date)] Alte Backups geloescht (aelter als $RETENTION_DAYS Tage)"

7. Offsite-Backups in die Cloud

Ein Backup auf dem gleichen Server schuetzt nicht vor Serverausfall, Einbruch oder Rechenzentrumsausfall. Offsite-Backups in Cloud-Speicher sind der entscheidende dritte Schutzwall.

Backup zu AWS S3 (mit awscli)

# Nach dem mysqldump: Backup zu S3 hochladen
aws s3 cp /backup/db/backup_$(date +%Y%m%d).sql.gz s3://mein-backup-bucket/datenbank/

Backup zu Backblaze B2 (guenstiger als S3)

# Mit rclone (unterstuetzt S3, B2, Google Drive, etc.)
rclone copy /backup/db/ b2:mein-backup-bucket/datenbank/ --include "*.sql.gz"

8. Backups regelmaessig testen

Ein Backup, das du nie getestet hast, ist keins. Datenbanken koennen unbemerkt beschaedigt werden – ein Backup von einer beschaedigten Datenbank hilft nicht. Testplan:

• Monatlich: Backup in eine Test-Datenbank importieren und grundlegende Abfragen ausfuehren – passen Zeilenzahlen wichtiger Tabellen?
• Quartalsweise: Kompletten Restore auf einem Test-Server durchfuehren und die Anwendung damit starten – funktioniert alles?
• Nach jedem Schema-Aenderung: Pruefe, ob der neue Dump vollstaendig importierbar ist – neue Tabellen, neue Constraints koennten Probleme bereiten