Backup für MySQL/MariaDB: LVM-Snapshots, Percona XtraBackup und Point-in-Time-Restore

Ein Backup für MySQL/MariaDB ist im Alltag schnell „irgendwie vorhanden“ – bis zum ersten echten Restore. Dann zeigt sich, ob Sie nur Dateien kopiert haben oder ob Sie eine wiederherstellbare Datenbank-Sicherung besitzen. In produktiven Umgebungen geht es dabei selten um einzelne Tabellen, sondern um verlässliche RPO (Recovery Point Objective: maximal tolerierbarer Datenverlust) und RTO (Recovery Time Objective: maximal tolerierte Ausfallzeit), um nachvollziehbare Prozesse und um Backups, die auch unter Last, mit großen InnoDB-Datenbeständen und mit laufenden Schreibzugriffen funktionieren.

Dieser Beitrag ordnet drei zentrale Bausteine praxisnah ein: LVM-Snapshots (Snapshot auf Blockgerätebene für schnelle, lokale „Einfrierpunkte“), Percona XtraBackup (Hot-Backup für InnoDB ohne Shutdown) und den Point-in-Time-Restore (PITR) über Binary Logs (Binlogs: Protokoll der Datenänderungen). Der Fokus liegt auf Voraussetzungen, Risiken, typischen Stolperfallen, Prüfschritten, Umsetzung und einer Rückfallstrategie, die im Incident nicht improvisiert werden muss.

Backup für MySQL/MariaDB: Was „konsistent“ bei MySQL/MariaDB wirklich bedeutet

Bei MySQL/MariaDB ist „Konsistenz“ mehrstufig. Wichtig ist die Unterscheidung zwischen crash-konsistent und transaktionskonsistent:

• Crash-konsistent: Das Backup entspricht einem plötzlichen Stromausfall. InnoDB kann beim Start per Crash-Recovery (Redo/Undo-Logs) auf einen konsistenten Zustand zurückrollen. Das ist oft ausreichend, aber nicht immer vorhersehbar schnell.
• Transaktionskonsistent: Das Backup repräsentiert einen sauberen Schnittpunkt, an dem alle Transaktionen vollständig sind. Das reduziert Überraschungen bei Recovery und ist für enge RTOs besser.

InnoDB (Standard-Storage-Engine) ist transaktionsfähig und kann Crash-Recovery. Andere Engines (z. B. MyISAM) haben andere Eigenschaften; in gemischten Umgebungen steigen die Risiken. In der Praxis sollten Sie daher zuerst klären: Welche Engines und Features werden genutzt? Dazu gehören auch Replikation, Verschlüsselung (at-rest), Tabellenkompression, große BLOBs und besonders das Binary Logging.

Baustein 1: LVM-Snapshots für MySQL/MariaDB – schnell, aber nicht magisch

LVM (Logical Volume Manager) ermöglicht Snapshots auf Blockgerätebene. Ein Snapshot hält den Zustand eines Logical Volumes zu einem Zeitpunkt fest. Technisch funktioniert das über Copy-on-Write: Ab dem Snapshot werden geänderte Blöcke in den Snapshot-Bereich umgeleitet. Das ist attraktiv, weil ein Snapshot in Sekunden erstellt ist – aber er ist keine vollständige Datensicherung, sondern ein temporärer „Einfrierpunkt“, den Sie anschließend wegsichern (z. B. per rsync oder Backup-Software) müssen.

Voraussetzungen und typische Architektur

Die wichtigste Voraussetzung: Das MySQL/MariaDB-Datadir (typisch /var/lib/mysql) muss auf einem LVM-Logical-Volume liegen. Häufige Stolperfalle: Binlogs, Relay-Logs, tmpdir oder separate Partitionen liegen nicht mit auf dem Volume. Für konsistente Wiederherstellung müssen alle zusammengehörigen Datenpfade berücksichtigt werden: Datadir, Binlogs, Konfigurationsdateien, ggf. Keyring-Dateien (bei at-rest Encryption), Zertifikate und Scripts/Units.

Warum LVM-Snapshots bei schreibenden Datenbanken scheitern können

