Ihr MySQL-Backup Dauert 12 Stunden. So Beheben Sie Das.

Vollständige Backups einer 2-TB-MySQL-Datenbank, die mehr als 12 Stunden dauern, regelmässig fehlschlagen und noch nie zurückgespielt wurden, sind ein häufiger Befund. Das Backup existiert, aber niemand weiss, ob es funktioniert. Dieser Leitfaden gibt Ihnen einen Selbsttest in zwei Minuten und die vier Schritte, mit denen wir das beheben. Er basiert auf einem echten Projekt.

Selbsttest in zwei Minuten

Beantworten Sie ehrlich:

1. Wann haben Sie zuletzt ein Backup vollständig in ein Testsystem zurückgespielt?
2. Wie lange dauert eine vollständige Wiederherstellung? Wissen Sie es, oder ist es eine Schätzung?
3. Wenn ein Backup nachts fehlschlägt, wer merkt es, und wann?
4. Können Sie auf einen bestimmten Zeitpunkt zurückgehen, zum Beispiel fünf Minuten vor einem fehlerhaften Deployment?
5. Was kosten Sie die Backup-Speicher pro Monat?

Wenn Sie zwei oder mehr dieser Fragen nicht beantworten können, haben Sie ein Wiederherstellungsrisiko statt eines Backups.

Warum es im grossen Massstab bricht

• Vollständige Backups wachsen mit den Daten. Im Terabyte-Bereich dauern sie einen halben Tag und schlagen häufiger fehl.
• Inkrementelle Backups hängen an einer Kette. Löscht man ein Glied, ist alles danach unbrauchbar.
• Eine Wiederherstellung von einem Terabyte dauert so lange, dass Teams sie nicht testen. Ungetestete Backups versagen, wenn man sie braucht.
• Generische Backup-Tools verstehen InnoDB nicht. Managed-Lösungen rechnen pro GB ab.

Die Lösung in vier Schritten

1. Ein datenbanknahes Backup-Tool verwenden. XtraBackup versteht Änderungen auf InnoDB-Seitenebene. Wöchentlich ein Vollbackup und alle sechs Stunden ein inkrementelles, verschlüsselt und komprimiert, zuerst auf schnellen lokalen Speicher und dann in den Objektspeicher synchronisiert.
2. Retention mit Kettenlogik. Ein Backup wird erst gelöscht, wenn alle Backups seiner Kette älter als die Aufbewahrungsfrist sind. So entstehen keine verwaisten inkrementellen Backups, die sich nicht zurückspielen lassen.
3. Point-in-Time-Recovery als Skript. Ein Befehl stellt auf einen gewählten Zeitpunkt wieder her: zuerst das Vollbackup, dann die inkrementellen in der richtigen Reihenfolge. Ein Dry-Run-Modus zeigt den Plan vorab.
4. Restore-Test automatisieren. Regelmässig in ein Testsystem zurückspielen und bei Fehlern alarmieren. Was manuell getestet wird, wird nicht getestet.

Wie es in der Praxis aussah

Bei einer 2-TB-Produktionsdatenbank sank die Backup-Zeit von 12 Stunden auf 30 Minuten für ein Vollbackup und 5 Minuten für ein inkrementelles. Die Erfolgsquote stieg von 60% auf 99.8%, Restores werden monatlich getestet, und der Speicher kostet rund 3 $ im Monat statt über 150 $ für ein Managed-Tool. Details: die Fallstudie.

Nächster Schritt

Machen Sie den Selbsttest heute. Zeigt er Lücken, buchen Sie ein Gespräch, und wir schauen uns Ihr Setup gemeinsam an.