Block-Level-Replikation vs. File-Level-Backup: Entscheidungshilfe bei heterogener Infrastruktur

In heterogenen Infrastrukturen prallen im Backup- und DR-Alltag (Disaster Recovery, also Wiederanlauf nach schwerem Ausfall) oft zwei Welten aufeinander: Block-Level-Replikation und File-Level-Backup. Beide klingen nach „Daten sind sicher“ – lösen aber unterschiedliche Probleme. Wer Block-Level-Replikation vs. File-Level-Backup sauber bewertet, vermeidet typische Fehlannahmen wie „Replikation ist ein Backup“ oder „Dateibackup reicht auch für Datenbanken“. Dieser Beitrag liefert eine Entscheidungshilfe für Administratoren, System Engineers und IT-Dienstleister: mit Voraussetzungen, Risiken, Prüfschritten, Umsetzung und einer realistischen Rückfallstrategie – inklusive MariaDB-spezifischer Stolperfallen.

Begriffe sauber trennen: Was wird eigentlich geschützt?

Block-Level-Replikation repliziert Speicherblöcke (z. B. auf SAN-, iSCSI- oder Storage-Array-Ebene) von einem Quellsystem auf ein Ziel. Sie arbeitet unterhalb des Dateisystems: dem Replikationsmechanismus ist egal, ob der Block zu einer VM-Disk, einem MariaDB-Datenfile oder einer Logdatei gehört. Vorteil: sehr schnelle Spiegelung ganzer Volumes, oft mit kurzen RPOs (Recovery Point Objective = maximaler Datenverlust in Zeit) und schnellen RTOs (Recovery Time Objective = Zeit bis zur Wiederaufnahme des Betriebs).

File-Level-Backup sichert Dateien und Verzeichnisstrukturen (z. B. über Agenten, SMB/NFS, rsync oder Backup-Software), oft mit Versionierung und Aufbewahrung (Retention). Vorteil: gezielte Wiederherstellung einzelner Dateien, bessere Kontrolle über Versionen und häufig bessere Integration in Immutable-/Air-Gap-Konzepte (Schutz gegen nachträgliche Manipulation).

Wichtig: Beide Ansätze können Snapshots nutzen. Ein Snapshot ist ein Zeitpunktabbild (meist Copy-on-Write) eines Volumes oder Dateisystems. Snapshots sind kein Ersatz für Backups, wenn sie auf dem gleichen Storage liegen oder durch denselben Angriff kompromittiert werden können.

Warum Replikation nicht automatisch ein Backup ist

Die Kernfrage ist nicht, ob Daten irgendwo „zweimal vorhanden“ sind, sondern ob Sie zu einem definierten Zeitpunkt verlässlich zurück können. Replikation repliziert auch Fehler: versehentliches Löschen, Verschlüsselung durch Ransomware, logische Datenkorruption oder ein fehlerhaftes Deployment werden zuverlässig und schnell auf das Ziel übertragen. Das ist für Hochverfügbarkeit (HA) hilfreich, aber für Wiederherstellung oft fatal.

Ein File-Level-Backup mit Versionen kann in vielen Fällen genau hier punkten: Sie können vor den Schaden zurückspringen, auch wenn der Schaden „sauber“ repliziert wurde. Der Preis: Backups sind oft langsamer im Restore kompletter Systeme, und Konsistenz ist bei Datenbanken ohne passenden Mechanismus nicht garantiert.

Entscheidung nach Zielbild: HA, DR, Archiv, Compliance

In der Praxis hilft eine einfache Zuordnung, bevor man Tools diskutiert:

