BACKUP

mysqldump reicht nicht – ein Backup-Konzept für echte Projekte

Ich hab in meiner Karriere mehr als einmal erlebt wie jemand stolz "wir haben Backups" sagt und dann beim Restore-Versuch feststellt dass der Cronjob seit drei Monaten schweigend fehlschlug, der Dump leer ist oder die einzige Kopie auf demselben Server liegt der gerade nicht mehr existiert.

Das ist kein Vorwurf – das ist ein Systemfehler. Backups die nie getestet werden sind keine Backups, das sind Hoffnungen.

Was mysqldump kann und was nicht

mysqldump ist gut. Es erstellt konsistente logische Backups, ist auf jedem System verfügbar und produziert SQL-Dateien die man lesen und selektiv wiederherstellen kann. Für kleine bis mittelgroße Datenbanken ist es vollkommen ausreichend.

Was es nicht ist: ein vollständiges Backup-Konzept. Ein einzelner Dump ohne Rotation, ohne offsite-Kopie, ohne Monitoring ob er erfolgreich war, ist der Anfang eines Konzepts. Nicht das Konzept selbst.

#!/bin/bash # Backup-Skript das mehr macht als nur dumpen DATUM=$(date +%Y%m%d_%H%M%S) BACKUP_DIR="/backup/mysql" DB="produktions_db" DATEI="$BACKUP_DIR/${DB}_${DATUM}.sql.gz" # Dump + direkt komprimieren mysqldump --single-transaction --routines --triggers "$DB" | gzip > "$DATEI" # Prüfen ob der Dump nicht leer ist if [ ! -s "$DATEI" ]; then echo "FEHLER: Backup ist leer!" | mail -s "Backup fehlgeschlagen" admin@beispiel.de exit 1 fi # Alte Backups löschen (älter als 14 Tage) find "$BACKUP_DIR" -name "*.sql.gz" -mtime +14 -delete # Offsite-Kopie (z.B. zu anderem Server oder S3) rsync -az "$DATEI" backup-server:/backups/mysql/ # Wichtig: --single-transaction für InnoDB, sonst kein konsistenter Dump

Die drei Fragen die jedes Backup-Konzept beantworten muss

Wie alt ist der älteste Datenverlust den ich mir leisten kann? Täglich? Stündlich? Das bestimmt die Backup-Frequenz. Bei kritischen Systemen: Binary Log Backups für Point-in-Time Recovery.

Wie lange darf die Wiederherstellung dauern? Ein 50-GB-Dump einzuspielen dauert. Wer wenige Minuten RTO braucht, muss über physische Backups mit Percona XtraBackup nachdenken.

Liegt mindestens eine Kopie woanders? Nicht auf demselben Server. Nicht im selben Rechenzentrum. S3, anderer VPS, NAS zu Hause – irgendwo wo ein Server-Ausfall nicht gleichzeitig das Backup killt.

Und dann: jeden Monat einen Restore testen. Wirklich. Nicht drüber nachdenken, nicht planen, tun. Das ist der einzige Beweis dass ein Backup funktioniert.

← zurück zu Datenbanken 📂 Archiv