Backup, Restore und PITR mit Percona XtraBackup

Physische Backups mit Percona XtraBackup: Installation der passenden XtraBackup-Version, Backup-Benutzer mit auth_socket, komprimiertes/verschlüsseltes Full- + Incremental-Backup-Skript, Zeitsteuerung per systemd-Timer oder cron, Kopieren der Binlogs und eine Restore-Probe. Die Szenariokarten decken den vollständigen Restore, den Restore aus einer Incremental-Kette, die Wiederherstellung auf einen Zeitpunkt (PITR), den Restore einer einzelnen Tabelle, den Aufbau einer Replica aus einem Backup und den Restore auf einen anderen Server ab. Dieser Guide ist für tägliche Backups großer Datenbanken und für Disaster Recovery gedacht; für Migrationen, Dumps einzelner Schemas/Tabellen oder den Wechsel zwischen Versionen nutzt du den Guide zum logischen Backup (mysqldump / MySQL Shell).

Topologie: 1 Server (Einzelserver, Source, Replica oder Secondary eines InnoDB Clusters); Backup-Speicher auf lokaler Platte oder NFS

Szenarien

• Backups einrichten, zeitlich planen und Restore testen (kompletter Ablauf) — XtraBackup-Installation, Backup-Benutzer, Full- + Incremental-Backup-Skript, Zeitsteuerung und eine Restore-Probe (inklusive PITR). Wähle das, wenn du es zum ersten Mal einrichtest. Das Backup läuft bei laufendem Server; keine Downtime, nur zusätzliche Platten-/CPU-Last.
• Vollständiger Restore: zum letzten Full-Backup zurückkehren — Das Datenverzeichnis ist verloren/beschädigt oder der Server startet nicht; die Rückkehr zum Full-Backup der Kette genügt. MySQL ist während des gesamten Restores gestoppt.
• Restore aus einer Full- + Incremental-Kette (bis zum letzten Incremental) — Du willst auf den Stand des letzten Incremental-Backups (oder eines Incrementals deiner Wahl) zurück; die Incrementals werden mit --apply-log-only der Reihe nach auf das Full-Backup angewendet. MySQL ist während des gesamten Restores gestoppt.
• Wiederherstellung auf einen Zeitpunkt (PITR): vor einem fehlerhaften DELETE / DROP — Versehentlich gelöschte oder beschädigte Daten: Das letzte Backup wird zurückgespielt und die Binlogs werden bis unmittelbar vor die fehlerhafte Transaktion (per Zeit, Position oder GTID) angewendet. MySQL ist während des gesamten Restores gestoppt, und auch Schreibvorgänge nach dem Fehlerzeitpunkt gehen verloren; ist nur eine Tabelle betroffen, prüfe zuerst das Szenario für eine einzelne Tabelle.
• Einzelne Tabelle wiederherstellen (--export + IMPORT TABLESPACE) — Du brauchst nur den gesicherten Stand einer Tabelle; ohne den ganzen Server zurückzuspielen, wird die Tabelle aus dem Backup unter dem Namen t_restore importiert und die Daten werden von dort korrigiert. Der Server bleibt online.
• Neue Replica aus einem Backup aufbauen — Du willst eine neue (oder neu aufzubauende) Replica statt per Clone über das Netz aus einem vorhandenen XtraBackup-Backup vorbereiten und an die Source anbinden (große Datenmenge, Last auf der Source). Die Source ist nicht betroffen; die Daten des Zielservers werden ersetzt.
• Backup auf einem anderen Server zurückspielen (Migration, Test, Klon) — Du willst ein Produktions-Backup auf einem Test-/Entwicklungsserver öffnen, einen Server umziehen oder auf einem separaten Server prüfen, dass sich das Backup wirklich zurückspielen lässt. Der Quellserver ist nicht betroffen.

Vor dem Start

