Retour aux archives

Archive

Publication historique ou contenu de 30 jours ou plus.

Sauvegarde Cloud : définir ce qu’il faut restaurer

Archive publiée en 2015. Ce contenu décrit son époque et ne constitue pas une recommandation technique ou une présentation de l’offre actuelle.

Illustration symbolique : Sauvegarde Cloud : définir ce qu’il faut restaurer

Une sauvegarde devient utile le jour où une personne retrouve une donnée exploitable dans le délai prévu. Un voyant vert indique qu’une opération s’est terminée ; il ne démontre pas que l’application redémarrera, que les droits seront corrects ou que l’équipe saura quoi faire pendant l’interruption.

Le point de départ est donc une question métier : qu’est-ce qui doit pouvoir reprendre, avec quelle perte de travail acceptable ? La réponse détermine les moyens à mettre en place et les essais à organiser.

Décrire les données avant de choisir l’outil

Construisez un inventaire simple : ensemble de données, emplacement réel, responsable, dépendances et méthode de récupération envisagée. Incluez les dossiers locaux, serveurs, bases, documents partagés et applications hébergées. Une personne peut travailler dans Teams alors que ses fichiers sont stockés dans SharePoint ; le nom de l’interface ne suffit pas à définir le périmètre protégé.

Pour chaque ensemble, distinguez quatre besoins : retrouver un fichier effacé, revenir avant une corruption, reconstruire une application et reprendre après l’indisponibilité d’un site. Ils ne se vérifient pas avec le même exercice. Une synchronisation peut propager une suppression ; un historique de versions peut aider sans constituer une copie indépendante couvrant toute l’application.

Azure Backup prend en charge plusieurs charges Azure et locales selon des mécanismes propres à chacune. Une VM protégée ne signifie pas que tous les services SaaS du même abonnement ou de la même organisation le sont. La matrice du produit et de la charge concernée reste le document à vérifier avant de s’engager.

Fixer deux objectifs compréhensibles

La perte de données acceptable correspond à l’ancienneté maximale du point que vous accepteriez de restaurer. Le délai de reprise comprend la détection, la décision, la restauration puis la validation par les utilisateurs. Présentez-les avec des situations de travail, plutôt qu’avec deux seuls acronymes techniques.

Exemple illustratif : un bureau d’études souhaite retrouver ses dossiers du matin avant la reprise du lendemain. Il faut déterminer si les documents seuls suffisent, ou si les logiciels, comptes et modèles sont également indispensables. Ce scénario proposé n’est ni une mesure de performance ni un engagement de service Valor.

Arbitrez aussi la durée de conservation, la localisation des copies, les autorisations d’administration, le stockage et le coût des restaurations. Prévoyez qui peut supprimer une protection ou modifier sa politique, et comment une erreur de configuration serait repérée.

Faire un essai qui prouve quelque chose

  1. Choisissez une donnée représentative, avec son propriétaire et un résultat attendu écrit avant l’essai.
  2. Sélectionnez un point de restauration et une destination d’essai distincte de la production lorsque le produit le permet.
  3. Relevez le temps nécessaire pour retrouver les accès et lancer l’opération, puis celui de récupération.
  4. Ouvrez les fichiers ou l’application, contrôlez leur cohérence et vérifiez les autorisations avec le compte de l’utilisateur prévu.
  5. Faites valider le résultat métier et consignez les éléments absents, les manipulations manuelles et les dépendances découvertes.

Une base restaurée mais inutilisable par l’application reste un essai incomplet. Un document accessible uniquement à l’administrateur ne valide pas le retour au travail. N’écrasez pas les données courantes pour simplifier un exercice.

Le livrable à conserver

Gardez une fiche de reprise accessible même si l’environnement principal est indisponible : périmètre, responsable de décision, accès de secours, procédure, preuve du dernier test et prochaine révision. Un changement d’application, de propriétaire ou de politique doit déclencher la question d’un nouvel essai.

La sauvegarde des données et l’organisation d’un basculement de service sont deux chantiers liés. Microsoft distingue Azure Backup et Azure Site Recovery pour ces objectifs. Commencez par le scénario à réussir avant de multiplier les outils.

Sources et prolongements