The Doppler Quarterly (FRANÇAIS) Été 2018 | Page 63

Des défi nitions pour assurer que vos
solutions de sauvegarde soient rentables,
performantes et vraiment conformes aux
besoins de votre activité.
Les services de sauvegarde et récupération après sinistre (DR) et de planifi cation ne
sont pas particulièrement enthousiasmants, mais ils ne manquent pas de susciter une
certaine excitation lorsqu’aucun plan de sécurité et de robustesse des données appro-
prié n’a été élaboré. Lorsque le sujet de la reprise après sinistre se pose, beaucoup de
gens (même ceux qui devraient être le plus au courant !) imaginent encore des bandes
magnétiques en rotation qui doivent être dépêchées sur une installation de stockage
hors site. Il est vrai qu’il existe des environnements où cette approche de la sauvegarde
et de la restauration est encore employée ; mais on trouve désormais des options indu-
bitablement plus effi caces, fi ables et rentables de sauvegarde et de DR, surtout en
matière de stockage dans le cloud.
À cet égard, certains termes sont souvent utilisés indifféremment, alors qu'ils revêtent
en réalité des signifi cations différentes et distinctes. Il n'est donc pas superfl u de les
passer à nouveau en revue.
Sauvegarde/restauration
Ce terme vise principalement les données elles-mêmes, et non les applications. Les
solutions adoptées tendent à reposer sur un stockage d'objet robuste (Amazon S3 ou
Azure Blob Storage). Elles adoptent souvent une approche multicouche composée de
données « tièdes » (quantités de données plus réduites qui peuvent être restaurées rapi-
dement) et de données « froides » (plus grande quantité de stockage archivée, moins
chère à restaurer, mais dont l'accès prend plus de temps et est plus coûteux).
Reprise après sinistre
Ce terme est centré sur les applications et nécessite de prendre en compte à la fois la
couche de données et la pile applicative. Les conceptions proposées doivent être parées
pour un large éventail de défaillances. Les solutions varient considérablement selon la
vitesse à laquelle l’application doit être remise en service après une défaillance (objectif
de temps de récupération, ou RTO), ainsi que de la durée pendant laquelle la perte des
données applicatives est tolérable (objectif de point de récupération, ou RPO). Il est à
noter qu’il n’existe pas d’option « meilleure » que les autres, mais uniquement des solu-
tions qui conviennent le mieux aux besoins spécifi ques de chaque situation. Ces options
sont les suivantes :
ÉTÉ 2018 | THE DOPPLER | 61