Backup-Strategie und Disaster Recovery für Magento 2

1. Backup und Disaster Recovery: zwei Disziplinen, RTO und RPO

Viele Teams behandeln Backup-Strategie und Disaster Recovery als ein und dasselbe Thema, dabei sind es zwei unterschiedliche Disziplinen mit unterschiedlichen Zielen. Ein Backup ist eine technische Kopie von Daten zu einem Zeitpunkt. Disaster Recovery ist der organisatorische und technische Prozess, der aus dieser Kopie in möglichst kurzer Zeit wieder einen funktionierenden Shop macht. Wer nur Backups zieht, aber keinen definierten Wiederherstellungsprozess hat, besitzt im Ernstfall eine Sammlung von Dateien, aber keinen Plan. Genau hier setzen die zwei Steuerungsgrößen an, die jede belastbare Backup-Strategie und Disaster Recovery gemeinsam brauchen: Recovery Time Objective (RTO) und Recovery Point Objective (RPO).

Der RTO beantwortet die Frage, wie lange der Shop nach einem Vorfall maximal offline sein darf, bevor der Geschäftsschaden inakzeptabel wird. Bei einem Magento-Shop mit sechsstelligem Tagesumsatz ist ein RTO von vier Stunden etwas völlig anderes als ein RTO von 24 Stunden, und die technische Architektur dahinter unterscheidet sich massiv: warme Standby-Instanz gegen kalten Restore aus dem Objektspeicher. Der RPO beantwortet die Frage, wie viel Datenverlust im schlimmsten Fall akzeptabel ist, gemessen in Zeit seit dem letzten konsistenten Backup. Ein RPO von 15 Minuten erfordert Transaktionslog-basierte Backups oder Replikation, ein RPO von 24 Stunden reicht mit einem nächtlichen mysqldump aus.

Beide Werte müssen mit dem Fachbereich verhandelt werden, nicht allein von der IT festgelegt werden. Eine Backup-Strategie und Disaster Recovery ohne dokumentierte RTO- und RPO-Werte pro System ist Kaffeesatzleserei: Niemand weiß, ob die aktuelle nächtliche Sicherung überhaupt zu den Geschäftsanforderungen passt. Für einen Magento-2-Shop bedeutet das konkret, RTO und RPO getrennt für die Datenbank, für pub/media und für die Anwendungslogik in app/code zu definieren, weil sich diese drei Komponenten in Änderungsfrequenz und Kritikalität stark unterscheiden.

2. Datenbank-Backups im Vergleich: mysqldump, XtraBackup, mydumper

Die Wahl des Datenbank-Backup-Werkzeugs ist die wichtigste Einzelentscheidung innerhalb der Backup-Strategie, weil sie direkt bestimmt, wie stark ein Backup den Live-Betrieb beeinträchtigt. mysqldump ist das Standardwerkzeug, logisch, einfach zu verstehen und überall verfügbar, erzeugt aber bei großen Magento-Datenbanken mit mehreren Gigabyte an sales_order- und catalog_product_entity-Tabellen spürbare Last. Ohne --single-transaction hält mysqldump bei InnoDB-Tabellen implizit Sperren, die parallele Schreibzugriffe blockieren können. Mit --single-transaction nutzt MySQL stattdessen einen konsistenten Snapshot über MVCC, wodurch Schreibvorgänge während des Dumps weiterlaufen können, solange keine DDL-Anweisungen dazwischenkommen.

Percona XtraBackup löst das Problem grundlegend anders: Es kopiert die physischen InnoDB-Datendateien direkt vom Dateisystem und wendet anschließend das Transaktionslog an, um einen konsistenten Zustand herzustellen, praktisch ohne Locking und ohne spürbare Last auf der laufenden Instanz. Für Magento-Datenbanken jenseits von 10 bis 20 Gigabyte ist XtraBackup in der Praxis die einzige Option, die sowohl schnell als auch für den Live-Betrieb unkritisch ist. Der Nachteil: Ein XtraBackup-Restore erfordert denselben MySQL-Major-Release und ist an die physische Dateistruktur gebunden, während ein mysqldump-Export portabel zwischen Versionen und sogar zwischen MySQL und MariaDB funktioniert.