• Snapshot läuft voll: Bei hoher Schreiblast wächst der Snapshot-Bereich schnell. Ist er voll, wird der Snapshot ungültig – und Ihr Sicherungslauf ist wertlos.
• Performance-Einbruch: Copy-on-Write erzeugt zusätzliche I/O. Unter Last kann das deutlich spürbar werden.
• Uneinheitliche Datenpfade: Wenn Binlogs oder Keyring außerhalb liegen, haben Sie zwar Daten, aber keinen reproduzierbaren Zustand.

Praxisregel: LVM-Snapshots sind gut, wenn Sie sie kurz leben lassen und sofort aus dem Snapshot heraus sichern. Sie sind weniger gut, wenn der Snapshot lange existiert oder wenn die Schreiblast unvorhersehbar ist.

Umsetzung: Snapshot erstellen, sichern, wieder entfernen

Ein praxistauglicher Ablauf kombiniert LVM mit einem kurzen Datenbank-„Freeze“. Bei InnoDB wird häufig FLUSH TABLES WITH READ LOCK (FTWRL) genutzt, um einen konsistenten Moment für nicht-transaktionale Anteile zu erzwingen; bei reinen InnoDB-Workloads ist das oft nicht nötig, aber in gemischten Umgebungen ein Sicherheitsnetz. Wichtig: Ein globaler Read-Lock blockiert Schreibzugriffe und kann Applikationen ausbremsen. Planen Sie das bewusst und kurz.

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

MYSQL_SOCK="/var/run/mysqld/mysqld.sock"
MYSQL_USER="backup"
MYSQL_PWD_FILE="/etc/mysql/backup.pwd"
LV="/dev/vg0/mariadb"
SNAP_NAME="mariadb_snap"
SNAP_SIZE="30G"   # muss zur Schreiblast passen
MOUNTPOINT="/mnt/mariadb_snap"

mysql_exec() {
  mysql --protocol=socket --socket="$MYSQL_SOCK" -u"$MYSQL_USER" 
    --password="$(cat "$MYSQL_PWD_FILE")" -e "$1"
}

# 1) optional: kurzer Read-Lock für konsistenten Schnitt
mysql_exec "FLUSH TABLES WITH READ LOCK;"
# Positionen für PITR/Diagnose notieren (bei MySQL/MariaDB Versionen unterschiedlich)
mysql_exec "SHOW MASTER STATUS;"

# 2) Snapshot erstellen
lvcreate -s -n "$SNAP_NAME" -L "$SNAP_SIZE" "$LV"

# 3) Lock sofort wieder lösen
mysql_exec "UNLOCK TABLES;"

# 4) Snapshot mounten und sichern
mkdir -p "$MOUNTPOINT"
mount -o ro "/dev/vg0/$SNAP_NAME" "$MOUNTPOINT"

# Beispiel: tar in Backup-Ziel (Platzhalter)
BACKUP_DIR="/backup/mariadb"
mkdir -p "$BACKUP_DIR"
DATE="$(date +%F_%H%M%S)"

tar -C "$MOUNTPOINT" -cpf "$BACKUP_DIR/datadir_${DATE}.tar" var/lib/mysql

# 5) Aufräumen
umount "$MOUNTPOINT"
lvremove -f "/dev/vg0/$SNAP_NAME"

Wichtig: Das Beispiel zeigt bewusst den Ablauf, nicht alle Hardening-Details. In der Realität sollten Sie Locks sauber in trap-Handlern lösen, Snapshot-Größen dynamisch planen und die Backup-Integrität prüfen (siehe unten). Außerdem: Ein tar vom Datadir ist nur sinnvoll, wenn Sie die übrigen relevanten Pfade (Binlogs, Konfig, Keyring) ebenfalls sichern oder klar dokumentiert getrennt ablegen.

Prüfschritte und Monitoring für LVM-Snapshot-Backups

