Depuis plusieurs années, tous les experts en cybersécurité insistent sur le fait de disposer d’une copie étanche des données sous forme de sauvegarde du SI.
Quelle que soit la technologie utilisée, cette stratégie de cyber-résilience doit empêcher qu’une cyber-attaque sophistiquée (prise de contrôle de l’AD, élévation de privilèges sur les serveurs, …) permette aux cyber-attaquants de corrompre ou de détruire cette copie de sauvegarde étanche.
Il existe plusieurs approches technologiques pour gérer cette étanchéité :
Quelques soient les technologies utilisées, on voit que globalement, les entreprises ont compris l’enjeu de se protéger via ce dernier niveau de sauvegarde.
Historiquement, les politiques de sauvegarde ressemblaient peu ou prou à cela :
Naturellement, cette sauvegarde se faisait en local : soit sur des appliances spécialisées, soit des espaces de stockage NAS ou SAN ou soit via des bandes/cartouches.
Pourquoi continuer à garder en local alors que la sauvegarde locale génère de nombreuses contraintes (financières, qualité, …) ?
Pour d’excellentes raisons dans des contextes particuliers :
Mais pour la majorité des entreprises ou organismes, cela reste-t-il toujours pertinent ?
Si on analyse les besoins en termes de délai de restauration, on se rend compte que les restauration urgentes sont exclusivement des besoins de restauration sur des données récentes (le plus souvent du dernier état de la sauvegarde réalisée), telles que :
Dans ces différents cas, il faut privilégier la vitesse de restauration des données. Les mécanismes de sauvegarde en local et de restauration locale sont évidemment pertinents car le débit du LAN ne constitue pas un goulot d’étranglement.
Dans un contexte de sauvegarde dans un Cloud (ou Datacenter externalisé), la durée de restauration d’une sauvegarde externalisée sera toujours limitée par le débit du réseau WAN.
Il reste donc toujours pertinent de garder en local une profondeur de sauvegarde des 7 derniers jours par exemple.
En revanche, les besoins de restauration d’une version de base de données qui date de plusieurs semaines, ou d’un ensemble de fichiers datant de 12 mois sont rares, voire extrêmement rares (et sont souvent pour répondre à des besoins d’ordres réglementaires ou métier).
Alors les besoins de délais de restauration ne sont jamais immédiats et il est possible d’accepter une durée de 8 ou 24 heures pour restaurer ces données.
Dans ce contexte, il n’est généralement pas nécessaire d’avoir une grande profondeur de sauvegarde en local pour couvrir les besoins des métiers.
D’un point de vue besoin métier, disposer de durées de rétention longues en local est très souvent inutile.
Dans un contexte d’augmentation des données difficile à contenir et qui a un impact direct sur les besoins d’espace de sauvegarde local (et les coûts liés), il est certainement pertinent de repenser sa politique de sauvegarde.
La stratégie de sauvegarde qui consiste à conserver en local de longues durées de rétention semble perdre sa pertinence suivant l’évolution du contexte de la sauvegarde.
D’autant plus que d’avoir des sauvegardes anciennes dont on ne teste jamais la restauration, ou le redémarrage, donne un niveau de garantie faible sur la capacité à pouvoir les restaurer un jour !
Utiliser les technologies Cloud pour conserver les rétentions longues des sauvegardes offre de nombreux atouts :
Si chaque contexte d’entreprise est différent, il semble pertinent au moins de se poser la question : N’est-il pas temps de repenser ma stratégie de sauvegarde ?
Dans un prochain article, nous analyserons les nouveaux critères à intégrer dans une politique de sauvegarde.
76 rue Denfert-Rochereau
69004 Lyon
Tel : 04.28.29.79.01
© 2014–2022 NUABEE. TOUS DROITS RÉSERVÉS.
Cookie | Durée | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |