Sauvegarder MySQL et vérifier que l’export se restaure

01. Inventorier les dépendances

Listez les bases, moteurs de tables, événements, routines et déclencheurs utilisés. Notez également la version du serveur, les jeux de caractères et les comptes nécessaires à l’application. Le dump d’une base ne constitue pas à lui seul une sauvegarde de toute la configuration du service.

Choisissez un créneau et un compte de sauvegarde aux privilèges adaptés. L’exemple suivant vise MySQL avec des tables InnoDB. Les paramètres et les droits doivent être validés pour votre version ; ils ne sont pas interchangeables sans contrôle avec MariaDB.

02. Produire un export contrôlé

umask 077
mysqldump -u sauvegarde -p \
  --single-transaction --quick \
  --routines --events --triggers \
  application > application.sql

Le mot de passe est demandé, sans être écrit dans la commande. --single-transaction permet une vue cohérente des tables transactionnelles prises en charge ; cela ne rend pas cohérentes les tables non transactionnelles. Évitez les changements de structure pendant l’export.

Contrôlez immédiatement le code de retour et la sortie d’erreur. Un fichier non vide peut être incomplet. Pour automatiser, utilisez un fichier temporaire et ne le renommez comme sauvegarde terminée qu’après le succès de la commande. Protégez ensuite l’export : il peut contenir toutes les données sensibles de l’application.

03. Restaurer sur une instance isolée

Utilisez un serveur de test dont les paramètres de connexion ne peuvent pas pointer sur la production. Créez une base vide dédiée, importez le SQL, puis vérifiez les erreurs. Les comptes référencés par les objets, leurs permissions et les extensions de l’application peuvent demander une préparation supplémentaire.

Comparez quelques indicateurs métier : nombre de clients actifs, date du dernier enregistrement attendu, présence des documents associés. Lancez l’application restaurée avec les e-mails, paiements et webhooks externes désactivés. Un simple comptage des tables ne valide pas le fonctionnement du service.

04. Mesurer le délai réel de reprise

Chronométrez téléchargement, déchiffrement, import et contrôles. Si l’import dépasse le délai accepté, étudiez une méthode physique ou une architecture de reprise différente. Si vous devez revenir entre deux exports, prévoyez une stratégie de journaux binaires et testez-la séparément.

Conservez le compte rendu avec l’identifiant de sauvegarde, le résultat et les problèmes rencontrés. Transférez l’export validé vers un dépôt distinct, avec une rétention définie. Consultez aussi la méthode pour séparer les copies.

05. Réexaminer les copies tar et snapshots du wiki

L’article original comparait dump SQL, copie des fichiers et snapshot LVM. Ces méthodes n’offrent pas les mêmes garanties. Une copie tar du répertoire de données pendant les écritures ne devient pas une sauvegarde cohérente parce qu’elle termine sans erreur.

Un snapshot de stockage doit couvrir les fichiers et journaux nécessaires avec une coordination adaptée au moteur. Choisissez une procédure officiellement prise en charge par la version de la base, puis testez son démarrage après restauration. Le guide d’administration MySQL précise aussi les différences de réparation entre moteurs.