• Snapshot-Auslastung: lvs -a -o+seg_monitor,lv_size,data_percent,metadata_percent in Monitoring aufnehmen. Alarmieren, bevor data_percent kritisch wird.
• Dauer des Snapshots: Snapshot-Lifetime messen und begrenzen. Je länger, desto größer die Gefahr „läuft voll“ und desto mehr I/O-Overhead.
• Restore-Probe: Regelmäßig auf einem Testsystem entpacken, Datenbank starten, Crash-Recovery beobachten, anschließend CHECK TABLE selektiv bzw. Applikations-Health-Checks ausführen.

Baustein 2: Percona XtraBackup – Hot-Backups für InnoDB mit besserer Planbarkeit

Percona XtraBackup ist ein Tool, das InnoDB-Daten „im laufenden Betrieb“ sichern kann (Hot-Backup). Es liest die InnoDB-Datendateien und nutzt Log-Informationen, um einen konsistenten Zustand herzustellen. Für Admin-Teams ist XtraBackup oft der praktikabelste Weg, wenn Downtime vermieden werden soll und LVM-Snapshots zu riskant sind (Snapshot-Füllung, getrennte Pfade, Storage-Layout).

Wichtig für MariaDB: Abhängig von Version und Distribution gibt es Unterschiede bei XtraBackup-Varianten und Kompatibilität. Prüfen Sie vorab, ob die eingesetzte XtraBackup-Version Ihre MariaDB-Version unterstützt und ob Features wie Verschlüsselung, Galera oder bestimmte Tabellenformate sauber abgedeckt sind. In heterogenen Landschaften lohnt sich ein standardisiertes „Backup-Toolchain“-Matrix-Dokument.

Was XtraBackup sichert – und was Sie zusätzlich brauchen

XtraBackup erzeugt typischerweise ein physisches Backup (Datei-/Seitenebene) inklusive Metadaten. Für einen vollständigen Wiederanlauf benötigen Sie darüber hinaus:

• Konfiguration (z. B. my.cnf, includes, systemd overrides), weil Parameter wie innodb_buffer_pool_size, datadir, log_bin oder server_id das Verhalten beim Start beeinflussen.
• Binary Logs für PITR, wenn RPO kleiner als Ihr Backup-Intervall ist.
• Keyring-/Encryption-Artefakte (je nach Setup), sonst sind Daten zwar vorhanden, aber nicht entschlüsselbar.

Basis-Runbook: Full-Backup und Prepare-Phase

Der typische Ablauf besteht aus „backup“ und „prepare“. In der Prepare-Phase werden die notwendigen Log-Replays durchgeführt, damit das Backup startfähig ist. Ohne Prepare ist ein Restore häufig unvollständig oder startet mit Fehlern.

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

BACKUP_BASE="/backup/mariadb/xtrabackup"
DATE="$(date +%F_%H%M%S)"
TARGET="$BACKUP_BASE/full_$DATE"

mkdir -p "$TARGET"

# Full backup (Beispielparameter; Zugangsdaten sicher per Datei/Secret-Store verwalten)
xtrabackup 
  --backup 
  --target-dir="$TARGET" 
  --user=backup 
  --password-file=/etc/mysql/backup.pwd 
  --socket=/var/run/mysqld/mysqld.sock

# Prepare: macht das Backup konsistent/startfähig
xtrabackup --prepare --target-dir="$TARGET"

Typische Stolperfalle: Das Backup wird erstellt, aber „prepare“ wird vergessen oder auf einem anderen Host mit unpassender Version ausgeführt. Planen Sie die Prepare-Phase als festen Jobbestandteil ein und protokollieren Sie die Versionsstände (Datenbank und Tool) in den Backup-Metadaten.

Inkrementelle Backups: Speichern sparen, aber Restore komplexer

Inkrementelle XtraBackup-Sicherungen reduzieren Datenvolumen und Laufzeit, erhöhen aber die Restore-Komplexität: Sie müssen die Kette (Full + alle Inkremente) intakt halten und in der richtigen Reihenfolge „apply-log“/prepare anwenden. Für enge RTOs ist die Restore-Zeit der Kette entscheidend – nicht die Backup-Zeit.

Empfehlung aus Betriebssicht: Nutzen Sie Inkremente nur, wenn Sie die Restore-Kette regelmäßig in einer Restore-Probe durchspielen. Sonst sparen Sie im Normalbetrieb Zeit und verlieren sie im Incident mehrfach zurück.

