Wer Datenbanken im Eigenbetrieb hostet - egal ob auf dem Homeserver, einer VPS oder dem Synology-NAS - braucht zuverlässige, automatische Sicherungen. Diese Anleitung zeigt, wie Sie Ihr MySQL/MariaDB- und PostgreSQL-Backup mit cron automatisieren: Wir nutzen mysqldump und pg_dump für konsistente Dumps, komprimieren mit gzip, halten den Speicher per Retention-Regel sauber und schieben die Sicherungen verschlüsselt mit rclone in die Cloud. Am Ende läuft ein Bash-Skript täglich per cron-Job, ohne manuellen Eingriff. Die Anleitung richtet sich an Administratoren, die Datenbanken gegen Ausfall, Ransomware und versehentliches Löschen absichern.

Was ist mysqldump und pg_dump - und warum automatisieren?

mysqldump ist das offizielle Client-Werkzeug von MySQL/MariaDB, das eine Datenbank in eine Textdatei mit SQL-Anweisungen exportiert (logisches Backup). pg_dump ist das Gegenstück von PostgreSQL und kann zusätzlich ein komprimiertes Custom-Format (-F c) erzeugen, das sich selektiv und parallel zurücksichern lässt. Beide Tools erstellen ein konsistentes Abbild des Datenbestands zu einem Zeitpunkt - bei MySQL via --single-transaction ohne Tabellen-Locks (für InnoDB), bei PostgreSQL ohnehin transaktional sauber.

Manuelle Backups vergisst man im Alltag - genau dann, wenn die Platte stirbt oder ein DROP TABLE daneben geht. Deshalb kombinieren wir die Dumps mit einem cron-Job (zeitgesteuerte Automatisierung unter Linux), einer Rotation (alte Dateien werden gelöscht) und einem Offsite-Upload in die Cloud. Das Ergebnis erfüllt die bekannte 3-2-1-Regel: drei Kopien, zwei Medien, eine außer Haus.

Voraussetzungen

Ein Linux-Server (Debian/Ubuntu, RHEL/Rocky oder ein NAS mit Shell-Zugriff, x86 oder ARM) mit Root- bzw. sudo-Rechten. Das Skript selbst braucht kaum Ressourcen; 1 CPU-Kern und 1 GB RAM neben der Datenbank reichen.
Eine laufende MySQL/MariaDB- und/oder PostgreSQL-Instanz, mit lokalem Zugriff.
Installierte Client-Tools: mysqldump (Paket mysql-client/mariadb-client) bzw. pg_dump (Paket postgresql-client).
gzip, find und cron (auf den meisten Systemen vorinstalliert).
rclone für den Cloud-Sync (z. B. zu S3, Backblaze B2, Google Drive, Hetzner Storage Box).
Ein Verzeichnis für die Backups, z. B. /var/backups/db. Planen Sie freien Speicher für mindestens die komprimierte Dump-Größe mal Anzahl der Aufbewahrungstage ein.

Schritt 1: Backup-Verzeichnis und Client-Tools vorbereiten

Legen Sie zuerst ein dediziertes Backup-Verzeichnis an und installieren Sie die Dump-Werkzeuge, falls noch nicht vorhanden.

sudo mkdir -p /var/backups/db
sudo chmod 750 /var/backups/db

# Debian/Ubuntu
sudo apt update
sudo apt install -y mariadb-client postgresql-client gzip rclone

# RHEL/Rocky/AlmaLinux
sudo dnf install -y mariadb postgresql gzip rclone

Prüfen Sie anschließend, ob die Tools erreichbar sind:

mysqldump --version
pg_dump --version
rclone version

Verifizieren: Alle drei Befehle geben eine Versionsnummer aus, ls -ld /var/backups/db zeigt drwxr-x---. Die Hauptversion von pg_dump muss mindestens der des PostgreSQL-Servers entsprechen.

Schritt 2: Datenbank-Zugangsdaten sicher hinterlegen

Niemals Passwörter direkt ins Skript schreiben. Bei MySQL/MariaDB nutzen Sie eine geschützte .my.cnf, bei PostgreSQL eine .pgpass-Datei.

MySQL/MariaDB: .my.cnf

Verwenden Sie die Gruppe [client] - so lesen sowohl mysqldump (Backup) als auch der mysql-Client (Restore) dieselben Zugangsdaten.

[client]
user=backup
password=IHR_SICHERES_PASSWORT
host=localhost

Speichern Sie die Datei als /root/.my.cnf und setzen Sie die Rechte streng:

sudo chmod 600 /root/.my.cnf

