Partie 5 · Exploitation
Sauvegarde, restauration, automatisation
Une panne serveur ou une erreur de manipulation ne doit pas faire perdre les données. La direction demande une stratégie de sauvegarde complète et exploitable : elle inclut non seulement les données, mais aussi la logique SQL avancée associée au système.
À définir :
- la fréquence de sauvegarde (le volet Sauvegarde parle de sauvegardes automatiques quotidiennes / hebdomadaires) ;
- ce qui doit impérativement être sauvegardé ;
- une rotation ou conservation limitée des dumps ;
- la journalisation des sauvegardes réussies et échouées ;
- un test minimal de restauration ;
- comment vérifier que les objets avancés (procédures, triggers, événements) sont bien restaurés.
Modalités citées : export SQL ou dump, versionning des sauvegardes, stockage externe possible. L'automatisation des traitements récurrents passe par la planification (CRON pour la collecte et les sauvegardes).
Vérifie que tu as compris
À toi de coder
Tester pour croire
Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Le test minimal de restauration consiste à recharger le dump dans une base vierge, vérifier les comptes de lignes, puis vérifier que les objets avancés existent (ici : le trigger dans sqlite_master). Le résultat du test et chaque sauvegarde (réussie ou échouée) doivent laisser une trace dans une table de journalisation des sauvegardes.