mydumper nimmt eine Mittelposition ein: Es erzeugt wie mysqldump logische, portable Dumps, parallelisiert die Ausgabe aber über mehrere Threads pro Tabelle und ist dadurch bei großen Magento-Datenbanken deutlich schneller als das Single-Thread-Original. Für die tägliche Backup-Strategie und Disaster Recovery empfiehlt sich häufig eine Kombination: XtraBackup für die schnelle, lastarme tägliche Vollsicherung, ergänzt um einen wöchentlichen logischen Dump mit mydumper oder mysqldump für maximale Portabilität, etwa bei einem Wechsel des Datenbank-Providers.

3. Medien- und Dateisystem-Backups: pub/media und var-Verzeichnis

Ein rein datenbankzentrierter Blick auf die Backup-Strategie übersieht einen kritischen Teil eines Magento-Shops: das Dateisystem. Das Verzeichnis pub/media enthält Produktbilder, Kategorie-Assets und häufig auch hochgeladene Kundendateien, deren Referenzen fest in der Datenbank verankert sind, etwa in catalog_product_entity_media_gallery. Geht pub/media verloren, während die Datenbank intakt bleibt, zeigt der Shop technisch korrekt an, verliert aber sämtliche Produktbilder, was für einen Onlineshop einem faktischen Totalausfall gleichkommt. Medien-Backups gehören deshalb genauso zwingend zur Disaster Recovery wie die Datenbanksicherung.

Das var-Verzeichnis dagegen enthält größtenteils regenerierbare Inhalte wie Cache, Session-Daten und kompilierten Code und muss in der Regel nicht gesichert werden, mit einer wichtigen Ausnahme: var/log, sofern Audit-Anforderungen oder eine laufende Incident-Analyse eine Historie der Exception- und System-Logs verlangen. Die Trennung zwischen sicherungspflichtigen und regenerierbaren Verzeichnissen reduziert das Backup-Volumen erheblich und beschleunigt sowohl die tägliche Sicherung als auch einen späteren Restore, weil weniger Daten bewegt werden müssen.

Der kritischste Punkt bei Medien-Backups ist die Konsistenz zwischen DB-Stand und Media-Stand. Wird die Datenbank um 2 Uhr gesichert und pub/media erst um 4 Uhr, können in der Zwischenzeit hochgeladene Bilder in der Datenbank referenziert sein, aber im Medien-Backup fehlen, oder umgekehrt Dateien existieren, auf die kein Datenbankeintrag mehr zeigt. Die Lösung ist, beide Backups im selben Lauf und möglichst eng getaktet zu starten, idealerweise die Datenbanksicherung unmittelbar vor oder nach dem tar-Archiv von pub/media, sodass das Zeitfenster für Inkonsistenzen minimal bleibt.

#!/usr/bin/env bash
# backup.sh: Full production backup, database, media, upload to S3, rotation
set -euo pipefail
IFS=$'\n\t'

readonly TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
readonly BACKUP_DIR="/var/backups/magento"
readonly S3_BUCKET="s3://mironsoft-backups/shop-prod"
readonly RETENTION_DAYS=14
readonly LOG_FILE="/var/log/backup/${TIMESTAMP}.log"

exec > >(tee -a "$LOG_FILE") 2>&1

log() { echo "[$(date +%H:%M:%S)] $1"; }

mkdir -p "$BACKUP_DIR"

# 1. Database backup via Percona XtraBackup (near lock-free)
log "Starting XtraBackup..."
xtrabackup --backup \
  --target-dir="${BACKUP_DIR}/db-${TIMESTAMP}" \
  --user=backup_user --password="${MYSQL_BACKUP_PASSWORD}" \
  --compress --compress-threads=4

xtrabackup --prepare --target-dir="${BACKUP_DIR}/db-${TIMESTAMP}"
tar -czf "${BACKUP_DIR}/db-${TIMESTAMP}.tar.gz" -C "${BACKUP_DIR}" "db-${TIMESTAMP}"
rm -rf "${BACKUP_DIR}/db-${TIMESTAMP}"

# 2. Media and filesystem backup, consistent time window with the DB dump
log "Archiving pub/media..."
tar -czf "${BACKUP_DIR}/media-${TIMESTAMP}.tar.gz" -C /var/www/html pub/media

# 3. Checksums for integrity verification on restore
sha256sum "${BACKUP_DIR}/db-${TIMESTAMP}.tar.gz" > "${BACKUP_DIR}/db-${TIMESTAMP}.sha256"
sha256sum "${BACKUP_DIR}/media-${TIMESTAMP}.tar.gz" > "${BACKUP_DIR}/media-${TIMESTAMP}.sha256"

# 4. Upload to S3-compatible offsite storage, server-side encryption enabled
log "Uploading to offsite storage..."
aws s3 cp "${BACKUP_DIR}/db-${TIMESTAMP}.tar.gz" "${S3_BUCKET}/db/" --sse aws:kms
aws s3 cp "${BACKUP_DIR}/media-${TIMESTAMP}.tar.gz" "${S3_BUCKET}/media/" --sse aws:kms
aws s3 cp "${BACKUP_DIR}/db-${TIMESTAMP}.sha256" "${S3_BUCKET}/db/"
aws s3 cp "${BACKUP_DIR}/media-${TIMESTAMP}.sha256" "${S3_BUCKET}/media/"

# 5. Local rotation: keep RETENTION_DAYS days on disk, S3 lifecycle handles offsite retention
log "Applying local retention policy (${RETENTION_DAYS} days)..."
find "$BACKUP_DIR" -type f -mtime +"$RETENTION_DAYS" -delete

log "Backup completed successfully: ${TIMESTAMP}"

4. Die 3-2-1-Backup-Regel und Offsite-Storage

Die 3-2-1-Regel ist der bewährte Rahmen, in dem jede robuste Backup-Strategie und Disaster Recovery gedacht werden sollte: mindestens drei Kopien der Daten, auf mindestens zwei unterschiedlichen Speichermedien, davon mindestens eine Kopie an einem anderen physischen Standort. Für einen Magento-Shop bedeutet das konkret: die Produktivdatenbank selbst, eine lokale Sicherung auf dem Applikationsserver oder einem separaten Backup-Host, und eine dritte Kopie in einem Object Storage außerhalb des primären Rechenzentrums, etwa bei einem anderen Cloud-Provider oder einer anderen Region desselben Providers.

Der Grund für das Offsite-Erfordernis liegt in der Risikokorrelation: Ein Server-Ausfall, ein Ransomware-Angriff mit lateraler Bewegung im Netzwerk oder ein komplettes Rechenzentrums-Ereignis betreffen Backups, die auf demselben System oder im selben Netzwerksegment liegen, mit hoher Wahrscheinlichkeit gleichzeitig mit den Produktivdaten. Object Storage wie S3-kompatible Dienste eignet sich besonders gut als dritte Kopie, weil er über eine eigene Zugriffsebene verfügt, unabhängig vom Produktivnetzwerk erreichbar ist und mit Versionierung sowie Object Lock zusätzlich vor nachträglicher Manipulation oder Löschung geschützt werden kann.

Verschlüsselung muss an zwei Stellen greifen: im Ruhezustand (at rest) und bei der Übertragung (in transit). Für den Transport reicht in der Regel TLS, wie es aws s3 cp und vergleichbare Tools ohnehin standardmäßig verwenden. Im Ruhezustand sollte serverseitige Verschlüsselung mit einem eigenen Schlüssel (SSE-KMS statt SSE-S3) aktiviert werden, damit selbst bei kompromittierten Zugangsdaten zum Storage-Bucket der Schlüsselzugriff separat kontrolliert bleibt. Wer zusätzlich clientseitig verschlüsselt, bevor das Archiv das Netzwerk verlässt, schützt sich sogar gegen einen kompromittierten Storage-Provider, muss dann aber das Schlüsselmanagement selbst zuverlässig betreiben, denn ein verlorener Schlüssel macht auch ein korrekt hochgeladenes Backup wertlos.

5. Automatisierung: Backup-Skript mit Rotation und Retention-Policy

Eine Backup-Strategie, die auf manuelles Anstoßen angewiesen ist, wird in der Praxis vergessen, verzögert oder inkonsistent ausgeführt. Automatisierung über cron ist der Mindeststandard, wobei die Job-Definition drei Dinge sicherstellen muss: einen definierten Ausführungszeitpunkt außerhalb der Spitzenlast, eine vollständige Protokollierung jedes Laufs, und eine Benachrichtigung bei Fehlschlägen, die nicht im Cron-Mail-Rauschen untergeht. Für Magento-Shops mit internationalem Kundenstamm gibt es selten ein echtes Nachtfenster ohne Traffic, weshalb XtraBackup gegenüber lockendem mysqldump hier einen echten betrieblichen Vorteil bringt.

Die Retention-Policy definiert, wie lange welche Backup-Generation aufbewahrt wird, und sollte gestaffelt sein: tägliche Backups für 14 Tage, wöchentliche Backups für 3 Monate, monatliche Backups für ein bis drei Jahre, je nach Compliance-Anforderungen. Eine reine "alles 14 Tage löschen"-Regel wie im einfachen Rotationsskript oben ist ein guter Einstieg, deckt aber nicht den Fall ab, in dem ein Datenproblem erst nach mehreren Wochen bemerkt wird und ein älterer Wiederherstellungspunkt gebraucht wird. Objektspeicher-Lifecycle-Regeln übernehmen die gestaffelte Retention oft eleganter als selbstgeschriebene Lösch-Logik im Backup-Skript, weil sie unabhängig vom Ausführungsstatus des Cron-Jobs greifen.

# /etc/cron.d/magento-backup
# Runs nightly backup at 02:15, logs stdout/stderr, mails only on failure
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@mironsoft.de

15 2 * * * deploy /usr/local/bin/backup.sh >> /var/log/backup/cron.log 2>&1 || echo "Backup FAILED at $(date)" | mail -s "[ALERT] Magento backup failed" ops@mironsoft.de

# Weekly logical dump for portability (Sunday 03:30)
30 3 * * 0 deploy /usr/local/bin/backup-weekly-dump.sh >> /var/log/backup/cron-weekly.log 2>&1

# Restore-drill reminder, first Monday of each month
0 9 1-7 * 1 deploy [ "$(date +\%u)" = "1" ] && mail -s "[REMINDER] Monatlicher Restore-Drill fällig" ops@mironsoft.de </dev/null

6. Restore-Prozess und regelmäßige Restore-Drills

Ein Backup, das nie zurückgespielt wurde, ist eine Hypothese, kein verlässlicher Baustein der Disaster Recovery. In der Praxis scheitern Restores erstaunlich oft an trivialen Ursachen: ein falsches Passwort im Skript, eine inkompatible MySQL-Version zwischen Backup-Quelle und Ziel, ein vergessenes Chown auf pub/media nach dem Entpacken, oder ein XtraBackup-Archiv, das nie mit --prepare vorbereitet wurde und deshalb inkonsistent ist. Jeder dieser Fehler bleibt unentdeckt, solange niemand den kompletten Restore-Prozess unter realistischen Bedingungen durchspielt.

Ein Restore-Drill ist der geplante, wiederholte Test genau dieses Prozesses, idealerweise monatlich und in einer isolierten Umgebung, die nicht die Produktion berührt. Der Ablauf: aktuellstes Backup aus dem Offsite-Storage herunterladen, Datenbank und Medien in eine frische Staging-Instanz einspielen, den Shop dort hochfahren und funktional prüfen, ob Bestellungen, Produktdaten und Kundendaten dem erwarteten Stand entsprechen. Die gemessene Dauer dieses Drills ist gleichzeitig der realistischste verfügbare Messwert für den tatsächlich erreichbaren RTO, oft ernüchternd höher als die auf dem Papier angenommene Zahl.

Für den Mark-Shust-Docker-Magento-Betrieb lässt sich der Restore-Drill vollständig in einer separaten Compose-Umgebung durchführen, ohne die produktive Instanz zu berühren, was das Risiko des Tests selbst auf nahezu null reduziert. Wichtig ist, den Drill zu dokumentieren: Startzeit, Dauer je Schritt, aufgetretene Probleme und deren Behebung. Diese Protokolle fließen direkt in das Disaster-Recovery-Runbook ein und machen aus einem einmaligen Test einen kontinuierlich verbesserten Prozess.

#!/usr/bin/env bash
# restore.sh: Pull latest backup from offsite storage and restore DB + media
set -euo pipefail
IFS=$'\n\t'

readonly S3_BUCKET="s3://mironsoft-backups/shop-prod"
readonly RESTORE_DIR="/tmp/magento-restore"
readonly TARGET_WEBROOT="/var/www/html"

mkdir -p "$RESTORE_DIR"

echo "[INFO] Fetching latest backup manifest..."
latest_db="$(aws s3 ls "${S3_BUCKET}/db/" | sort | tail -n 1 | awk '{print $4}')"
latest_media="$(aws s3 ls "${S3_BUCKET}/media/" | sort | tail -n 1 | awk '{print $4}')"

echo "[INFO] Downloading ${latest_db} and ${latest_media}..."
aws s3 cp "${S3_BUCKET}/db/${latest_db}" "${RESTORE_DIR}/"
aws s3 cp "${S3_BUCKET}/media/${latest_media}" "${RESTORE_DIR}/"

echo "[INFO] Verifying checksums..."
aws s3 cp "${S3_BUCKET}/db/${latest_db%.tar.gz}.sha256" "${RESTORE_DIR}/"
(cd "$RESTORE_DIR" && sha256sum -c "$(basename "${latest_db%.tar.gz}.sha256")")

echo "[INFO] Extracting and preparing database..."
tar -xzf "${RESTORE_DIR}/${latest_db}" -C "$RESTORE_DIR"
xtrabackup --decompress --target-dir="${RESTORE_DIR}/db"
xtrabackup --prepare --target-dir="${RESTORE_DIR}/db"

echo "[INFO] Stopping MySQL and swapping data directory..."
systemctl stop mysql
mv /var/lib/mysql "/var/lib/mysql.bak-$(date +%s)"
xtrabackup --copy-back --target-dir="${RESTORE_DIR}/db" --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

echo "[INFO] Restoring pub/media..."
tar -xzf "${RESTORE_DIR}/${latest_media}" -C "$TARGET_WEBROOT"
chown -R www-data:www-data "${TARGET_WEBROOT}/pub/media"

echo "[INFO] Restore complete. Run bin/magento cache:flush and functional checks now."

7. Das Disaster-Recovery-Runbook: Rollen, Eskalation und Kommunikation

Technik allein rettet keinen Vorfall, wenn niemand weiß, wer im Ernstfall was tut. Ein Disaster-Recovery-Runbook ist das dokumentierte Gegenstück zur technischen Backup-Strategie und Disaster Recovery: ein konkretes, schrittweises Dokument, das definiert, wer als Incident Commander den Vorfall leitet, wer die technische Wiederherstellung durchführt, und wer die Kommunikation nach innen und außen übernimmt. Ohne diese Rollenklärung entstehen im Ernstfall doppelte Arbeit, widersprüchliche Anweisungen und wertvoller Zeitverlust genau in dem Moment, in dem jede Minute zählt.

Die Eskalationskette muss konkrete Namen, Telefonnummern und Vertretungsregelungen enthalten, nicht nur abstrakte Rollen. Ein Runbook, das "der Systemadministrator wird informiert" schreibt, hilft nachts um drei Uhr niemandem, wenn unklar ist, welcher von drei Systemadministratoren gemeint ist und über welchen Kanal er erreichbar ist. Sinnvoll ist eine dreistufige Eskalation: Stufe 1 löst der diensthabende Techniker anhand des Runbooks selbst, Stufe 2 zieht einen Senior-Engineer hinzu, wenn die Lösung nach einer definierten Zeitspanne, etwa 30 Minuten, nicht greift, Stufe 3 informiert die Geschäftsführung, sobald absehbar ist, dass der definierte RTO überschritten wird.