Legen Sie einen eigenen Backup-User mit Lese- und Sperrrechten an, statt root zu verwenden. PROCESS braucht mysqldump für die Tablespace-Informationen, sonst bricht der Dump mit einem Rechtefehler ab:

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'IHR_SICHERES_PASSWORT';
GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, PROCESS, RELOAD, REPLICATION CLIENT
  ON *.* TO 'backup'@'localhost';
FLUSH PRIVILEGES;

PostgreSQL: .pgpass

Legen Sie in PostgreSQL eine Rolle backup an, die alle Daten lesen darf (ab PostgreSQL 14 über die Rolle pg_read_all_data):

sudo -u postgres psql -c "CREATE ROLE backup LOGIN PASSWORD 'IHR_SICHERES_PASSWORT';"
sudo -u postgres psql -c "GRANT pg_read_all_data TO backup;"

Das Format der Passwortdatei ist host:port:datenbank:user:passwort. Speichern Sie diese Zeile als /root/.pgpass:

localhost:5432:*:backup:IHR_SICHERES_PASSWORT

Setzen Sie danach die Rechte, sonst ignoriert libpq die Datei:

sudo chmod 600 /root/.pgpass

Alternativ lässt sich PGPASSWORD als Umgebungsvariable setzen. .pgpass ist sauberer, weil das Passwort nicht in der Prozessumgebung auftaucht.

Verifizieren: sudo mysql --defaults-file=/root/.my.cnf -e 'SHOW GRANTS' listet die Rechte des Users backup, sudo psql -U backup -h localhost -d postgres -c 'SELECT 1' antwortet ohne Passwortabfrage.

Schritt 3: rclone für den Cloud-Sync einrichten

Konfigurieren Sie ein rclone-Remote interaktiv. Im Beispiel nennen wir es cloud (z. B. Backblaze B2 oder S3-kompatibel).

rclone config

Folgen Sie dem Assistenten (n für neues Remote, Typ wählen, Keys eingeben). Führen Sie rclone config mit sudo aus, wenn das Skript später als root läuft, da die Konfiguration pro Benutzer gespeichert wird. Testen Sie danach den Zugriff:

rclone lsd cloud:
rclone mkdir cloud:db-backups

Für Ende-zu-Ende-Verschlüsselung legen Sie ein crypt-Remote über Ihr Cloud-Remote, sodass die Dumps nur verschlüsselt beim Anbieter liegen.

Verifizieren: sudo rclone lsd cloud: listet den Ordner db-backups ohne Fehlermeldung.

Schritt 4: Das Backup-Skript schreiben

Das Bash-Skript das beide Datenbanksysteme sichert, komprimiert, rotiert und hochlädt. Speichern Sie es als /usr/local/bin/db-backup.sh.

#!/usr/bin/env bash
set -euo pipefail

# --- Konfiguration ---
BACKUP_DIR="/var/backups/db"
TIMESTAMP="$(date +%F_%H-%M-%S)"
RETENTION_DAYS=30
RCLONE_REMOTE="cloud:db-backups"
LOGFILE="/var/log/db-backup.log"

log() { echo "$(date '+%F %T') $*" | tee -a "$LOGFILE"; }

mkdir -p "$BACKUP_DIR"

# --- MySQL / MariaDB: alle Datenbanken, transaktionssicher ---
MYSQL_FILE="$BACKUP_DIR/mysql_all_${TIMESTAMP}.sql.gz"
log "Starte mysqldump -> $MYSQL_FILE"
mysqldump --defaults-file=/root/.my.cnf \
  --all-databases --single-transaction --quick \
  --routines --events --triggers \
  | gzip -9 > "$MYSQL_FILE"

# --- PostgreSQL: jede DB einzeln im Custom-Format ---
log "Starte pg_dump fuer alle PostgreSQL-Datenbanken"
export PGPASSFILE=/root/.pgpass
for DB in $(psql -U backup -h localhost -tAc \
    "SELECT datname FROM pg_database WHERE datistemplate = false AND datname <> 'postgres';"); do
  PG_FILE="$BACKUP_DIR/pg_${DB}_${TIMESTAMP}.dump"
  log "pg_dump $DB -> $PG_FILE"
  pg_dump -U backup -h localhost -F c -Z 6 -f "$PG_FILE" "$DB"
done

# --- Retention: alte Backups lokal loeschen ---
log "Loesche lokale Backups aelter als ${RETENTION_DAYS} Tage"
find "$BACKUP_DIR" -type f \( -name '*.sql.gz' -o -name '*.dump' \) \
  -mtime +"$RETENTION_DAYS" -delete

