Les technologies de sauvegardes/restauration font parti de ces domaines les plus entourés de mythes et légendes en tout genre. L’importance des investissements des entreprises dans ces domaines et la créativité des équipes marketing des multiples acteurs en est sans doute la cause. La vérité est souvent contextuelle et dépend des stratégies mises en oeuvre que des produits.

La question « Comment sauvegarder une base de données ? » ne vient pas en premier dans la mise en oeuvre d’une stratégie de sauvegarde/restauration. Les premières questions sont « Pourquoi sauvegarder vos bases de données ? » et pour chacune de ces raisons « Quel est l’impact d’une indisponibilité (temporaire ou définitive) des données ? ».

Autrement dit, ce qui compte pour choisir une stratégie de sauvegarde/restauration de ce sont, dans l’ordre :

• les causes possibles de pertes de vos données,
• l’impact et la probabilité associés à la perte et/ou à l’indisponibilité des données,
• l’investissement nécessaire pour prévenir l’indisponibilité en regard du risque encouru en cas de perte de toute ou partie des données, même temporaire.
• les objectifs de temps de restauration (RTO : Recovery Time Objectives) et des données que l’on accepte de perdre en cas de restauration(RPO : Recovery Point Objectives)
• les techniques de sécurisation qui faut mettre en oeuvre

Il ne faut pas oublier non plus que la stratégie de sauvegarde/restauration n’est qu’une composante d’une stratégie de sécurisation des environnements. Si possible, ces stratégies doivent être cohérentes : Pourquoi investir pour être capable de restaurer en cas de perte d’une baie en moins de 2 heures s’il faut 3 jours pour disposer d’une baie de secours ? Pourquoi constituer une restauration capable de repartir en quelques minutes si le système d' »alerting » et les équipes d’exploitation ne sont pas capables de prendre des décisions en moins de 4 heures ? Ne faut-il pas dimensionner correctement l’infrastructure pour que l’application soit « utilisable », c’est à dire performante et également prévoir la perte de la machine de base de données, du réseau ou de l’application ?

Enfin, la copie de bases de données pour constituer des environnements de tests, de recettes ou de pré-production influence souvent la stratégie de sauvegarde/restauration choisie. En effet, la solution retenue peut être basée sur les mêmes composants techniques dans la mesure où ces problèmes sont proches, a priori (quoique…).

Les causes possibles de pertes de données :
Voici quelques exemples de causes de pertes de données contre lesquelles il faut se prémunir :

• La perte de tout ou partie des données du fait d’une panne de l’un des SPOF (single point of failure) ou d’une panne double
• La perte d’une partie des données (fichiers ou tablespaces) dûe à une erreur de manipulation ou à un problème des logiciels et matériels (suppression d’un fichier, bug dans un filesystem, volume manager ou d’une baie de stockage)
• La perte d’une partie des données (ensemble de blocs qui sont alors dit « corrumpus ») dûe à un problème des logiciels et matériels de l’infrastructure base de données (e.g. bug dans un driver I/O, du système ou d’une instance de la base de données)
• Une erreur humaine ou de l’application qui nécessite de faire revenir votre système ou une partie de votre système à une date précédente dans le temps (PITR : Point In Time Recovery)
• Une perte de la totalité de l’infrastructure du fait d’un désastre (incendie, dégât des eaux, attentats)

Administrateur, effectuez des manipulations en production
Dès la création d’une base de données, il est indispensable de mettre en oeuvre une stratégie de sauvegarde/restauration et à chaque manipulation que vous effectuez sur un environnement de production, il faut se poser les questions suivantes :

• Que peut-il m’arriver de pire et quelles seraient les conséquences si ça arrivait ?
• Qu’est-ce que je suis en mesure de reconstituer ?

Mauvaises idées à propos des sauvegardes/restauration :
Voici quelques idées souvent rencontrées et pour lesquels – réfléchissez-y bien !- il est assez facile de trouver des contre-exemples :

• Les technologies de type « split-mirror » sont les plus rapides pour restaurer des environnements.
• Il faut éviter les impacts des sauvegardes sur les environnements de production.
• Les technologies matérielles n’impactent pas le système de production.
• Les technologies de sauvegardes/restauration ne sont pas capables de monter en charge.
• Les technologies de compression sont le meilleur vecteur pour réduire la taille des sauvegardes

Il en existe beaucoup d’autres… N’hésitez pas à enrichir ces exemples de vos expériences !

G-ArK!