Wer Datenbanken im Eigenbetrieb hostet - egal ob auf dem Homeserver, einer VPS oder dem Synology-NAS - braucht zuverlässige, automatische Sicherungen. In dieser Anleitung lernst du, wie du dein MySQL/MariaDB- und PostgreSQL-Backup mit cron automatisieren kannst: 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 dass du manuell eingreifen musst. Die Anleitung richtet sich an Admins, Selfhoster und alle, die ihre Daten gegen Ausfall, Ransomware und versehentliches Löschen absichern wollen.

Kurzfassung: Bash-Skript erstellt Dumps mit mysqldump --single-transaction bzw. pg_dump -F c, packt sie mit gzip, benennt sie mit Zeitstempel, löscht alte Dateien per find -mtime +30 -delete und synchronisiert per rclone copy in die Cloud. Ein cron-Eintrag startet das Ganze täglich.

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 ausser Haus.

Voraussetzungen

Ein Linux-Server (Debian/Ubuntu, RHEL/Rocky oder ein NAS mit Shell-Zugriff) mit Root- bzw. sudo-Rechten.
Eine laufende MySQL/MariaDB- und/oder PostgreSQL-Instanz, auf die du dich lokal verbinden kannst.
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, mit ausreichend Speicherplatz.

Schritt 1: Backup-Verzeichnis und Client-Tools vorbereiten

Lege zuerst ein dediziertes Backup-Verzeichnis an und installiere 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üfe anschließend, ob die Tools erreichbar sind:

mysqldump --version
pg_dump --version
rclone version

Schritt 2: Datenbank-Zugangsdaten sicher hinterlegen

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

MySQL/MariaDB: .my.cnf

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

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

Speichere die Datei als /root/.my.cnf und setze die Rechte streng:

sudo chmod 600 /root/.my.cnf

Lege idealerweise einen eigenen Backup-User mit Lese- und Sperrrechten an, statt root zu verwenden:

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

PostgreSQL: .pgpass

Das Format ist host:port:datenbank:user:passwort. Datei nach /root/.pgpass mit Rechten 600:

localhost:5432:*:backup:DEIN_SICHERES_PASSWORT
sudo chmod 600 /root/.pgpass

Alternativ kannst du im Skript PGPASSWORD als Umgebungsvariable setzen - .pgpass ist aber sauberer, weil das Passwort nicht in der Prozessliste auftaucht.

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

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

rclone config

Folge dem Assistenten (n für neues Remote, Typ wählen, Keys eingeben). Teste danach den Zugriff:

rclone lsd cloud:
rclone mkdir cloud:db-backups

Tipp: Für Ende-zu-Ende-Verschlüsselung kannst du ein crypt-Remote über dein Cloud-Remote legen, sodass die Dumps verschlüsselt in der Cloud liegen.

Schritt 4: Das Backup-Skript schreiben

Jetzt kommt das Herzstück: ein Bash-Skript, das beide Datenbanksysteme sichert, komprimiert, rotiert und hochlädt. Speichere 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."

Mach 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.

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

Lass das Skript täglich nachts laufen. Öffne die crontab des Root-Users:

sudo crontab -e

Füge diese Zeile ein - 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üfe, ob der Eintrag aktiv ist:

sudo crontab -l

Auf Systemen mit systemd kannst du alternativ einen Timer nutzen, das Prinzip bleibt aber gleich.

Schritt 6: Erster Test und Verifikation

Starte das Skript einmal manuell und beobachte das Log:

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

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

rclone ls cloud:db-backups

Restore testen - das wichtigste Detail

Ein Backup, das du nie zurückgespielt hast, ist nur eine Hoffnung. Teste die Wiederherstellung in einer leeren Test-Datenbank.

MySQL/MariaDB aus dem gzip-Dump:

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

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 musst du den passenden Client installieren. Prüfe regelmäßig die Logdatei und richte einen Monitoring-Check ein (z. B. eine Healthcheck-URL, die das Skript am Ende per curl aufruft), damit du Bescheid weißt, falls ein Lauf fehlschlägt.

Backup-Hinweis

Dieses Setup ist deine Backup-Strategie für die Datenbanken - aber denk an die zweite Ebene: Sichere auch die .my.cnf, .pgpass, das Skript selbst und die rclone-Konfiguration (~/.config/rclone/rclone.conf). Für komplette Server- und Datei-Backups ergänzt sich diese Lösung gut mit einem dateibasierten Tool - siehe unseren Cross-Link-Absatz weiter unten.

Troubleshooting

mysqldump: Access denied: Der Backup-User hat zu wenig Rechte oder die .my.cnf wird nicht gelesen. Prüfe --defaults-file-Pfad und die GRANTs.
pg_dump: no password supplied: .pgpass hat falsche Rechte (muss 600 sein) oder das Format stimmt nicht. Setze testweise PGPASSWORD.
cron läuft, aber nichts passiert: cron hat ein minimales PATH. Nutze im Skript absolute Pfade oder setze PATH in der crontab.
rclone: directory not found: Remote-Name oder Bucket falsch. Prüfe mit rclone listremotes und rclone lsd cloud:.
Dump bricht bei großen DBs ab: Festplatte voll oder Timeout. Nutze Streaming (kein Zwischenfile) und prüfe 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?

Du packst die Dump-Befehle in ein Bash-Skript, machst es mit chmod 750 ausführbar und trägst 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 Speicher konstant und du behältst nur die jüngsten Sicherungen.

Wie verschlüssele ich die Backups in der Cloud?

Lege in rclone ein crypt-Remote über dein 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?

Nutze Streaming statt Zwischendateien (Pipe direkt in gzip), --quick bei mysqldump und parallele pg_dump-Jobs mit -j im Directory-Format. Prüfe den freien Speicher vorher und ziehe 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 hast du in wenigen Schritten ein robustes, automatisches Datenbank-Backup gebaut - vollständig per cron gesteuert und mit Offsite-Kopie in der Cloud. Wichtig bleibt: Teste regelmäßig die Wiederherstellung, überwache die Logs und sichere auch deine Zugangsdaten. Dann bist du gegen Plattenausfall, Fehlbedienung und Ransomware deutlich besser aufgestellt.

Weiterführende Anleitungen & Quellen

Wenn du neben den Datenbanken auch komplette Server und Dateien sichern willst, kombiniere 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 rund um Datensicherung, Retention und Offsite-Strategien findest du gebündelt in der Kategorie Backup.

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