• Hochverfügbarkeit (HA): Ziel ist minimale Ausfallzeit. Block-Level-Replikation oder Cluster-Mechanismen sind hier stark, weil sie schnelle Umschaltung ermöglichen.
• Disaster Recovery (DR): Ziel ist Wiederanlauf nach Standort-/Storage-Ausfall. Replikation ist sinnvoll, aber nur, wenn ein „sauberer“ Konsistenzpunkt und eine Rücksprungmöglichkeit existieren.
• Backup/Restore: Ziel ist Wiederherstellung auch nach logischen Fehlern oder Angriff. File-Level-Backup, Objekt-Repositorys, Immutable Storage und Offsite-Kopien sind hier zentral.
• Archiv/Retention/Compliance: Ziel ist lange Aufbewahrung, Nachvollziehbarkeit, Wiederauffindbarkeit. File-Level-Backups mit Index/Metadaten und getrennten Aufbewahrungspools sind meist geeigneter.

In heterogenen Umgebungen (Windows/Linux, VMs/Bare Metal, NAS/SAN, On-Prem/Cloud, unterschiedliche Applikationsstacks) ist fast immer eine Kombination sinnvoll: Replikation für schnelle Wiederanläufe bestimmter Systeme plus Backup für versionierte, auditierbare Restore-Pfade.

Block-Level-Replikation im Betrieb: Voraussetzungen und Stolperfallen

Block-Level-Replikation funktioniert dann gut, wenn Sie Infrastruktur- und Betriebsannahmen klar machen. Typische Voraussetzungen:

• Identität & Konsistenz: Das Ziel muss die replizierten Volumes in einem konsistenten Zustand übernehmen können. Ohne Applikations-Quiesce (kurzes „Einfrieren“ von Schreibzugriffen) riskieren Sie inkonsistente Dateisysteme oder Datenbanken.
• Netz & Latenz: Replikation ist I/O-getrieben. Bandbreite, RTT (Round-Trip-Time) und Paketverlust entscheiden über RPO und Stabilität. Asynchrone Replikation toleriert Latenz, synchrone ist empfindlich und kann Write-Latenzen erhöhen.
• Split-Brain-Schutz: Bei Fehlern dürfen nicht beide Seiten „aktiv“ schreiben. Split-Brain (zwei aktive Primärseiten) führt fast immer zu Datenverlust oder schwierigen Merge-Szenarien.
• Orchestrierung: Failover ist nicht nur „Volume mounten“. DNS, IPs, Load Balancer, Secrets, Zertifikate, Applikationsstarts, Abhängigkeiten (z. B. AD, NTP, Monitoring) müssen als Runbook oder Automation vorhanden sein.

Typische Stolperfallen in heterogener Infrastruktur:

• Reihenfolgefehler: VM-Datastores werden umgeschaltet, aber Datenbank und Applikationsserver starten in falscher Reihenfolge. Ergebnis: lange Recovery, inkonsistente Zustände.
• Hidden Dependencies: Ein Lizenzserver, ein internes PKI-Endpoint oder ein zentraler Syslog-Collector fehlt im DR-Segment – und Anwendungen blockieren beim Start.
• Snapshot-Ketten: Storage-Snapshots in Kombination mit Replikation können zu langen „Ketten“ führen; das erschwert Rollbacks und erhöht I/O-Overhead.
• Replikation ohne Retention: Es gibt kein „Zurück zu gestern 02:00“. Dann ist Replikation nur ein schnellerer Weg in den falschen Zustand.

Prüfschritte für Replikation (Preflight)

Bevor Sie Replikation als DR-Pfad verkaufen (intern oder beim Kunden), sollten Sie mindestens diese Prüfpunkte abhaken:

• Konsistenzpunkt definiert: Wie stellen Sie Applikationskonsistenz her (z. B. DB flush, Filesystem freeze, VM-Snapshot mit Quiesce)?
• Failover-Runbook vorhanden: Wer macht was, in welcher Reihenfolge, mit welchen Checks?
• Rücksprung (Failback) geplant: Wie kommen Daten zurück, ohne Split-Brain oder lange Downtime?
• Isolationsfähigkeit: Können Sie im Incident die Replikation stoppen, um ein „sauberes“ Ziel zu bewahren?
• Testfenster: Gibt es regelmäßige Proben (mindestens partiell), nicht nur Papier?