Troubleshooting: häufige XtraBackup-Probleme

• „permission denied“ oder SELinux/AppArmor: XtraBackup braucht Leserechte auf Datadir und Logs. Bei SELinux/AppArmor müssen Profile passen, sonst bricht das Backup mitten drin ab.
• Disk voll im Target: Physische Backups sind groß. Ohne Vorab-Check auf freien Platz und ohne Retention-Strategie laufen Sie in partielle Backups.
• Inkompatible Kombinationen: MariaDB-/MySQL-Versionen und XtraBackup-Versionen müssen zusammenpassen. Symptome sind Prepare-Fehler oder Startfehler nach Restore.
• Binlog-Positionen fehlen: Für PITR benötigen Sie definierte Startpunkte (Datei/Position oder GTID, wenn genutzt). Stellen Sie sicher, dass Sie diese Informationen pro Backup ablegen.

Baustein 3: Point-in-Time-Restore (PITR) mit Binary Logs – der Weg zu engem RPO

Ein PITR ermöglicht, eine Datenbank nicht nur auf den Zeitpunkt des letzten Backups, sondern auf einen beliebigen Zeitpunkt danach wiederherzustellen – typischerweise „bis kurz vor dem Fehler“. Das funktioniert, indem Sie ein Basis-Backup (z. B. XtraBackup oder LVM-basierter Stand) einspielen und anschließend die Binary Logs (Binlogs) bis zu einem Stoppzeitpunkt „nachfahren“. Binlogs sind das Änderungsjournal der Datenbank (DML/DDL-Ereignisse), das auch für Replikation genutzt wird.

Voraussetzungen: Binlogs richtig aktivieren und aufbewahren

Ohne Binlogs gibt es keinen PITR. Prüfen Sie in der Konfiguration (my.cnf), ob log_bin aktiv ist und wie die Aufbewahrung geregelt wird (z. B. binlog_expire_logs_seconds bzw. ältere Parameter). Achten Sie auf Speicherorte: Wenn Binlogs auf demselben Volume liegen und ein Storage-Defekt eintritt, sind Basis-Backup und Binlogs gemeinsam gefährdet. Für belastbare PITR-Fähigkeit sollten Binlogs zeitnah auf ein separates Ziel repliziert/gesichert werden.

[mysqld]
log_bin=/var/log/mysql/mysql-bin
binlog_format=ROW
# Aufbewahrung (Beispiel): 7 Tage
binlog_expire_logs_seconds=604800
sync_binlog=1

Hinweis: binlog_format=ROW (Row-based Replication) ist in vielen Betriebsumgebungen die robustere Wahl, weil Änderungen als Zeilenereignisse geloggt werden. Das hilft bei Replikationskonsistenz, kann aber Binlogs größer machen. sync_binlog=1 erhöht die Sicherheit (Binlog wird häufiger auf Disk geflusht), kann aber Schreibperformance beeinflussen. Solche Parameter sind Abwägungen; dokumentieren Sie sie als Teil Ihrer Backup-/Recovery-Policy.

PITR-Runbook in Schritten (operativ gedacht)

1. Stoppzeitpunkt definieren: „Bis wann“ soll wiederhergestellt werden? Häufig ist das kurz vor einem Fehl-Deploy, einem fehlerhaften Job oder einer Löschaktion.
2. Basis-Backup einspielen: XtraBackup-Restore oder LVM-Backup zurück auf ein frisches Datadir.
3. Startpunkt der Binlogs ermitteln: Aus Backup-Metadaten (Binlog-Datei/Position oder GTID). Ohne diesen Startpunkt ist PITR fehleranfällig.
4. Binlogs anwenden: Mit mysqlbinlog die relevanten Binlogs bis zur Zielzeit extrahieren und einspielen.
5. Validierung: Applikationschecks, Datenintegrität (stichprobenartig), Replikationsstatus (falls relevant), Performance-Parameter.

Beispiel: Binlogs bis zu einer Zielzeit anwenden

Das folgende Beispiel zeigt das Prinzip. Es setzt voraus, dass Sie die Binlogs verfügbar haben und die Zielzeit sauber bestimmen können (Zeitzonen beachten!).

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