# --- Cloud-Sync ---
log "Synchronisiere nach $RCLONE_REMOTE"
rclone copy "$BACKUP_DIR" "$RCLONE_REMOTE" --transfers 4 --log-file "$LOGFILE" --log-level INFO

log "Backup abgeschlossen."

Machen Sie das Skript ausführbar:

sudo chmod 750 /usr/local/bin/db-backup.sh

Was die wichtigsten Flags bewirken

--single-transaction: konsistenter MySQL-Dump ohne Tabellen-Locks (InnoDB).
--quick: streamt große Tabellen zeilenweise, schont den RAM.
--routines --events --triggers: sichert auch Stored Procedures, Events und Trigger mit.
pg_dump -F c: PostgreSQL Custom-Format - komprimiert und mit pg_restore selektiv rücksicherbar.
-Z 6: Kompressionsstufe für pg_dump (0-9).
find -mtime +30 -delete: Retention, löscht Dateien älter als 30 Tage.

Hinweis: rclone copy löscht in der Cloud nichts. Alte Sicherungen entfernen Sie dort über eine Lebenszyklus-Regel des Speicheranbieters oder rclone delete --min-age 30d.

Verifizieren: bash -n /usr/local/bin/db-backup.sh meldet keinen Syntaxfehler, ls -l /usr/local/bin/db-backup.sh zeigt -rwxr-x---.

Schritt 5: cron-Job für die Automatisierung einrichten

Lassen Sie das Skript täglich nachts laufen. Öffnen Sie die crontab des Root-Users:

sudo crontab -e

Fügen Sie diese Zeile ein, sie startet das Skript täglich um 02:30 Uhr mit Logausgabe:

30 2 * * * /usr/local/bin/db-backup.sh >> /var/log/db-backup-cron.log 2>&1

Prüfen Sie, ob der Eintrag aktiv ist:

sudo crontab -l

Auf Systemen mit systemd können Sie alternativ einen Timer nutzen, das Prinzip bleibt gleich.

Verifizieren: sudo crontab -l zeigt die Zeile, am nächsten Morgen enthält /var/log/db-backup.log den Eintrag „Backup abgeschlossen.“ mit Datum 02:30.

Schritt 6: Erster Test und Verifikation

Starten Sie das Skript einmal manuell und beobachten Sie das Log:

sudo /usr/local/bin/db-backup.sh
ls -lh /var/backups/db
tail -n 20 /var/log/db-backup.log

Prüfen Sie, ob die Dateien in der Cloud angekommen sind:

rclone ls cloud:db-backups

Restore testen - das wichtigste Detail

Ein Backup ohne erfolgreichen Restore-Test ist nicht belastbar. Testen Sie die Wiederherstellung in einer separaten Testinstanz, nicht auf dem Produktivserver.

MySQL/MariaDB aus dem gzip-Dump. Achtung: Ein Dump mit --all-databases enthält DROP- und CREATE DATABASE-Anweisungen und überschreibt auf dem Zielserver alle gleichnamigen Datenbanken. Führen Sie den Befehl deshalb nur auf einem Testserver aus:

gunzip < /var/backups/db/mysql_all_2026-05-31_02-30-00.sql.gz | mysql --defaults-file=/root/.my.cnf

PostgreSQL aus dem Custom-Format mit pg_restore:

createdb -U backup -h localhost meinedb_restore
pg_restore -U backup -h localhost -d meinedb_restore /var/backups/db/pg_meinedb_2026-05-31_02-30-00.dump

Verifizieren: ls -lh /var/backups/db zeigt je Lauf eine .sql.gz-Datei und je PostgreSQL-Datenbank eine .dump-Datei mit plausibler Größe, rclone ls listet dieselben Dateien, und die Testinstanz enthält nach dem Restore die erwarteten Tabellen.

Updates & Wartung

Halte die Client-Tools aktuell (apt upgrade bzw. dnf update), damit mysqldump/pg_dump zur Server-Version passen - vor allem bei einem PostgreSQL-Major-Upgrade brauchen Sie den passenden Client. Prüfen Sie regelmäßig die Logdatei und richten Sie einen Monitoring-Check ein (z. B. eine Healthcheck-URL, die das Skript am Ende per curl aufruft), damit ein fehlgeschlagener Lauf auffällt.

Backup-Hinweis