File-Level-Backup im Betrieb: Stärken, Grenzen, typische Fehler

File-Level-Backup ist in heterogenen Umgebungen oft die realistischste Basisschicht, weil es plattformnah funktioniert: Windows-Server, Linux, NAS-Shares, Applikationsdaten, Konfigurationsverzeichnisse. Die großen Vorteile liegen in Versionierung, selektivem Restore und Aufbewahrung.

Die häufigsten Betriebsfehler sind weniger Tool- als Prozessprobleme:

• Offene Dateien und Locks: Ohne VSS (Volume Shadow Copy Service, Windows-Snapshot-Dienst) oder vergleichbare Mechanismen werden Dateien „im Schreiben“ gesichert. Das kann unbrauchbar sein.
• ACLs und Metadaten: NTFS-ACLs, POSIX-Rechte, xattrs (Extended Attributes) oder SMB-Ownership gehen verloren, wenn das Backup nicht metadatenfähig ist. Restore sieht dann „richtig aus“, aber Berechtigungen sind kaputt.
• Zu große Restore-Domänen: Ein einzelner Job sichert „alles“. Im Ernstfall dauert der Restore zu lange, weil Priorisierung und Parallelisierung fehlen.
• Kein Restore-Test: Backups gelten als „grün“, aber niemand hat je geprüft, ob ein konsistenter Restore funktioniert.

Praxisregel: Backups müssen das Restore-Ziel abbilden

Wer schnelle Systemwiederherstellung braucht, sollte File-Level-Backups mit Image-/VM-Backups kombinieren. Wer einzelne Dateien schnell benötigt (z. B. versehentlich gelöschte Vertrags-PDFs), braucht Versionierung und Such/Index. Wer Ransomware fürchtet, braucht Immutable- und Offsite-Kopien sowie getrennte Credentials.

MariaDB im Fokus: Warum Datenbank-Konsistenz die Entscheidung kippen kann

In der Kategorie MariaDB entscheidet nicht selten die Frage: „Wie bekomme ich einen konsistenten Zustand zurück – und wie weit kann ich in der Zeit zurück?“ MariaDB ist MySQL-kompatibel, nutzt typischerweise InnoDB (Storage Engine mit Transaktionslog). Bei Datenbanken ist ein File-Copy ohne koordinierte Schritte riskant: Sie sichern sonst Datenfiles und Logs in einem Zwischenzustand.

Replikation auf Blockebene kann für MariaDB funktionieren, wenn Sie applikationskonsistente Snapshots erzeugen (also Schreibvorgänge kurz kontrolliert anhalten/flushen) und den Snapshot replizieren. File-Level-Backup kann funktionieren, wenn es datenbankaware ist (z. B. logische Dumps für kleine DBs oder physische Backups mit geeignetem Tool).

Typische MariaDB-Stolperfallen bei Block-Level-Replikation

• Crash-konsistent ist nicht gleich applikationskonsistent: Ein crash-konsistenter Snapshot entspricht einem „Stromausfall“. InnoDB kann vieles recovern, aber nicht jedes Szenario ist sauber, und Recovery-Zeiten sind schwer planbar.
• Binary Logs (Binlog): Für Point-in-Time-Recovery (PITR) brauchen Sie Binlogs. Replikation allein liefert keinen „zurück zu 10:17 Uhr“, wenn 10:20 Uhr bereits verschlüsselt repliziert wurde.
• Version/Migration: Ein MariaDB-Upgrade oder eine Schema-Migration, die logisch falsch ist, wird repliziert. Ohne versionsfähiges Backup kein sauberer Rücksprung.

Typische MariaDB-Stolperfallen bei File-Level-Backups

