Votre cabinet
Vous choisissez la plateforme de sauvegarde et la politique de rétention, décidez ce qui compte comme un résultat de test de restauration acceptable, et nommez qui doit être informé immédiatement si un test de restauration échoue.
Sauvegarde et reprise Backup & disaster recovery
La sauvegarde tourne déjà quelque part chez la plupart des clients; ce qui manque habituellement, c’est quelqu’un qui vérifie qu’elle a réussi, et quelqu’un qui a vraiment essayé une restauration. Cette page nomme la surveillance des sauvegardes et les tests de restauration planifiés comme leur propre volet chiffré et récurrent — avec le même artefact récurrent et la même escalade vers un responsable désigné que toute autre demande sur ce site, pas un projet ponctuel.
Vous choisissez la plateforme de sauvegarde et la politique de rétention, décidez ce qui compte comme un résultat de test de restauration acceptable, et nommez qui doit être informé immédiatement si un test de restauration échoue.
On confirme que les travaux de sauvegarde convenus se sont vraiment terminés, on exécute le test de restauration planifié selon la politique que vous avez fixée, et on escalade un test échoué de la même façon qu’on escalade tout autre risque — avant le prochain cycle de sauvegarde, pas après.
Pour un client qui a déjà une sauvegarde active — locale, dans le nuage, ou les deux — mais dont l’état de complétion des travaux et la fiabilité des restaurations n’ont jamais été vérifiés selon un horaire.
Un accès en lecture à l’historique des travaux de la plateforme de sauvegarde (ou un chemin de rapport défini), la politique de rétention et l’attente de délai de restauration que vous voulez appliquer, et un responsable désigné pour un test de restauration échoué ou un travail qui échoue silencieusement.
Ce que vous recevez: Une sauvegarde vérifiée selon un horaire plutôt que supposée fonctionnelle — et un test de restauration avec un résultat réel, pas seulement un journal de travaux qui dit « terminé ».
Ce qu’on vous remet: Une note récurrente de sauvegarde et de test de restauration, dans la langue déclarée du compte, qui nomme ce qui a été testé et le résultat obtenu.
Un fichier qui s’ouvre et un système qui redémarre dans un état utilisable sont deux barres différentes. Convenez de ce qu’un test de restauration réussi doit vraiment démontrer avant que le premier test ne s’exécute.
Combien de données un client peut se permettre de perdre, et combien de temps il peut rester hors service, change la fréquence de sauvegarde et la méthode de restauration appropriées — c’est une décision d’affaires, pas un défaut technique.
Une application métier avec sa propre base de données, ou un système qui vit hors de l’environnement principal, doit être nommé explicitement — « on sauvegarde le serveur » ne veut pas automatiquement dire que tout ce qu’il contient est restaurable.
Un seul fichier à restaurer et une panne à l’échelle du site ne sont pas la même demande. Nommez la ligne entre « consigner et retester au prochain cycle » et « escalader maintenant » avant qu’une vraie panne n’oblige à la tracer en plein incident.
Non. Ça fonctionne avec la plateforme et l’horaire de sauvegarde que votre client a déjà — on surveille et on teste par rapport à ça, on ne vend ni n’exige un outil en particulier.
Ça va au responsable désigné comme une escalade, de la même façon qu’un correctif échoué ou qu’une exception de sécurité — avec ce qu’on sait de la cause, pour que votre cabinet décide de la suite. Ça ne se reprogramme pas discrètement pour le prochain cycle.