Sauvegarde, restauration et PITR avec Percona XtraBackup

Sauvegarde physique avec Percona XtraBackup : installation de la version d'XtraBackup compatible, utilisateur de sauvegarde avec auth_socket, script de sauvegarde full + incrémentale compressée/chiffrée, planification par timer systemd ou cron, copie des binlogs et test de restauration. Les cartes de scénario couvrent la restauration complète, la restauration depuis une chaîne incrémentale, le retour à un instant précis (PITR), la restauration d'une seule table, la création d'un replica à partir d'une sauvegarde et la restauration sur un autre serveur. Utilisez ce guide pour la sauvegarde quotidienne des grosses bases et pour la reprise après sinistre ; pour une migration, un dump d'un seul schéma/d'une seule table ou un passage entre versions, utilisez le guide de sauvegarde logique (mysqldump / MySQL Shell).

Topologie: 1 serveur (autonome, source, replica ou secondary d'InnoDB Cluster) ; stockage des sauvegardes sur disque local ou NFS

Scénarios

• Mettre en place les sauvegardes, les planifier et tester la restauration (flux complet) — Installation d'XtraBackup, utilisateur de sauvegarde, script de sauvegarde full + incrémentale, planification et test de restauration (PITR compris). Choisissez cette option pour une première mise en place. La sauvegarde est prise serveur ouvert : aucune interruption, seule la charge disque/CPU augmente.
• Restauration complète : revenir à la dernière sauvegarde full — Le répertoire de données est perdu/corrompu ou le serveur ne démarre pas ; revenir à la sauvegarde full de la chaîne suffit. MySQL reste arrêté pendant toute la restauration.
• Restaurer depuis une chaîne full + incrémentale (jusqu'à la dernière incrémentale) — Vous voulez revenir à l'instant de la dernière sauvegarde incrémentale (ou d'une incrémentale de votre choix) ; les incrémentales sont appliquées dans l'ordre sur la full avec --apply-log-only. MySQL reste arrêté pendant toute la restauration.
• Revenir à un instant précis (PITR) : avant un DELETE / DROP erroné — Données supprimées ou corrompues par erreur : la dernière sauvegarde est restaurée et les binlogs sont appliqués jusqu'à juste avant la transaction fautive (par date, position ou GTID). MySQL reste arrêté pendant toute la restauration et les écritures postérieures à l'erreur sont aussi annulées ; si une seule table est touchée, envisagez d'abord le scénario de restauration d'une seule table.
• Restaurer une seule table (--export + IMPORT TABLESPACE) — Vous avez seulement besoin de l'état sauvegardé d'une table ; sans restaurer tout le serveur, la table est importée depuis la sauvegarde sous le nom t_restore et les données sont corrigées à partir de là. Le serveur reste ouvert.
• Créer un nouveau replica à partir d'une sauvegarde — Vous voulez préparer un replica neuf (ou à reconstruire) à partir d'une sauvegarde XtraBackup existante plutôt que par un clone réseau, puis le connecter à la source (gros volume, charge sur la source). La source n'est pas touchée ; les données du serveur cible sont remplacées.
• Restaurer la sauvegarde sur un autre serveur (migration, test, clone) — Vous voulez ouvrir une sauvegarde de production sur un serveur de test/développement, migrer un serveur ou vérifier sur un serveur séparé que la sauvegarde se restaure réellement. Le serveur source n'est pas touché.

Avant de commencer

• MySQL … fonctionne (s'il a été installé avec le guide DBAtlas Installation MySQL sur un serveur, les chemins sont identiques) ; le root du système d'exploitation peut se connecter sans mot de passe avec la commande mysql (auth_socket ou ~/.mylogin.cnf).
• Le répertoire de sauvegarde … est sur un disque/NFS séparé avec au moins (taille des données × nombre de chaînes) d'espace… (zstd réduit généralement la taille de 3 à 6 fois)…. La restauration nécessite au moins deux fois la taille des données en espace libre sous … (décompression + prepare).
• Le binary log est activé et GTID est actif (pour le PITR et la cohérence des incrémentales).
• Le serveur peut joindre repo.percona.com en HTTPS, ou un miroir interne est configuré.
• Un emplacement sûr hors du serveur (coffre, gestionnaire de mots de passe) est prêt pour conserver une copie de la clé de chiffrement. Si la clé est perdue, les sauvegardes ne peuvent plus être ouvertes.
• Un serveur de test séparé est de préférence disponible pour le test de restauration (installé avec la même version de MySQL et le même my.cnf). Les étapes de restauration remplacent le répertoire de données du serveur sur lequel elles s'exécutent.
• Ce serveur est un replica sain : threads IO et SQL à Yes, retard faible. Si les binlogs sont copiés (PITR), log_replica_updates doit être activé (actif par défaut en 8.x) ; sinon le binlog du replica ne contient pas les transactions venant de la source.
• Ce serveur est membre d'un InnoDB Cluster et actuellement SECONDARY / ONLINE. La sauvegarde est planifiée sur ce membre ; si le membre devient primary par la suite, le script écrit un avertissement et prend quand même la sauvegarde.
• La chaîne de sauvegarde à restaurer se trouve sous …… (sur le serveur …)… et elle est complète : la full et les incrémentales à utiliser, avec les répertoires de métadonnées -lsn… ; clé de chiffrement dans …….
• MySQL … et XtraBackup … sont installés sur ce serveur ; la version mineure de MySQL est identique ou plus récente que celle du serveur sauvegardé (la valeur server_version de la sauvegarde apparaît à l'étape de diagnostic).
• …Aucune donnée à conserver sur le serveur cible : le répertoire de données est remplacé par la sauvegarde (l'ancien est mis de côté sous .old-<horodatage>).…La fenêtre de maintenance et l'interruption applicative sont validées : MySQL est arrêté pendant la restauration ; l'application ne doit pas se connecter à ce serveur.…
• La table est en InnoDB et dans son propre fichier .ibd avec innodb_file_per_table = ON (valeur par défaut en 8.x) ; la structure de la table (colonnes, index) n'a pas changé depuis la sauvegarde. Le serveur reste ouvert.

Phases du guide

• Installation d'XtraBackup — Ajouter le dépôt Percona · Installer XtraBackup
• Utilisateur de sauvegarde et clé — Vérifier le plugin auth_socket · Créer l'utilisateur de sauvegarde · Tester la connexion · Créer la clé de chiffrement
• Script de sauvegarde et planification — Créer le répertoire de sauvegarde · Écrire le script de sauvegarde · Rendre le script exécutable · Prendre la première sauvegarde full · Tester une sauvegarde incrémentale · Écrire le service systemd …
• Restauration (restore) — Copier la chaîne dans le répertoire de travail · Déchiffrer / décompresser · Préparer la sauvegarde full (prepare, apply-log-only) · Appliquer les incrémentales dans l'ordre · Prepare final · Arrêter MySQL et mettre les données existantes de côté …
• Retour à un instant précis (PITR) — Déterminer l'instant cible · Appliquer les binlogs jusqu'à l'instant cible · Vérifier le résultat et prendre une nouvelle sauvegarde
• Nettoyage — Supprimer les données mises de côté et le répertoire de travail
• 1. Diagnostic : quelle sauvegarde, quelle méthode ? — Vérifier l'état du serveur et les versions · Lister les chaînes de sauvegarde et leur contenu
• 2. Filet de sécurité — Enregistrer l'état et la configuration actuels
• 3. Application : préparer la sauvegarde — Copier la chaîne dans le répertoire de travail · Copier la chaîne dans le répertoire de travail · Déchiffrer / décompresser · Préparer la sauvegarde full (prepare, apply-log-only) · Appliquer les incrémentales dans l'ordre · Prepare final
• 3. Application : restaurer les données — Arrêter MySQL et mettre les données existantes de côté · Copier la sauvegarde dans le répertoire de données (copy-back) · Démarrer MySQL et vérifier · Vérifier la configuration de réplication restaurée depuis la sauvegarde
• 3. Application : appliquer les binlogs jusqu'à la cible (PITR) — Vérifier la transaction fautive et le point cible · Appliquer les binlogs jusqu'à la cible
• 4. Vérification — Vérifier que la transaction fautive a été annulée · Vérifier les données
• 5. Après — Prendre une nouvelle sauvegarde full · Supprimer les données mises de côté et le répertoire de travail · Cause racine et topologie
• 1. Diagnostic : la table et la sauvegarde conviennent-elles ? — Afficher l'état actuel et la structure de la table · Lister les chaînes de sauvegarde et leur contenu
• 2. Filet de sécurité — Sauvegarder l'état actuel de la table
• 3. Application : préparer la sauvegarde avec --export — Copier la chaîne dans le répertoire de travail · Déchiffrer / décompresser · Préparer la sauvegarde full (prepare, apply-log-only) · Appliquer les incrémentales dans l'ordre · Prepare final (--export)
• 3. Application : importer la table dans une table intermédiaire — Créer la table intermédiaire et détacher son tablespace · Copier les fichiers de la sauvegarde et les importer (IMPORT TABLESPACE)
• 4. Vérification — Contrôler la table intermédiaire et la comparer à la table d'origine
• 5. Après : reporter les données et nettoyer — Reporter les lignes nécessaires dans la table d'origine · Supprimer la table intermédiaire et le répertoire de travail
• 1. Diagnostic : le serveur cible et la sauvegarde conviennent-ils ? — Vérifier la version, l'identité et le disque du serveur cible · Lister les chaînes de sauvegarde et leur contenu (…)
• 2. Filet de sécurité — Enregistrer l'état et la configuration actuels
• 3. Application : récupérer et préparer la sauvegarde — Récupérer la chaîne depuis le serveur de sauvegarde · Copier la chaîne dans le répertoire de travail · Déchiffrer / décompresser · Préparer la sauvegarde full (prepare, apply-log-only) · Appliquer les incrémentales dans l'ordre · Prepare final
• 3. Application : restaurer les données — Arrêter MySQL et mettre les données existantes de côté · Copier la sauvegarde dans le répertoire de données (copy-back) · Démarrer MySQL et vérifier · Vérifier la configuration de réplication restaurée depuis la sauvegarde
• 3. Application : démarrer la réplication depuis la position de la sauvegarde — Déterminer le point de départ · Configurer et démarrer la réplication
• 4. Vérification — Vérifier les données
• 5. Après — Supprimer les données mises de côté et le répertoire de travail · Mettre le serveur en service dans son nouveau rôle