• „Einfach /var/lib/mysql kopieren“: Das ist im laufenden Betrieb häufig inkonsistent. Selbst wenn es manchmal „geht“, ist es kein belastbares Verfahren.
• Fehlende Binlogs: Ohne Binlogs bleibt nur „Restore auf Snapshot-Zeitpunkt“. PITR fällt aus, RPO wird gröber.
• Restore-Probe fehlt: Ein Backup ist erst dann gut, wenn ein Restore auf Testinstanz inklusive Start, Checks und Anwendungsabfrage reproduzierbar klappt.

Entscheidungsmatrix: Wann welches Verfahren (oder beides)?

Für den Alltag hilft eine pragmatische Matrix. Keine Theorie, sondern Betriebslogik:

• Sehr kleines RTO (Minuten): Block-Level-Replikation oder VM-Replikation + Orchestrierung. File-Level allein ist meist zu langsam für vollständige Systemwiederherstellung.
• Sehr kleines RPO (Sekunden bis wenige Minuten): Replikation ist stark, aber nur sinnvoll mit zusätzlichem „Zeitpuffer“ (Snapshot-Retention) oder separatem Backup, sonst replizieren Sie den Schaden.
• Viele kleine Restore-Fälle (User-Files): File-Level-Backup mit Versionierung, Index und sauberem Berechtigungsrestore (ACLs/xattrs).
• Ransomware-Bedrohung hoch: File-Level/Repository-Backups mit Immutable Storage, getrennten Accounts und Offline-/Offsite-Kopie. Replikation kann ergänzen, ist aber kein Schutz, wenn sie ungebremst mitverschlüsselt.
• Heterogen, viele Plattformen: File-Level als Basisschicht; Replikation gezielt für wenige kritische Workloads (z. B. zentrale Datenbank-VMs) und nur mit Test- und Rollback-Konzept.
• MariaDB mit PITR-Anforderung: Physisches Backup + Binlogs (PITR) oder ein anderes transaktionslogbasiertes Verfahren. Replikation kann den Grundzustand liefern, ersetzt aber die Zeitreise nicht.

Umsetzung in der Praxis: Kontrollpunkte, die Sie dokumentieren sollten

Unabhängig vom Produkt sind folgende Artefakte entscheidend. Wenn sie fehlen, ist die Lösung im Ernstfall oft nicht reproduzierbar:

• Systeminventar: Welche Volumes/Shares enthalten welche Daten (Applikation, DB, Logs, Uploads, Konfig)?
• Schutzklasse je Workload: Ziel-RPO/RTO, Aufbewahrung, Verschlüsselung, Offsite.
• Abhängigkeiten: DNS, Identität (AD/LDAP), NTP, Zertifikate, Secrets, Monitoring, zentrale Storage-/Netzpfade.
• Runbooks: Failover, Restore, Failback, Stop-the-Bleed (Replikation anhalten), Kommunikations- und Freigabepunkte.

Checkliste: Minimaler Restore-Test (technisch belastbar)

Ein Restore-Test muss nicht gleich eine Vollübung sein, aber er braucht klare Erfolgskriterien:

• Integrität: Prüfsummen/Hash oder stichprobenartige Dateivergleiche (bei File-Level).
• Boot/Start: VM/Host startet, Dienste laufen, Logs sind plausibel.
• Applikationscheck: Für MariaDB z. B. Verbindungsaufbau, einfache Queries, Tabellenkonsistenz.
• Zeit: Gemessene Restore-Zeit (real, nicht geschätzt).
• Dokumentation: Was war anders als erwartet? Welche Abhängigkeit fehlte?

MariaDB-How-to: Backup + Binlog-PITR als verlässliche Basisschicht

Für MariaDB ist ein bewährter Ansatz: regelmäßiges physisches Vollbackup plus kontinuierliche/regelmäßige Sicherung der Binlogs. Damit können Sie auf einen Vollbackup-Zeitpunkt zurück und dann bis kurz vor dem Fehler vorspulen (PITR). Als Tool wird in der Praxis häufig Percona XtraBackup verwendet (physisches Hot-Backup für InnoDB). Das ist kein „Framework-Interna“, sondern Betriebshandwerk: konsistente Sicherung, planbare Restore-Schritte.

