Les sauvegardes avec SQL SERVER.

Votre entreprise ou organisme a installé des instances de bases de données SQL SERVER pour le développements de nouvelles applications et vous vous apprêté à mettre tous les efforts pour migrer en production ces applications.

Dans vos plans de migration en production, avez-vous planifiés des plans de sauvegardes et de recouvrements de vos bases de données dans le cas de pannes matériel ou de problème logiciel. Quel est le volume de données que vous êtes prêts à perdre (5 minutes, 1 heure, 1 journée) ? Selon la réponse, vous devrez ajuster votre scénario de sauvegarde.

Des méthodes de sauvegardes sont multiples avec SQL SERVER. Sauvegarde complète, incrémentale ou transactionnelle. La première méthode consiste à prendre en copie la base de données au complet. Le mode incrémental permet de prendre les modifications depuis la dernière sauvegarde incrémentale ou complète. Et pour finir la sauvegarde transactionnel permet de prendre une copie du journal des transactions à plusieurs périodes dans le temps.

Toutes ces méthodes de sauvegarde sont étroitement liées au mode de recouvrement à laquelle la base de données est configurée. Pour le mode de sauvegarde complet, il s’applique dans tous les modes de recouvrement. Pour les méthodes incrémentales et transactionnelles, la base de données devant être sauvegardée avec ces méthodes doivent être en mode complet ou en « bulk-logged » (difficile à traduire)

Il est certain que le mode de recouvrement complet permet une plus grande souplesse mais requiert également un plan de gestion des journaux de transactions. Le mode simple est vraiment simple, on peut revenir qu’avec la dernière sauvegarde complète. Le mode « Bulk-logged » permet de restaurer toutes les transactions sauf celles qui ont été faites au moyen d’insertion massives (Bulk Insert). Une gestion des journaux de transaction est également à prévoir.

Lorsque nous parlons de gestion du journal de transactions, cela signifie la surveillance de l’accroissement de ce dernier. Pour permettre de le diminuer, il suffit de sauvegarder le journal de transaction et d’effectuer une diminution (Shrink) des fichiers du journal de transaction.

Voici un scénario à laquelle nous pouvons appliquer ces méthodes de sauvegardes.

Vous avez une instance de bases de données contenant les bases de données systèmes (master, msdb, model et tempdb) et 1 bases de données utilisateur contenant 500 Gb de données avec un accroissement continuel. Les méthodes de sauvegardes que nous pouvons appliqués sont :

• 1 sauvegarde hebdomadaire complète des bases de données système excluant tempdb car celle-ci est détruite et recréé à chaque fois que le service SQL est redémarré. Les changements aux bases de données systèmes sont minimes donc en ayant une sauvegarde de données à chaque semaine, le risque de perte de données est minime.

• 1 Sauvegarde complète hebdomadaires de la base de données utilisateur.
• 1 sauvegarde incrémentale journalière.
• 1 sauvegarde transactionnelle aux 15 minutes.

Dans la plupart des cas, les systèmes en entreprises sont moins achalandés les fins de semaines donc il est souhaitable de faire la sauvegarde complète dans la nuit du samedi au dimanche. La sauvegarde complète requiert plus de temps que les autres sauvegardes, c’est pour cela, qu’en règle générale sur les grosses bases de données nous les sauvegardons que les fins de semaines.

Les autres jours de la semaine une sauvegarde incrémentale sera alors faite en tenant compte des modifications effectuées depuis la dernière sauvegarde complète ou incrémentale. Étant données que votre base de données est modifiée régulièrement avec des données critiques, nous voulons perdre que 15 minutes de données en cas de pannes. Donc pour cela, une sauvegarde des journaux de transactions est également faite aux 15 minutes. Cette méthode de sauvegarde nous permet de limiter l’accroissement du journal de transaction et également de conserver une copie de ces derniers sur disque ou sur autre support magnétique.

Avec ce genre de scénario de sauvegarde il faut s’assurer que les données soient disponibles et en sécurité. Le choix du ou des supports magnétiques est primordiale (disque, ruban). Une évaluation par l’administrateur de base de données (DBA) devra être effectuée afin de s’assurer que la restauration pourra être complétée peut importe la situation de panne.

En bref, pour effectué la restauration complète, nous devons avoir entre les mains les sauvegardes suivantes : La dernière sauvegarde complètes, toutes les sauvegardes incrémentales ainsi que tous les journaux de transactions. Cela complexifie la restauration de la base de données en problème. C’est pour cela que la documentation des différentes bases de données doit être tenue à jour continuellement.

Une gestion assidue des sauvegardes ainsi que de la gestion des supports magnétiques (ruban en autre) doit être suivi quotidiennement avec la tenue d’un registre des sauvegardes. Ce registre des sauvegardes devra indiquer l’endroit où se retrouve le support magnétique (Voûtes, salle des serveurs). Cette gestion vous permettra d’être réactif en cas de crise et de mieux contrôler le temps de restauration de votre base de données critique. Dans bien des entreprises ou organisme, l’administrateur de bases de données est dépendant des personnes qui gèrent les supports magnétiques.

D’autres solutions de hautes disponibilités sont également disponible mais seront traités ultérieurement.

Bonne élaboration de plan de sauvegarde!