Pourquoi copier les fichiers ne suffit pas
Copier les fichiers d'une base pendant qu'elle tourne produit une sauvegarde qui existe, s'ouvre, et refuse de démarrer.
La raison est simple. Une base écrit en permanence dans plusieurs fichiers, et une écriture logique se répartit sur plusieurs d'entre eux. Une copie prise en cours de route capture certains fichiers avant l'écriture, d'autres après. Le résultat est incohérent, et la base le détecte au démarrage.
C'est l'échec de restauration le plus fréquent, et il ne se voit qu'au moment de restaurer.
Les trois méthodes correctes
L'export logique. L'outil de la base produit un fichier qui décrit son contenu. Simple, portable d'une version à l'autre, mais lent sur les gros volumes et coûteux à restaurer.
La sauvegarde physique cohérente. L'outil dédié de la base copie les fichiers en s'assurant de leur cohérence, souvent en s'appuyant sur le journal des transactions. Plus rapide, plus fidèle, lié à la version.
L'instantané avec gel des écritures. Le stockage prend un instantané pendant que la base est brièvement mise en pause d'écriture. Très rapide, mais il faut que la base coopère : un instantané pris sans ce gel est exactement la copie incohérente décrite plus haut.
Le journal des transactions change tout
Sur les bases qui en tiennent un, il permet de restaurer à un instant précis, pas seulement à l'heure de la dernière sauvegarde complète.
Concrètement : sauvegarde complète chaque nuit, journal sauvegardé toutes les quinze minutes, et vous pouvez revenir à 14 h 07, juste avant la suppression accidentelle d'une table.
Attention au piège classique : sur certains systèmes, un journal jamais sauvegardé n'est jamais purgé, et il remplit le disque jusqu'à l'arrêt de la base. Une sauvegarde mal configurée provoque alors la panne qu'elle devait prévenir.
Ce qu'il faut vérifier
Trois contrôles, dans cet ordre.
La sauvegarde est-elle cohérente ? Le seul verdict fiable est une restauration suivie d'un démarrage.
Combien de temps met la restauration ? Sur une grosse base, le temps de rejeu du journal s'ajoute à la copie, et il est souvent sous-estimé.
Les identifiants sont-ils dedans ? Restaurer les données sans les comptes d'accès produit une base intacte que l'application ne peut plus utiliser.
Le cas des bases gérées
Une base gérée par un fournisseur cloud fait ses instantanés automatiquement, et c'est confortable. Deux limites demeurent.
La rétention est bornée, souvent à quelques jours ou semaines. Et ces instantanés vivent dans le même compte : la perte d'accès au compte les emporte.
Un export régulier vers un autre emplacement reste nécessaire, exactement pour les mêmes raisons qu'ailleurs.
À retenir
Ne copiez jamais les fichiers d'une base en marche. Utilisez l'outil de la base, sauvegardez le journal des transactions et surveillez sa purge. Et vérifiez qu'une restauration démarre vraiment, comptes d'accès compris.