Beispielhafte Ablaufskizze (Linux, generisch; Pfade/Benutzer anpassen). Das zeigt bewusst die Struktur – produktiv müssen Sie Credentials sicher ablegen (z. B. in root-only config, Vault, oder Backup-Agent-Secrets) und Rechte sauber setzen.

1) Vollbackup mit XtraBackup (physisch, konsistent)

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

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

mkdir -p "$TARGET"

# Hinweis: Zugangsdaten nicht im Klartext im Skript lassen.
# Nutzen Sie z. B. eine geschützte my.cnf unter /root/.my.cnf

xtrabackup --backup --target-dir="$TARGET"

# Prepare-Schritt macht das Backup restorefähig (Redo-Logs anwenden)
xtrabackup --prepare --target-dir="$TARGET"

# Optional: Integritätsmarker
echo "$TS" > "$TARGET/backup.completed"

2) Binlogs sichern (Grundlage für Point-in-Time-Recovery)

Damit PITR funktioniert, müssen Binlogs aktiviert sein und regelmäßig in ein separates, versioniertes Ziel kopiert werden. Binlogs sind die fortlaufenden Änderungsprotokolle (Transaktions-/Statement-Log), mit denen Sie Änderungen nach einem Vollbackup wieder abspielen können.

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

BINLOG_DIR="/var/lib/mysql"
ARCHIVE_DIR="/backup/mariadb/binlogs"

mkdir -p "$ARCHIVE_DIR"

# Alle aktuellen Binlogs auflisten
mysql -N -e "SHOW BINARY LOGS;" | awk '{print $1}' | while read -r f; do
  src="$BINLOG_DIR/$f"
  if [[ -f "$src" ]]; then
    # Kopie mit Metadaten, aber ohne Überschreiben (Versionierung im Repo wäre noch besser)
    cp -n "$src" "$ARCHIVE_DIR/" || true
  fi
done

# Optional: Binlog-Rotation anstoßen (damit ein „abgeschlossener“ Log zum Archiv wandert)
mysql -e "FLUSH BINARY LOGS;"

3) Restore + PITR (Konzept und Prüfschritte)

Ein PITR ist nur so gut wie Ihr Test. Beim Restore spielen Sie erst das Vollbackup ein, starten MariaDB in kontrollierter Umgebung und spielen dann Binlogs bis zu einem definierten Zeitpunkt oder bis vor eine bestimmte Position ab. Typische Prüfschritte: Start ohne Crash-Recovery-Schleifen, Plausibilitätschecks in den Applikationsdaten, Abgleich der erwarteten letzten Transaktion.

Wichtig für die Entscheidung „Replikation vs. Backup“: Diese Zeitreise bekommen Sie mit reiner Block-Replikation nur dann, wenn Sie auf der Replikationsseite ebenfalls eine Versionierung/Retention von Snapshots haben und im Incident schnell genug isolieren. In der Praxis ist ein getrenntes Backup-Repository häufig die robustere Basisschicht.

Ransomware-Realität: Was in beiden Modellen schiefgeht

Ransomware ist kein Spezialfall mehr, sondern ein Designkriterium. Für beide Ansätze gilt:

• Replikation: Verschlüsselte Daten replizieren schnell. Ohne verzögerte Replikation, Snapshot-Retention am Ziel und einen „Stop“-Prozess im Incident kann das DR-Ziel unbrauchbar werden.
• File-Level-Backup: Backups können gelöscht oder verschlüsselt werden, wenn Angreifer Zugriff auf Backup-Credentials oder das Repository haben. Immutable Storage (WORM/Unveränderlichkeit), getrennte Accounts und Offline-/Offsite-Kopien sind entscheidend.

