Trop souvent, je vois des gens poser des questions sur les stratégies de sauvegarde qu'ils devraient utiliser pour leurs bases de données. Cela ne semble jamais échouer, chaque question de ce type que j'ai rencontrée dans une variété de forums n'inclut jamais leurs exigences de récupération. J'ai souvent hésité à prendre en compte vos exigences de récupération avant de concevoir votre stratégie de sauvegarde. Lorsque je suis pressé pour les exigences, j'obtiendrai souvent des exigences de sauvegarde, par exemple :
- Les sauvegardes ne doivent introduire aucun temps d'arrêt
- Besoin de pouvoir sauvegarder les journaux redo archivés
- Les sauvegardes doivent être écrites sur bande
Ces exigences sont bonnes, mais à mon avis, vous ne devriez jamais concevoir votre stratégie de sauvegarde sans d'abord documenter vos exigences de récupération et obtenir l'occurrence de la gestion.
Voici donc quelques questions que je me pose lors de la conception d'une stratégie de sauvegarde. Notez que ces questions sont toutes axées sur le côté récupération des choses.
- Combien de pertes de données puis-je me permettre lorsque je restaure la base de données ? Zéro perte de données ? Une heure de perte de données est-elle acceptable après la restauration de la base de données ?
- Dois-je reporter des transactions, c'est-à-dire effectuer une restauration ponctuelle ?
- Dois-je restaurer le contenu d'un schéma tout en laissant les autres schémas intacts ?
- Combien de temps me reste-t-il pour que la base de données soit opérationnelle après une panne ?
- De quels types d'échecs dois-je me remettre ? Évidemment, je dois pouvoir restaurer à partir d'une panne complète du serveur ou de la perte d'un disque. Mais ai-je besoin d'être en mesure de me remettre d'échecs humains comme quelqu'un qui a accidentellement supprimé une table ?
- Vais-je devoir restaurer la sauvegarde sur d'autres serveurs dans le cadre de l'actualisation des bases de données de développement ou de test à partir d'une copie de production ?
Si vous demandez à la plupart des membres de la communauté Oracle de nos jours, ils vous diront d'utiliser RMAN pour sauvegarder votre base de données. RMAN est un excellent produit et, à bien des égards, il est meilleur que les anciennes sauvegardes à chaud ou à froid gérées par l'utilisateur. Certains administrateurs de base de données Oracle vous diront d'utiliser RMAN pour effectuer des sauvegardes à chaud et exécuter votre base de données de production en mode journal d'archivage. Ce faisant, vous couvrirez de nombreux scénarios de récupération auxquels vous êtes susceptible de faire face. Mais que se passe-t-il si votre réponse à la question 4 est que vous avez 1 heure pour vous remettre en marche et que votre base de données a une taille de 10 To. Bonne chance pour essayer de faire une restauration complète d'une base de données de 10 To en 1 heure avec RMAN. Et RMAN ne pourra pas répondre à la question 3, car RMAN ne sauvegarde pas au niveau du schéma.
De nombreux outils sont à la disposition du DBA pour sauvegarder et récupérer les données de la base de données. Ces outils incluent, mais ne sont pas limités à :
- Gestionnaire de récupération d'Oracle (RMAN)
- Sauvegardes gérées par l'utilisateur Oracle
- Exportation/importation Oracle ou Data Pump
- Instantanés sur disque
- Réplication sur disque
- Protection des données d'Oracle
Alors, lequel utilisez-vous? Eh bien, chacun a ses avantages et ses inconvénients. Une fois que vous connaissez vos exigences de récupération, les outils pour sauvegarder votre base de données commencent à devenir plus clairs. Et vous devrez peut-être utiliser plus d'un outil de sauvegarde pour répondre à toutes vos exigences de récupération. Si vous utilisez, comme suggestion, RMAN avec le mode Archive Log et rien d'autre, et que votre responsable vient vers vous et vous dit "vous devez remettre cette base de données de 10 To en état de fonctionnement en 1 heure !" votre travail pourrait bien être en jeu.
Ce qui nous amène au point suivant, documentez vos exigences de récupération et intégrez-les dans votre contrat de niveau de service (SLA). Lors de la rédaction et de la vérification du SLA, votre direction peut dire qu'elle ne veut aucune perte de données. C'est à ce moment que vous pouvez évoquer le pour et le contre de la mise en place d'une solution zéro perte de données… et aussi évoquer les coûts ! De nombreuses entreprises rechignent au coût élevé d'une solution sans perte de données, mais pour d'autres entreprises, le coût est faible par rapport au fardeau financier de la perte d'une transaction. C'est là que le marchandage et le troc entrent en jeu. Si la direction insiste sur une solution sans perte de données, elle doit trouver les fonds pour la prendre en charge car RMAN (gratuit) ne la fournira pas. Une fois que vos exigences de récupération sont documentées dans le SLA, il sera difficile pour la direction de vous demander de récupérer quelque chose que votre stratégie de sauvegarde n'est pas conçue pour prendre en charge. Si le SLA est en place et qu'ils vous demandent de récupérer chaque transaction et que votre stratégie de sauvegarde ne le permet pas, alors vous avez un document qui dit qu'aucune perte de données n'a jamais été nécessaire et cela peut vous aider à sauver votre travail.
Cela étant dit, une fois que vous avez documenté vos exigences de récupération dans le SLA, assurez-vous que votre stratégie de sauvegarde vous permettra d'effectuer tous les scénarios de récupération documentés dans le SLA. Votre travail peut en dépendre. Si le SLA stipule qu'il n'y a aucune perte de données et que vous n'implémentez pas Data Guard même si la direction était disposée à le financer, ils pourraient vous licencier parce que vous n'avez pas donné suite à votre travail.
Enfin, aucune stratégie de sauvegarde/récupération n'est complète si elle n'a pas été soigneusement testée. Vous devez tester chaque stratégie de récupération requise pour vous assurer que vous pouvez répondre à toutes les exigences énoncées dans le SLA. Les tests doivent être effectués au moins une fois par an pour deux raisons… premièrement, garantir que les modifications apportées au système n'ont pas d'impact négatif sur votre capacité à effectuer une récupération requise et deuxièmement, vous tenir au courant de la manière d'effectuer la récupération afin que si vous devez le faire pour de vrai, vous ne cherchez pas la procédure. Lors des tests, vous constaterez peut-être que votre méthodologie de sauvegarde prendra en charge les scénarios de récupération requis, mais qu'il est utile de les avoir si vous en avez besoin.
Et je ne le dirai jamais assez… Testez, testez et testez !
