Sauvegardes MySQL Incrémentielles À Grande Échelle : De 12 Heures À 30 Minutes

Le problème

Une startup très orientée données exploitait 2 To de MySQL en production. Les sauvegardes complètes duraient plus de 12 heures et échouaient régulièrement. L’équipe n’avait aucun moyen fiable de tester la restauration. Une restauration complète prenait des jours. Les échecs de sauvegarde passaient inaperçus jusqu’au moment où l’on en avait besoin. Les solutions de sauvegarde gérées (Kasten, AWS DMS) coûtaient plus de 150 $ par mois, rien que pour les sauvegardes.

Le défi

Sauvegarder à l’échelle du téraoctet est plus difficile qu’il n’y paraît :

• Les sauvegardes complètes coûtent cher : plus de 12 Go chacune, et une par semaine laisse des trous
• Les sauvegardes incrémentielles se cassent facilement : des chaînes deviennent orphelines, ou sont supprimées alors que des incrémentielles en dépendent encore
• La restauration à un instant précis est complexe : il faut rejouer une sauvegarde complète puis plusieurs incrémentielles, dans le bon ordre
• Les coûts s’accumulent : les solutions gérées facturent chaque Go sauvegardé
• Tester la restauration est risqué : restaurer des téraoctets prend trop de temps, l’équipe évite donc de le faire

La solution

Nous avons construit un système de sauvegarde conçu spécifiquement pour MySQL à grande échelle :

Phase 1 : architecture de sauvegarde

• Mise en place de XtraBackup pour MySQL (qui comprend les changements au niveau des pages InnoDB)
• Sauvegardes complètes chaque semaine et incrémentielles toutes les 6 heures
• Stockage local d’abord (SSD rapide pour une restauration rapide)
• Synchronisation S3 pour la conformité et la reprise après sinistre
• Chiffrement (AES256) et compression (zstd) automatiques

Phase 2 : rétention fondée sur les chaînes

• Système qui suit les dépendances entre sauvegardes d’une même chaîne
• Une sauvegarde n’est supprimée que si TOUTES celles de sa chaîne dépassent la durée de rétention
• Pas d’incrémentielles orphelines impossibles à restaurer
• Convention de nommage claire pour suivre les chaînes
• Nettoyage automatique des chaînes cassées

Phase 3 : restauration à un instant précis

• Processus de restauration scripté pour n’importe quel horodatage
• Rejeu des sauvegardes incrémentielles dans l’ordre jusqu’à l’instant visé
• Détection automatique du chiffrement et de la compression
• Mode simulation (dry-run) pour vérifier en toute sécurité
• Test de restauration intégré aux procédures hebdomadaires

Phase 4 : exploitation et visibilité

• Analyse hebdomadaire automatisée de l’état des chaînes de sauvegarde
• Suivi de l’espace de stockage utilisé (local et S3)
• Vérification de l’intégrité des sauvegardes
• De simples scripts shell (ni opérateurs ni contrôleurs nécessaires)
• Supervision et alertes claires

Résultats

Fiabilité :

• ✅ Taux de réussite des sauvegardes : 99,8% (contre 60% avec le processus manuel)
• ✅ Restauration testée chaque mois (jamais testée auparavant)
• ✅ Restauration à un instant précis vérifiée
• ✅ Aucune chaîne de sauvegarde orpheline en plus de 12 mois

Exploitation :

• ✅ Durée de sauvegarde : 12 heures → 30 minutes (complète) + 5 minutes (incrémentielle)
• ✅ Cycle de test de restauration : des jours → des heures
• ✅ Dépannage des sauvegardes : 80% de temps en moins
• ✅ Confiance de l’équipe dans les procédures de restauration : élevée

Finances :

• ✅ Coût : 3 $ par mois (stockage S3) contre plus de 150 $ par mois pour les solutions gérées
• ✅ Économie annuelle : environ 1 800 $
• ✅ Retour sur investissement : immédiat

À retenir

1. Les sauvegardes incrémentielles économisent du stockage à grande échelle, mais seulement si la gestion des chaînes est automatisée
2. Les outils natifs de la base de données sont indispensables : les solutions de sauvegarde génériques ne comprennent pas la structure de MySQL
3. La restauration à un instant précis exige une chaîne complète + incrémentielles, mais le processus de restauration peut rester simple
4. Le test de restauration doit être automatisé : s’il est manuel, il ne se fera pas régulièrement
5. Stockage local d’abord + synchronisation cloud valent mieux que le tout-cloud : restauration plus rapide, coût plus bas, meilleure conformité