Dieses Setup deckt die Datenbanken ab. Sichern Sie zusätzlich die .my.cnf, .pgpass, das Skript selbst und die rclone-Konfiguration (~/.config/rclone/rclone.conf). Für komplette Server- und Datei-Backups ergänzen Sie ein dateibasiertes Werkzeug, siehe „Weiterführende Anleitungen“.

Troubleshooting

mysqldump: Access denied: Der Backup-User hat zu wenig Rechte oder die .my.cnf wird nicht gelesen. Prüfen Sie den --defaults-file-Pfad und die GRANTs. Meldet der Dump „Access denied; you need (at least one of) the PROCESS privilege(s)“, fehlt das Recht PROCESS, alternativ hilft --no-tablespaces.
pg_dump: no password supplied: .pgpass hat falsche Rechte (muss 600 sein) oder das Format stimmt nicht. Setzen Sie testweise PGPASSWORD.
cron läuft, aber nichts passiert: cron hat ein minimales PATH. Nutzen Sie im Skript absolute Pfade oder setzen Sie PATH in der crontab.
rclone: directory not found: Remote-Name oder Bucket falsch. Prüfen Sie mit rclone listremotes und rclone lsd cloud:.
Dump bricht bei großen DBs ab: Festplatte voll oder Timeout. Nutzen Sie Streaming (kein Zwischenfile) und prüfen Sie den freien Speicher mit df -h.
Inkonsistente MyISAM-Tabellen: --single-transaction wirkt nur für InnoDB. Bei MyISAM hilft nur --lock-tables (kurzer Lock) oder die Migration zu InnoDB.

Häufige Fragen

Was ist der Unterschied zwischen mysqldump und pg_dump?

mysqldump sichert MySQL/MariaDB und erzeugt standardmäßig eine reine SQL-Textdatei. pg_dump sichert PostgreSQL und kann zusätzlich ein binäres Custom-Format (-F c) schreiben, das komprimiert ist und mit pg_restore selektiv und parallel zurückgespielt werden kann. Beide erstellen logische, konsistente Backups.

Wie automatisiere ich Datenbank-Backups mit cron?

Sie packen die Dump-Befehle in ein Bash-Skript, machen es mit chmod 750 ausführbar und tragen es in die crontab ein, z. B. 30 2 * * * /usr/local/bin/db-backup.sh für einen täglichen Lauf um 02:30 Uhr. cron startet das Skript dann automatisch ohne manuelles Eingreifen.

Wie funktioniert die Backup-Rotation?

Jedes Backup bekommt einen Zeitstempel im Dateinamen. Eine Retention-Regel löscht alte Dateien automatisch, im Beispiel mit find /var/backups/db -type f -mtime +30 -delete Das entfernt alles, was älter als 30 Tage ist. So bleibt der Speicherbedarf konstant und nur die jüngsten Sicherungen bleiben erhalten.

Wie verschlüssele ich die Backups in der Cloud?

Legen Sie in rclone ein crypt-Remote über Ihr Cloud-Remote. Damit werden Dateinamen und Inhalte vor dem Upload verschlüsselt und liegen nur verschlüsselt beim Anbieter. Im Skript verweist rclone copy dann auf das crypt-Remote statt direkt auf den Bucket.

Wie sichere ich sehr große Datenbanken effizient?

Nutzen Sie Streaming statt Zwischendateien (Pipe direkt in gzip), --quick bei mysqldump und parallele pg_dump-Jobs mit -j im Directory-Format. Prüfen Sie den freien Speicher vorher und ziehen Sie für sehr große Instanzen zusätzlich physische Backups (z. B. Percona XtraBackup bzw. pg_basebackup) in Betracht.

Fazit

Mit einem schlanken Bash-Skript, mysqldump bzw. pg_dump, gzip-Kompression, einer find-Retention und rclone entsteht ein automatisches Datenbank-Backup, per cron gesteuert und mit Offsite-Kopie in der Cloud. Testen Sie regelmäßig die Wiederherstellung, überwachen Sie die Logs und sichern Sie auch die Zugangsdaten. Das schützt vor Plattenausfall, Fehlbedienung und Ransomware.

Weiterführende Anleitungen & Quellen

Wenn Sie neben den Datenbanken auch komplette Server und Dateien sichern, kombinieren Sie dieses Setup mit einem deduplizierenden Backup-Tool: In unserer Anleitung zu restic-Backups unter Linux und Windows automatisieren zeigen wir verschlüsselte, inkrementelle Sicherungen per cron. Mehr zu Datensicherung, Retention und Offsite-Strategien finden Sie in der Kategorie Backup.

Quellen: Offizielle Dokumentation von MySQL mysqldump, PostgreSQL pg_dump und rclone.