Kommunikation im Ernstfall ist ein eigener Teilprozess innerhalb der Disaster Recovery und wird häufig unterschätzt. Kunden, die während eines Ausfalls auf eine Statusseite oder eine kurze, ehrliche Mitteilung stoßen, reagieren spürbar gelassener als bei völliger Funkstille. Das Runbook sollte deshalb vorformulierte Kommunikationsvorlagen enthalten, für interne Stakeholder ebenso wie für eine öffentliche Statusseite, damit in der Stresssituation niemand erst einen Text formulieren muss, sondern nur noch die konkreten Fakten einträgt.

8. Monitoring von Backup-Jobs und Alerting bei Fehlschlägen

Der gefährlichste Backup-Fehler ist der, der niemandem auffällt. Ein Cron-Job, der seit drei Wochen stillschweigend fehlschlägt, weil sich ein Passwort geändert hat oder die Zielpartition volllief, liefert die trügerische Sicherheit eines vermeintlich funktionierenden Systems, bis der Ernstfall eintritt und sich herausstellt, dass das letzte brauchbare Backup Wochen alt ist. Monitoring der Backup-Jobs selbst ist deshalb kein optionales Extra, sondern integraler Bestandteil jeder ernstgemeinten Backup-Strategie und Disaster Recovery.

Zwei Prüfungen sind minimal erforderlich: Erstens, ob der letzte Backup-Lauf erfolgreich mit Exit-Code 0 durchgelaufen ist, zweitens, ob überhaupt in der erwarteten Zeitspanne ein neues Backup im Zielspeicher angekommen ist. Die zweite Prüfung ist wichtiger, als sie zunächst klingt: Ein Cron-Job, der aus irgendeinem Grund gar nicht mehr getriggert wird, hinterlässt keinen fehlgeschlagenen Lauf, sondern einfach gar keinen Lauf, und eine reine Exit-Code-Prüfung würde das nicht erfassen. Ein "Dead man's switch"-Ansatz, der aktiv prüft, ob das jüngste Objekt im S3-Bucket jünger als ein definiertes Zeitfenster ist, deckt genau diesen Fall ab.

Alerting sollte in den bestehenden Kommunikationskanal des Teams integriert sein, etwa Slack, damit eine Meldung nicht in einer selten geprüften Mailbox versackt. Wichtig ist eine klare Eskalationsschwelle: Ein einzelner verspäteter Lauf, etwa durch erhöhte Last, muss nicht sofort einen lauten Alarm auslösen, aber das Ausbleiben von zwei aufeinanderfolgenden Backups oder ein wiederholter Fehlschlag sollte unmittelbar und unübersehbar gemeldet werden.

#!/usr/bin/env bash
# backup-monitor.sh: Check backup age and success, alert via Slack webhook
set -euo pipefail
IFS=$'\n\t'

readonly S3_BUCKET="s3://mironsoft-backups/shop-prod"
readonly MAX_AGE_HOURS=26
readonly SLACK_WEBHOOK_URL="${SLACK_WEBHOOK_URL:?SLACK_WEBHOOK_URL not set}"

notify_slack() {
  local message="$1"
  local color="$2"
  curl -sf -X POST -H 'Content-Type: application/json' \
    -d "{\"attachments\":[{\"color\":\"${color}\",\"text\":\"${message}\"}]}" \
    "$SLACK_WEBHOOK_URL" > /dev/null
}

latest_object="$(aws s3api list-objects-v2 --bucket "${S3_BUCKET#s3://*/}" --prefix db/ \
  --query 'sort_by(Contents, &LastModified)[-1].[Key,LastModified]' --output text)"

latest_key="$(echo "$latest_object" | awk '{print $1}')"
latest_time="$(echo "$latest_object" | awk '{print $2}')"
latest_epoch="$(date -d "$latest_time" +%s)"
now_epoch="$(date +%s)"
age_hours=$(( (now_epoch - latest_epoch) / 3600 ))

if (( age_hours > MAX_AGE_HOURS )); then
  notify_slack "Magento backup ALERT: latest DB backup (${latest_key}) is ${age_hours}h old, exceeds ${MAX_AGE_HOURS}h threshold." "danger"
  exit 1
fi

echo "[OK] Latest backup ${latest_key} is ${age_hours}h old (threshold ${MAX_AGE_HOURS}h)."

9. Self-Hosted (Mark Shust docker-magento) vs. Managed-Cloud-Snapshots