Ein praxistaugliches Muster ist: Replikation für Verfügbarkeit, Backup für Wiederherstellbarkeit. Dazu ein Incident-Runbook „Stop-the-bleed“: Replikation anhalten, Backup-Jobs stoppen, Credentials rotieren, Forensikfenster schaffen, dann gezielt aus einem sauberen Zeitpunkt wiederherstellen.

Rückfallstrategie: Was tun, wenn der geplante Pfad scheitert?

Rückfallstrategie heißt: Sie planen den Moment ein, in dem ein Restore fehlschlägt oder ein Failover unerwartete Abhängigkeiten offenlegt. Ein belastbarer Plan hat Stufen:

• Stufe 1: Wiederanlauf auf repliziertem Stand (schnell, aber Risiko logischer Fehler bleibt).
• Stufe 2: Rollback auf Ziel-Snapshot (wenn Retention vorhanden und Snapshot vor dem Incident liegt).
• Stufe 3: Restore aus Backup-Repository (versioniert/immutable, unabhängig vom replizierten Storage).
• Stufe 4: Teilrestore (z. B. MariaDB aus PITR, Files aus Versionen, Applikationsserver neu aus Template/IaC).

Damit das nicht theoretisch bleibt, definieren Sie vorab: Wer entscheidet die Stufe, welche Datenpriorität gilt (z. B. erst MariaDB, dann Uploads, dann Reporting), und welche maximale Downtime akzeptabel ist. Gerade in gemischten Umgebungen ist ein „alles oder nichts“-Restore selten optimal.

Empfehlung für heterogene Infrastruktur: Ein pragmatischer Zielaufbau

Wenn Sie heute neu strukturieren oder ein bestehendes Setup konsolidieren, ist dieses Zielbild in der Praxis gut betreibbar:

• Basisschicht: File-Level-/Repository-Backup mit Versionierung, klarer Retention und Offsite-Kopie (3-2-1 als Leitlinie: 3 Kopien, 2 Medien, 1 Offsite).
• Für kritische Systeme: Block-Level-Replikation (oder VM-Replikation) mit definierter Konsistenzmethode und Snapshot-Retention am Ziel.
• Für MariaDB: Physisches Vollbackup + Binlog-Archivierung für PITR, plus regelmäßige Restore-Proben auf Testinstanz.
• Betrieb: Monitoring/Alerting auf Job-Erfolg, Dauer, Datenmenge, Repository-Füllstand und Restore-Tests – nicht nur „Job grün“.

Das nimmt Druck aus DR-Tests: Sie müssen nicht jedes System vollständig aus dem Backup neu aufbauen, wenn Replikation das schnelle Weiterarbeiten ermöglicht. Gleichzeitig bleiben Sie in der Lage, auf einen sauberen Zeitpunkt zurückzugehen, wenn der logische Schaden bereits repliziert ist.

Fazit: Block-Level-Replikation vs. File-Level-Backup ist keine Glaubensfrage

Die Entscheidung Block-Level-Replikation vs. File-Level-Backup wird in heterogener Infrastruktur am besten über Betriebsziele getroffen: Replikation ist ein starker Hebel für kurze RTOs und schnelle Failover, aber ohne Versionierung und Isolationsfähigkeit replizieren Sie auch den Schaden. File-Level-Backups liefern Versionen, selektive Restores und bessere Retention – scheitern aber, wenn Konsistenz (insbesondere bei MariaDB) und Restore-Tests nicht ernst genommen werden.

Wenn Sie nur eine praktische Leitlinie mitnehmen: Replikation für Verfügbarkeit, Backups für Wiederherstellbarkeit – und beides regelmäßig testen, mit einem klaren „Stop-the-bleed“-Runbook und einer abgestuften Rückfallstrategie.

Für dieses Thema sind auch Immutable Backup und Ransomware-Schutz wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.