• MySQL … läuft (wurde es mit dem DBAtlas-Guide MySQL-Einzelserver-Installation installiert, sind die Pfade identisch); der root-Benutzer des Betriebssystems kann sich mit dem Befehl mysql ohne Passwort verbinden (auth_socket oder ~/.mylogin.cnf).
• Das Backup-Verzeichnis … liegt auf einer separaten Platte/einem NFS mit mindestens (Datenmenge × Anzahl der Ketten) Platz… (zstd verkleinert meist um das 3- bis 6-Fache)…. Für einen Restore braucht es unter … mindestens das Doppelte der Datenmenge an freiem Platz (Dekomprimierung + prepare).
• Binary Logging ist aktiv und GTID eingeschaltet (für PITR und konsistente Incrementals).
• Der Server erreicht repo.percona.com über HTTPS, oder ein interner Mirror ist eingerichtet.
• Ein sicherer Ort außerhalb des Servers (Tresor, Passwortmanager) für eine Kopie des Verschlüsselungsschlüssels steht bereit. Geht der Schlüssel verloren, lassen sich die Backups nicht öffnen.
• Für den Restore-Test gibt es möglichst einen separaten Testserver (mit derselben MySQL-Version und derselben my.cnf installiert). Die Restore-Schritte ersetzen das Datenverzeichnis des Servers, auf dem sie laufen.
• Dieser Server ist eine gesunde Replica: IO- und SQL-Thread stehen auf Yes, der Lag ist gering. Werden Binlogs kopiert (PITR), muss log_replica_updates aktiv sein (in 8.x standardmäßig an); sonst enthält das Binlog der Replica die von der Source kommenden Transaktionen nicht.
• Dieser Server ist Mitglied eines InnoDB Clusters und derzeit SECONDARY / ONLINE. Das Backup wird auf diesem Mitglied geplant; wird das Mitglied später Primary, schreibt das Skript eine Warnung und sichert trotzdem.
• Die wiederherzustellende Backup-Kette liegt unter …… (auf dem Server …)… und ist vollständig: das Full-Backup und die zu verwendenden Incrementals samt den Metadatenverzeichnissen -lsn…; Verschlüsselungsschlüssel unter …….
• Auf diesem Server sind MySQL … und XtraBackup … installiert; die MySQL-Unterversion ist gleich oder neuer als die des Servers, auf dem das Backup erstellt wurde (der Wert server_version des Backups erscheint im Diagnoseschritt).
• …Auf dem Zielserver gibt es keine zu erhaltenden Daten: Das Datenverzeichnis wird durch das Backup ersetzt (das alte wird als .old-<zeit> beiseitegelegt).…Wartungsfenster und Anwendungs-Downtime sind freigegeben: MySQL ist während des Restores gestoppt; die Anwendung darf sich nicht mit diesem Server verbinden.…
• Die Tabelle ist InnoDB und liegt dank innodb_file_per_table = ON (Standard in 8.x) in einer eigenen .ibd-Datei; die Tabellenstruktur (Spalten, Indexe) hat sich seit dem Backup nicht geändert. Der Server bleibt online.

Phasen der Anleitung

