Il y a plusieurs questions à se poser. Vous pensez bien qu’il y a une différence d’infrastructure et de procédure si vous voulez une application toujours up.
Vous avez probablement, dans vos contrats, un temps d’indisponibilité possible pour votre application dans le cadre d’une application BtoB.
Si c’est une application BtoC, combien de temps peut-elle être indisponible ?
Nous allons voir, dans cet article, comment mettre en place une sauvegarde MySql et traiterons dans un prochain article la restauration d’un environnement.
Combien de données puis-je perdre ?
Sans les données, il n’y a plus d’application. Mais pour une application qui fait de l’agrégation de données (comme Banking) ou une application avec beaucoup de saisie de données (comme un site de e-commerce), nous n’avons pas la même criticité.
L’agrégation peut toujours récupérer les données du jour précèdent. « Seules » les données complémentaires seraient perdues.
Pour une application de saisie d’information, il peut y avoir une perte de chiffre d’affaire, car les commandes seraient perdues.
Sauvegarde automatique
Il y a les données de la vie courante et exceptionnelles.
Si vous préparez un lancement, ce n’est pas la même chose que le cycle de vie classique de votre application.
Sauvegarde complète
mysqldump --all-databases --master-data --single-transaction > backup.sql
Avec l’option --single-transaction, la sauvegarde MySql aura une cohérence de données.
Vous pouvez avoir une tâche planifiée qui fera un backup complet de vos bases de façon régulière.
Sauvegarde incrémentale
Vous pouvez aussi activer les binary log de MySQL. Pour ce faire le serveur MySQL doit être démarré avec l’option --log-bin.
Lorsque les bin log sont activées, le serveur enregistre toutes les instructions qui modifient les données dans le journal binaire.
Il ne reste plus qu’à sauvegarder ces fichiers. Une sauvegarde complète reste nécessaire (avec un flush des bin log).
mysqldump --single-transaction --flush-logs --master-data=2 --all-databases --delete-master-logs > backup.sql
La suppression des journaux binaires MySQL avec mysqldump –delete-master-logs peut être dangereuse si votre serveur est un serveur source de réplication, car les serveurs de réplication n’ont peut-être pas encore complètement traité le contenu du journal binaire. La description de l’instruction
https://dev.mysql.com/doc/mysql-backup-excerpt/5.7/en/backup-policy.htmlPURGE BINARY LOGSexplique ce qui doit être vérifié avant de supprimer les journaux binaires MySQL.
Testez vos sauvegardes
Une sauvegarde c’est bien, mais une sauvegarde qui fonctionne c’est mieux. Utilisez votre environnement de préprod ou de recette pour tester votre sauvegarde. Vous saurez ainsi que votre sauvegarde a eu un problème et vous pourrez intervenir.