# Zielzeit (lokal/UTC bewusst wählen und dokumentieren)
STOP_TIME="2026-07-28 10:15:00"

# Beispiel: Binlogs aus zentralem Archiv in lokales Verzeichnis
BINLOG_DIR="/restore/binlogs"

# Verbindung zur wiederhergestellten Instanz
MYSQL_HOST="127.0.0.1"
MYSQL_PORT="3306"
MYSQL_USER="root"
MYSQL_PWD_FILE="/etc/mysql/root.pwd"

apply_binlogs() {
  local binlogs=("$@")
  mysqlbinlog --stop-datetime="$STOP_TIME" "${binlogs[@]}" 
    | mysql -h"$MYSQL_HOST" -P"$MYSQL_PORT" -u"$MYSQL_USER" --password="$(cat "$MYSQL_PWD_FILE")"
}

# Beispiel: Alle Binlogs in zeitlicher Reihenfolge anwenden
mapfile -t FILES < <(ls -1 "$BINLOG_DIR"/mysql-bin.* | sort)
apply_binlogs "${FILES[@]}"

Typische Stolperfallen im PITR:

• Zeitzone/Clock-Drift: Ereigniszeiten in Binlogs und Ihre „Incident-Zeit“ müssen zusammenpassen. NTP (Zeit-Synchronisation) ist hier nicht „nice to have“.
• Unvollständige Binlog-Kette: Fehlt ein Segment, gibt es Lücken. Darum: Binlogs kontinuierlich sichern und regelmäßig Vollständigkeit prüfen.
• GTID vs. Datei/Position: Wenn GTID (Global Transaction ID) genutzt wird, ist PITR/Failover oft einfacher, aber nur, wenn konsistent konfiguriert und verstanden. Ohne GTID bleiben Datei/Position.
• Row-Events und große Transaktionen: Sehr große Transaktionen können das Einspielen verlängern. Das wirkt direkt auf Ihr RTO.

Welche Kombination ist „richtig“? Entscheidungshilfe nach Betriebszielen

In der Praxis werden die Bausteine kombiniert, nicht gegeneinander ausgespielt. Eine pragmatische Entscheidungshilfe:

• LVM-Snapshot + Dateisicherung: Gut für sehr schnelle lokale Sicherungspunkte, wenn Storage-Layout sauber ist und Schreiblast planbar bleibt. Risiko: Snapshot-Füllung und inkonsistente Pfade.
• XtraBackup (Full/Inkrementell): Gut als Standard-Backup für große InnoDB-Datenbanken ohne Downtime. Risiko: Versions-/Kompatibilitätsmanagement und Restore-Ketten bei Inkrementen.
• PITR über Binlogs: Pflicht, wenn Sie enge RPOs brauchen oder häufig „logische Fehler“ (Löschen, falscher Job, Deploy) abfangen müssen. Risiko: Binlog-Aufbewahrung und saubere Startpunkt-Dokumentation.

Eine robuste Standardarchitektur für viele Umgebungen ist: XtraBackup als Basis (z. B. täglich) plus Binlog-Sicherung (kontinuierlich/eng getaktet) für PITR. LVM-Snapshots können ergänzend sinnvoll sein, etwa als schneller lokaler „Pre-Change“-Snapshot vor Wartungsarbeiten, sofern die Snapshot-Risiken aktiv gemanagt werden.

Checkliste: Vor dem ersten „echten“ Betriebseinsatz

1) Inventar und Pfade

• Datadir, Binlog-Verzeichnis, Relay-Logs (bei Replikation), tmpdir, Konfig-Includes erfasst
• Verschlüsselungs-/Keyring-Dateien und Zertifikate identifiziert und in Backup-Plan enthalten
• Storage-Layout dokumentiert (LVM, RAID, SAN, Cloud-Volumes), inklusive Abhängigkeiten

2) Backup-Jobs und Retention

