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