Beim Mark-Shust-Docker-Magento-Setup liegen Datenbank und Medien in Docker-Volumes, was die Backup-Strategie greifbar macht: Backup-Jobs können als eigener Service in derselben compose.yaml laufen, mit direktem Zugriff auf die relevanten Volumes, ohne Umweg über Netzwerkfreigaben. Der Vorteil des Self-Hosted-Ansatzes ist volle Kontrolle über Zeitpunkt, Werkzeug und Zielort der Sicherung, der Nachteil ist, dass das Team die gesamte Automatisierung, Überwachung und Storage-Anbindung selbst betreiben und pflegen muss.

Managed-Cloud-Snapshots, wie sie viele Cloud-Provider für Blockspeicher anbieten, verschieben einen Großteil dieser Verantwortung auf den Provider: ein Snapshot ist in Sekunden erstellt, unabhängig von der Datenbankgröße, und die Aufbewahrung wird über Provider-eigene Lifecycle-Regeln gesteuert. Der Trade-off liegt in der Granularität und Portabilität: Ein Snapshot sichert typischerweise die komplette Disk inklusive Betriebssystem, was für einen reinen Datenbank- oder Medien-Restore ineffizient ist, und ein Wechsel des Cloud-Providers wird durch proprietäre Snapshot-Formate erschwert oder unmöglich gemacht.

Für die meisten produktiven Magento-Betriebe empfiehlt sich ein hybrider Ansatz: Snapshots als schnelle, providernahe erste Verteidigungslinie für kurzfristige Rollbacks, kombiniert mit den in diesem Artikel beschriebenen anwendungsbewussten Backups über XtraBackup und tar-Archive als portable, providerunabhängige zweite und dritte Kopie im Sinne der 3-2-1-Regel. So bleibt die Disaster Recovery auch dann funktionsfähig, wenn der primäre Cloud- oder Hosting-Provider selbst Teil des Problems ist.

# compose.dev.yaml excerpt: dedicated backup service alongside Mark Shust docker-magento
services:
  backup:
    image: mironsoft/magento-backup:1.4
    restart: unless-stopped
    environment:
      MYSQL_BACKUP_PASSWORD: ${MYSQL_BACKUP_PASSWORD}
      S3_BUCKET: s3://mironsoft-backups/shop-prod
      RETENTION_DAYS: "14"
    volumes:
      - db-data:/var/lib/mysql:ro
      - media-data:/var/www/html/pub/media:ro
      - backup-staging:/var/backups/magento
    depends_on:
      - db
    entrypoint: ["/usr/local/bin/backup-cron-entrypoint.sh"]

volumes:
  db-data:
  media-data:
  backup-staging:

10. Zusammenfassung

Eine belastbare Backup-Strategie und Disaster Recovery für einen produktiven Magento-Shop besteht aus mehr als einem nächtlichen Cron-Job. RTO und RPO liefern die messbaren Zielwerte, an denen sich jede technische Entscheidung ausrichten muss. Percona XtraBackup löst das Locking-Problem großer Datenbanken, während Medien-Backups aus pub/media in engem zeitlichem Zusammenhang mit der Datenbanksicherung erfolgen müssen, um Konsistenz zu gewährleisten. Die 3-2-1-Regel mit verschlüsseltem Offsite-Storage schützt vor Szenarien, die die Produktivumgebung und lokale Backups gleichzeitig treffen.

Automatisierung mit Rotation, regelmäßige Restore-Drills und ein dokumentiertes Disaster-Recovery-Runbook mit klaren Rollen und Eskalationsketten verwandeln eine reine Backup-Routine in eine echte Disaster-Recovery-Fähigkeit. Monitoring der Backup-Jobs selbst schließt die Lücke, in der stillschweigend fehlschlagende Sicherungen unbemerkt bleiben. Ob self-hosted im Mark-Shust-Docker-Setup oder mit Managed-Cloud-Snapshots: Die Kombination aus mehreren Backup-Ebenen ist der zuverlässigste Weg, einen Magento-Shop auch nach einem schweren Vorfall planbar wieder online zu bringen.

11. FAQ: Backup-Strategie und Disaster Recovery