• Backup-Fenster, I/O-Limits und Prioritäten definiert (damit Produktion nicht „wegbricht“)
• Retention (Aufbewahrung) für Full/Ink und Binlogs abgestimmt auf RPO/RTO und Compliance
• Speicherplatz-Guards: Vorab-Checks, Warnschwellen, sauberes Aufräumen alter Stände

3) Validierung und Restore-Proben

• Automatisierte Restore-Probe (z. B. wöchentlich) auf isoliertem System
• Erfolgskriterien: DB startet, Applikation kann lesen/schreiben, kritische Queries plausibel
• Messpunkte: Dauer von Restore und Binlog-Replay (RTO real messen, nicht schätzen)

Rückfallstrategie: Wenn der Restore nicht wie geplant klappt

Auch gute Backups scheitern in der Praxis manchmal am Umfeld: falsche Version, fehlende Binlogs, zu wenig Platz, nicht dokumentierte Parameter. Eine Rückfallstrategie bedeutet nicht „aufgeben“, sondern alternative Wege vorbereiten:

• Parallel-Restore statt In-Place: Wiederherstellung auf separatem Host/VM, dann kontrollierter Cutover. Das reduziert Risiko und erleichtert Analyse.
• Letztes sicher startfähiges Backup: Wenn PITR scheitert, definieren Sie, welches Backup garantiert startfähig ist (Prepared XtraBackup, geprüftes LVM-Backup).
• Binlog-Replay in Etappen: Wenn das Replay an einer Stelle knallt (z. B. durch inkonsistente DDL), arbeiten Sie mit klaren Stopps, Logs und einem reproduzierbaren Verfahren, statt „trial and error“.
• Runbook und Entscheidungszeitpunkte: Legen Sie fest, wann Sie von Plan A (PITR) auf Plan B (letztes Full) wechseln, um RTO nicht zu reißen.

Sicherheits- und Betriebsaspekte, die oft vergessen werden

Zugänge und Secrets

Backup-User brauchen minimale Rechte. Passwörter gehören nicht in Skripte. Nutzen Sie Datei-Rechte (root-only), Secret-Stores oder dedizierte Credential-Mechanismen. Protokollieren Sie nicht versehentlich Passwörter in Logs (z. B. durch set -x).

Ransomware-Resilienz

Backups sind ein Ziel. Trennen Sie Backup-Ziele logisch und möglichst auch organisatorisch (separate Credentials, Write-once/immutable Optionen, Offline-Kopien). Ein PITR nützt wenig, wenn Binlogs und Backups gemeinsam verschlüsselt wurden.

Versionierung und Migrationsfähigkeit

Planen Sie, wie ein Restore auf neuerer Hardware oder in einer neuen Umgebung funktioniert: Pfade, systemd Units, Paketversionen, Kernel/Filesystem. Gerade bei MariaDB/MySQL unterscheiden sich Default-Parameter über Versionen. Dokumentieren Sie die exakten Versionen von DB und Backup-Tool pro Sicherungslauf.

Fazit: Backups sind erst dann „gut“, wenn PITR und Restore-Probe durch sind

Ein verlässliches Backup für MySQL/MariaDB besteht aus mehr als einem nächtlichen Job. LVM-Snapshots liefern sehr schnelle, lokale Sicherungspunkte, müssen aber wegen Snapshot-Füllung, I/O-Overhead und Pfad-Konsistenz aktiv gemanagt werden. Percona XtraBackup ist für viele InnoDB-lastige Umgebungen der stabile Standard für Hot-Backups – vorausgesetzt, Prepare-Phase, Versionen und Rechte sind sauber im Griff. Den entscheidenden Sprung beim RPO macht der Point-in-Time-Restore über Binlogs: Er fängt die typischen „logischen Fehler“ ab, die in der Praxis häufiger sind als Storage-Defekte.

Wenn Sie nur eine Sache priorisieren: Automatisieren Sie eine regelmäßige Restore-Probe (inklusive Binlog-Replay bis zu einem Testzeitpunkt) und messen Sie RTO/RPO mit realen Laufzeiten. Erst damit wird aus „wir haben Backups“ ein belastbarer Wiederanlaufpfad.

Für dieses Thema sind auch Lvm Snapshot MySQL und Percona Xtrabackup Mariadb wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.