• XtraBackup-Installation — Percona-Repository hinzufügen · XtraBackup installieren
• Backup-Benutzer und Schlüssel — Plugin auth_socket prüfen · Backup-Benutzer anlegen · Verbindung testen · Verschlüsselungsschlüssel erzeugen
• Backup-Skript und Zeitsteuerung — Backup-Verzeichnis anlegen · Backup-Skript schreiben · Skript ausführbar machen · Erstes Full-Backup erstellen · Incremental-Backup ausprobieren · systemd-Service schreiben …
• Restore — Kette ins Arbeitsverzeichnis kopieren · Entschlüsseln / dekomprimieren · Full-Backup vorbereiten (prepare, apply-log-only) · Incrementals der Reihe nach anwenden · Abschließendes prepare · MySQL stoppen, vorhandene Daten beiseitelegen …
• Wiederherstellung auf einen Zeitpunkt (PITR) — Zielzeitpunkt bestimmen · Binlogs bis zum Zielzeitpunkt anwenden · Ergebnis prüfen und neues Backup erstellen
• Aufräumen — Beiseitegelegte Daten und Arbeitsverzeichnis löschen
• 1. Diagnose: welches Backup, welche Methode? — Serverzustand und Versionen prüfen · Backup-Ketten und ihren Inhalt auflisten
• 2. Sicherheitsnetz — Aktuellen Zustand und Konfiguration festhalten
• 3. Durchführung: Backup vorbereiten — Kette ins Arbeitsverzeichnis kopieren · Kette ins Arbeitsverzeichnis kopieren · Entschlüsseln / dekomprimieren · Full-Backup vorbereiten (prepare, apply-log-only) · Incrementals der Reihe nach anwenden · Abschließendes prepare
• 3. Durchführung: Daten zurückspielen — MySQL stoppen, vorhandene Daten beiseitelegen · Backup ins Datenverzeichnis kopieren (copy-back) · MySQL starten und prüfen · Aus dem Backup übernommene Replikationskonfiguration prüfen
• 3. Durchführung: Binlogs bis zum Ziel anwenden (PITR) — Fehlerhafte Transaktion und Zielpunkt prüfen · Binlogs bis zum Ziel anwenden
• 4. Prüfung — Prüfen, dass die fehlerhafte Transaktion rückgängig gemacht ist · Daten prüfen
• 5. Nacharbeiten — Neues Full-Backup erstellen · Beiseitegelegte Daten und Arbeitsverzeichnis löschen · Grundursache und Topologie
• 1. Diagnose: Sind Tabelle und Backup geeignet? — Aktuellen Zustand und Struktur der Tabelle anzeigen · Backup-Ketten und ihren Inhalt auflisten
• 2. Sicherheitsnetz — Aktuellen Stand der Tabelle sichern
• 3. Durchführung: Backup mit --export vorbereiten — Kette ins Arbeitsverzeichnis kopieren · Entschlüsseln / dekomprimieren · Full-Backup vorbereiten (prepare, apply-log-only) · Incrementals der Reihe nach anwenden · Abschließendes prepare (--export)
• 3. Durchführung: Tabelle in eine Zwischentabelle importieren — Zwischentabelle anlegen und ihren Tablespace verwerfen · Dateien aus dem Backup kopieren und importieren (IMPORT TABLESPACE)
• 4. Prüfung — Zwischentabelle prüfen und mit der Originaltabelle vergleichen
• 5. Nacharbeiten: Daten übernehmen und aufräumen — Benötigte Zeilen in die Originaltabelle übernehmen · Zwischentabelle und Arbeitsverzeichnis löschen
• 1. Diagnose: Sind Zielserver und Backup geeignet? — Version, Identität und Platte des Zielservers prüfen · Backup-Ketten und ihren Inhalt auflisten (…)
• 2. Sicherheitsnetz — Aktuellen Zustand und Konfiguration festhalten
• 3. Durchführung: Backup holen und vorbereiten — Kette vom Backup-Server holen · Kette ins Arbeitsverzeichnis kopieren · Entschlüsseln / dekomprimieren · Full-Backup vorbereiten (prepare, apply-log-only) · Incrementals der Reihe nach anwenden · Abschließendes prepare
• 3. Durchführung: Daten zurückspielen — MySQL stoppen, vorhandene Daten beiseitelegen · Backup ins Datenverzeichnis kopieren (copy-back) · MySQL starten und prüfen · Aus dem Backup übernommene Replikationskonfiguration prüfen
• 3. Durchführung: Replikation ab dem Punkt des Backups starten — Startpunkt bestimmen · Replikation konfigurieren und starten
• 4. Prüfung — Daten prüfen
• 5. Nacharbeiten — Beiseitegelegte Daten und Arbeitsverzeichnis löschen · Server in seiner neuen Rolle in Betrieb nehmen