MySQL inkrementelle Backups im großen Maßstab: Von 12-Stunden-Backups zu 30-Minuten-Operationen

Das Problem

Ein datenintensives Startup führte 2TB MySQL in der Produktion. Vollständige Backups dauerten 12+ Stunden und schlugen regelmäßig fehl. Das Team hatte keine zuverlässige Möglichkeit, die Wiederherstellung zu testen — eine vollständige Wiederherstellung dauerte Tage. Backup-Fehler wurden erst bei Bedarf erkannt. Die Kosten für Managed-Backup-Lösungen (Kasten, AWS DMS) betrugen 150+$/Monat, nur für Backups.

Die Herausforderung

Das Skalieren von Backups bei TB-Größe ist täuschend schwierig:

• Vollständige Backups sind teuer — 12GB+ pro Woche, eine pro Woche schafft Lücken
• Inkrementelle Backups brechen leicht — Backup-Ketten werden verwaist, Ketten werden gelöscht, während inkrementelle Backups noch von ihnen abhängen
• Point-in-Time-Recovery ist komplex — erfordert Wiedergabe eines vollständigen Backups + mehrere inkrementelle Backups in korrekter Reihenfolge
• Die Kosten summieren sich auf — Managed-Backup-Lösungen berechnen pro GB Backup
• Wiederherstellung testen ist riskant — Wiederherstellung von TB Daten dauert zu lange, Team vermeidet Tests

Die Lösung

Wir haben ein spezialisiertes Backup-System speziell für MySQL im großen Maßstab entwickelt:

Phase 1: Backup-Architektur

• XtraBackup für MySQL implementiert (versteht InnoDB-Seiten-Level-Änderungen)
• Vollständige Backups wöchentlich + inkrementelle Backups alle 6 Stunden
• Local-First-Speicher (schnelle SSD für schnelle Wiederherstellung)
• S3-Sync für Compliance und Disaster Recovery
• Automatische Verschlüsselung (AES256) und Kompression (zstd)

Phase 2: Chain-Aware Retention

• System zum Tracking von Backup-Chain-Abhängigkeiten
• Backup nur löschen, wenn ALLE Backups in seiner Chain älter sind als Aufbewahrungszeitraum
• Verhindert verwaiste inkrementelle Backups, die nicht wiederhergestellt werden können
• Klare Benennungskonvention für Chain-Tracking
• Automatische Bereinigung defekter Ketten

Phase 3: Point-in-Time-Recovery

• Skriptierter Wiederherstellungsprozess für jeden bestimmten Zeitpunkt
• Spielt inkrementelle Backups in Reihenfolge bis Zielzeit ab
• Erkennt automatisch Verschlüsselung und Kompression
• Dry-Run-Unterstützung zur Sicherheitsverifikation
• Wiederherstellung in wöchentliche Verfahren eingebaut

Phase 4: Betrieb & Sichtbarkeit

• Automatische wöchentliche Analyse der Backup-Chain-Gesundheit
• Speicherverbrauch Tracking (lokal vs S3)
• Backup-Integritätsverifikation
• Einfache Shell-Skripte (keine Operatoren oder Controller erforderlich)
• Klare Überwachung und Benachrichtigungen

Ergebnisse

Zuverlässigkeit:

• ✅ Backup-Erfolgsquote: 99,8% (war 60% bei manuellem Prozess)
• ✅ Wiederherstellung monatlich getestet (zuvor ungettestet)
• ✅ Point-in-Time-Recovery-Fähigkeit verifiziert
• ✅ Keine verwaisten Backup-Ketten in 12+ Monaten

Betrieb:

• ✅ Backup-Zeit: 12 Stunden → 30 Minuten (vollständig) + 5 Minuten (inkrementell)
• ✅ Wiederherstellungstestzyklus: Tage → Stunden
• ✅ Backup-Fehlerbehebung: 80% weniger Zeitaufwand
• ✅ Teamvertrauen in Wiederherstellungsverfahren: hoch

Finanziell:

• ✅ Kosten: 3$/Monat (S3-Speicher) vs 150+$/Monat für Managed Solutions
• ✅ Jährliche Einsparungen: ~1.800$
• ✅ ROI aus Implementierung: sofort

Wichtige Erkenntnisse

1. Inkrementelle Backups sparen Speicher im großen Maßstab — aber nur, wenn Chain-Management automatisiert ist
2. Datenbank-native Tools sind essentiell — generische Backup-Lösungen verstehen MySQLs Struktur nicht
3. Point-in-Time-Recovery erfordert vollständiges + inkrementelles Chain — aber der Wiederherstellungsprozess kann einfach sein
4. Wiederherstellung testen muss automatisiert werden — wenn es manuell ist, wird es nicht regelmäßig durchgeführt
5. Local-First + Cloud-Sync schlägt reine Cloud-Backups — schnellere Wiederherstellung, niedrigere Kosten, bessere Compliance