SQL Server

Présentation des sauvegardes SQL Server

Paul S. Randal

En un coup de œil :

• Sauvegardes complètes
• Sauvegardes du journal des transactions
• Sauvegardes différentielles
• Planification de la stratégie de sauvegarde et l'intégrité de la sauvegarde

Contenu

Sauvegardes complètes
Sauvegardes différentielles
Sauvegardes du journal des transactions
Planification de stratégie de sauvegarde
Sauvegarde de l'intégrité
Résumé

Avez-vous vraiment besoin tirer les sauvegardes SQL Server ? Oui. À moins que vous importe peu sur vos données ou que vous ne dérange pas avoir à recréer entièrement votre base de données en cas d'incident, il vous faut certains moyen de restaurer la base de données à un point utilisable. Certaines personnes prétendent qu'avoir une copie redondante de la base de données ailleurs supprime la nécessité des sauvegardes, mais que se passe-t-il si cela copie est endommagé ou inaccessible ? Les sauvegardes sont nécessaires pour vérifier que vous pouvez toujours récupérer.

Mais le type de sauvegarde devez-vous prendre ? À quelle fréquence devez-vous prendre les ? Effet qu'ils auront sur la base de données et la charge de travail ? Et comment vous assurez-vous qu'ils sont valides ?

Mise en place une stratégie de sauvegarde est en fait plus facile que vous pouvez penser, même si les commandes BACKUP et RESTORE ont une multitude d'options. Et je vous figure tout en vous aider.

Il s'agit du premier article d'une série de trois parties. Ici, dans la première partie, je traite les sauvegardes. Partie 2 (numéro de septembre 2009), j'aborderai récupération suite à un incident à l'aide de sauvegardes. Et dans la partie 3 (numéro de novembre 2009), vous allez Examinez récupération d'urgence sans sauvegarde. Je vais faire un peu plus que d'habitude dans ces articles, mais vous devez en mesure de suivre l'aide de la documentation.

Dans l'article de ce mois-ci, j'expliquerai les principes fondamentaux de la les différents types de travail de sauvegarde et comment vous pouvez les utiliser dans une stratégie de sauvegarde. Il aidera si vous avez une connaissance du fonctionne du journal des transactions (voir mon article» Enregistrement de comprendre et de récupération dans SQL Server." Il est inutile de disposer de sauvegardes si elles deviennent pour être endommagé lorsque vous essayez de les utiliser, afin que vous allez expliquent également comment ajouter certaines intégrité vérifie les. En cours de route, je vous debunk certaines des idées reçues et fournissent des liens vers plus d'informations.

Je ne vais pas faire est expliquent comment fonctionne la syntaxe de la sauvegarde et comment effectuer les différents types de sauvegarde. DOCUMENTATION en ligne a été excellentes sections couvrant ce pourquoi donc gaspille espace duplication ici ? Voir la rubrique" Sauvegarde (Transact-SQL)"pour plus d'informations, en particulier la section exemples à la fin. La rubrique" Sauvegarde et restauration de rubriques Comment (SQL Server Management Studio)"explique comment utiliser les outils pour effectuer des sauvegardes. Il est préférable de consulter la procédure après avoir lu cet article, comme ici je vais vous expliquer l'et la raison.

L'implémentation de votre stratégie de sauvegarde est la partie relativement simple. Conception d'une stratégie efficace est essentiel, mais souvent négligée, partie.

Sauvegardes complètes

Le type de la plus simple de sauvegarde est une sauvegarde complète de la base de données. Il est également possible d'effectuer une sauvegarde complète d'un fichier de données unique ou un groupe de fichiers. Toutefois, ceux-ci ne sont pas couramment utilisés et tous les principes décrits s'appliquent à eux, trop, je vais pour mettre en évidence les sauvegardes au niveau de la base de données. Mais en tant que de SQL Server 2005, chaque type de sauvegarde plus granulaire de fonctionnent exactement la même (cela ne était pas true dans SQL Server 2000). La même règle s'applique à sauvegardes différentielles, ils peuvent être effectuées au fichier, le groupe de fichiers ou le niveau de la base de données, mais ces tout le travail de la même façon, ainsi, indépendamment du composant sauvegardé.

Une sauvegarde complète de base de données fournit une copie complète de la base de données et fournit un unique point dans le temps à laquelle la base de données peut être restaurée. Même si elle peut prendre plusieurs heures pour le processus de sauvegarde exécuter, vous pouvez toujours uniquement restaurer la sauvegarde à un point unique (efficacement à la fin de la sauvegarde, mais j'aborderai exactement quoi que point se trouve plus loin dans cet article). Une sauvegarde complète n'autorise pas n'importe quel point la récupération en temps lors de l'exécution la sauvegarde. C'est également le même pour les sauvegardes différentielles.

Il existe une idée fausse sur ce sujet, cependant, fuelled par le fait que vous pouvez utilisent le WITH STOPAT = < une fois ou journal souche de numéros > option sur une restauration de sauvegardes complètes et différentielles. Bien que la syntaxe permette d'elle, l'option n'a aucun effet et est simplement là pour des raisons de commodité.

Une autre idée fausse sur les sauvegardes intégrales est qu'ils contiennent uniquement des données. Les sauvegardes complètes et différentielles contiennent également des certains enregistrements de journal des transactions afin que le composant restauré (base de données, fichier ou groupe de fichiers) peut être apportée cohérent.

Envisagez une transaction d'exemple qui insère un enregistrement dans une table comportant un seul index non ordonnés en clusters. Les pages de la table et index sont répartis dans le fichier de données. La transaction est divisée en deux parties en interne : un enregistrement d'insertion dans une page données de la table, puis sur l'insertion de l'enregistrement requis dans une page d'index dans l'index non ordonnés en clusters. Si le processus de sauvegarde se trouve de lire la page index non ordonnés en clusters avant l'insertion d'enregistrement uniquement, mais lit la page de données de table après l'insertion d'enregistrement, la base de données représenté par que les données de la sauvegarde est mode transactionnel incohérente.

C'est dans lequel le journal des transactions. En incluant également certains enregistrements de journal des transactions dans la sauvegarde, récupération peut être exécutée sur la copie restaurée de la base de données, rendant cohérentes. Pour cette transaction exemple, en fonction de quand elle est validée, la partie restauration récupération peut reprendre il (ce qui signifie qu'il apparaîtra comme validé dans la copie restaurée de la base de données) ou annuler il nouveau (ce qui signifie qu'il n'apparaît pas du tout dans la copie restaurée de la base de données). Dans les deux cas, la cohérence transactionnelle qui est essentiel est conservée.

Une sauvegarde complète effectue les opérations suivantes :

1. Forcer un point de contrôle de base de données et prenez note du journal de numéro de séquence à ce stade. Cela vide toutes les pages mises à jour en mémoire sur le disque avant que quoi que ce soit est lu par la sauvegarde afin de réduire la quantité de travail qu'est la partie restauration récupération.
2. Démarrer lors de la lecture à partir de fichiers de données dans la base de données.
3. Arrêter de lire à partir des fichiers de données et créer une note du numéro séquence de journal de début de la plus ancienne transaction active à ce stade de (voir mon article «Understanding enregistrement et récupération dans SQL Server» pour obtenir une explication de ces termes).
4. Lire autant journal des transactions comme c'est nécessaire.

Expliquant quel journal des transactions est nécessaire est mieux effectuée à l'aide visuelle dans la figure 1 . Les numéros de rouges sur la barre de planning sont expliqués dans cette liste :

1. Point de contrôle et commencer la lecture de la base de données.
2. L'opération de lecture lit page X.
3. UNE transaction démarre.
4. Transaction A modifie page X. La copie de la sauvegarde est maintenant obsolète. Notez que la sauvegarde ne lira pas page X à nouveau, il est déjà passé ce point dans la base de données.
5. Transaction B démarre. Il ne termine pas avant que les données lues terminée.
6. UNE transaction est validée. Il valide les modifications à la page X.
7. Les données de sauvegarde lire opération se termine et journal des transactions lors de la lecture commence.

La figure 1 exemple de chronologie des modifications pendant une sauvegarde complète

Sauvegarde suffisante du journal des transactions est nécessaire afin que récupération peut correctement exécuter pendant la restauration et que toutes les pages dans la base de données sont au même point dans le temps, l'heure à laquelle les données de lecture de partie de l'opération de sauvegarde terminée (7 point). Le journal des transactions à partir du début de la plus ancienne actif (ou non validée) transaction (point 5, transactions B) la fin de la sauvegarde (point 7), est nécessaire pour permettre la récupération à exécuter. Le journal des transactions à partir de la sauvegarde point de contrôle (Point 1) à la fin de la sauvegarde (7 point) est requis pour autoriser toutes les pages à être mis au même point dans le temps.

Mis à si le journal des transactions ont été inclus uniquement à partir de début de la transaction active la plus ancienne (point 5), puis la copie de page X qui a été restaurée à partir de la sauvegarde lire au point 2 ne serait pas jour avec les modifications de transaction A, qui s'est produite à point 4. Cela signifie qu'il ne serait pas être cohérente avec le reste de la base de données lors de la l'opération de lecture des données terminée (point 7).

Par conséquent, le numéro de séquence minimale journal (LSN) du journal de transaction qui est inclus dans la sauvegarde complète est MIN (LSN de sauvegarde point de contrôle, LSN de transaction active la plus ancienne) et il peut s'agir d'une transaction a commencé avant même que la sauvegarde a commencé. Ceci garantit que la copie restaurée de la base de données (ou tout ce que vous avez restauré, page, de fichiers, de groupe de fichiers, de base de données) est entièrement cohérente.

Ce mécanisme signifie que transactions sont non suspendues de quelque manière que ce soit par les opérations de sauvegarde, bien que la charge d'e/S supplémentaire sur la base de données risque de ralentir les quelque peu. L'inconvénient de ce mécanisme est que le journal des transactions ne peut pas être désactivée pour la durée de la sauvegarde complète car il est nécessaire. Il y a beaucoup d'activité de mise à jour et la sauvegarde prend beaucoup de temps, cela peut aboutir à croissance du journal des transactions, un problème que j'ai déjà abordés dans plusieurs articles précédents et dans la colonne de forum aux questions SQL.

Les données contenues dans une sauvegarde complète ne sont pas nécessairement tout le contenu de tous les fichiers de données. La sauvegarde ne contient que les pages allouées dans les fichiers de données. Par exemple, une base de données unique fichier peut être de 100 Go mais contenir uniquement des 15 Go de données allouées. Dans ce cas, la sauvegarde ne contient que les 15 Go de données allouées ainsi que le journal des transactions nécessaire. (Toutefois, la base de données restauré sera toujours la même taille que l'original, dans ce cas, 100 Go.)

Une autre idée fausse est que le processus de sauvegarde examine ou les données qu'il sauvegarde les modifications apportées. C'est FAUX, à l'exception dans un seul cas lorsque les totaux de contrôle de sauvegarde est activées, laquelle je reviendrai bientôt.

Sauvegardes différentielles

L'autre type de sauvegarde des données est une sauvegarde différentielle. Une sauvegarde différentielle effectue les mêmes opérations qu'une sauvegarde complète, mais uniquement contient toutes les données qui a modifié ou ajouté depuis la dernière sauvegarde complète. Tort ici est que les sauvegardes différentielles sont incrémentielles. Ils sont réellement cumulatives et successives différentielles après une sauvegarde complète et augmente la taille en fonction de modification ou d'ajouté de données plus.

Dans chaque 4 Go section (appelée un intervalle GAM) de chaque fichier de données il est une page de base de données spéciale appelée un bitmap différentielle répertoriant les portions (appelées Extensions) de cette section 4 Go ont changé depuis la dernière sauvegarde complète, indiquant que les données modifiées ou été ajoutées à la base de données. (Il existe plusieurs autres bitmaps d'allocation, trop, et vous pouvez trouver plus d'informations sur ces éléments dans mon article de blog» Dans le moteur de stockage : GAM, SGAM, PFS et autres cartes d'allocation").

Une sauvegarde différentielle parcourt ces bitmaps et sauvegarde les données à leur uniquement des extensions de fichier qui sont marquées comme modifiées. Les bitmaps sont réinitialisés par la prochaine sauvegarde complète, afin de voir que de plus en plus des modifications de la base de données, plus seront marqués dans les bitmaps différentielles et des sauvegardes différentielles sera plus volumineux et plus. Enfin, si la plupart de la base de données a changé, une sauvegarde différentielle peut devenir aussi grand que la sauvegarde complète. Vous pouvez déterminer la taille votre prochaine sauvegarde différentielle utiliseront un script que j'ai écrit qui est disponible dans mon article de blog» Nouveau script : quelle la base de données a changé depuis la dernière sauvegarde complète ?." Incidemment, ce script peut également servir à faire une idée de l'évolution du taux d'une base de données — par exemple, sur une base de données contenu SharePoint.

Qu'une note de côté, si vous souhaitez effectuer une sauvegarde complète ad-hoc et ont il réinitialise pas les images bitmap différentielles, vous devez utiliser l'option WITH COPY_ONLY dans l'instruction BACKUP. Cela est très utile, que les sauvegardes différentielles suivant pourraient être basées sur l'ad-hoc sauvegarde complète réalise, plutôt que sur la sauvegarde complète (probablement planifiée) régulier. Cela peut entraîner des problèmes de grandes lorsque vous essayez de restaurer dans une situation d'urgence.

Pourquoi les sauvegardes différentielles utile ? Comme j'aborderai dans la section stratégie de sauvegarde, sauvegardes différentielles peuvent vraiment accélérer les opérations de restauration en permettant à de nombreuses transactions sauvegardes du journal ignorée dans le processus de restauration. Il est beaucoup plus rapide d'essentiellement reculer rapidement en utilisant une sauvegarde différentielle que pour avoir à relire de nombreux enregistrements de journal des transactions afin d'obtenir le même point de temps.

Sauvegardes du journal des transactions

Les sauvegardes du journal des transactions sont uniquement possible dans les modèles de récupération FULL ou BULK_LOGGED, tandis que les sauvegardes complètes et différentielles sont également possibles dans le modèle de récupération SIMPLE.

Une sauvegarde du journal des transactions contient tous les enregistrements de journal de transaction générées depuis la dernière sauvegarde du journal (ou sauvegarde complète qui démarre une chaîne de sauvegarde de journaux) est utilisée pour permettre à la base de données à récupérer à partir d'un point particulier dans le temps (généralement le temps droit avant un sinistre). Cela signifie qu'ils sont incrémentiels, contrairement aux sauvegardes différentielles sont cumulatives. Puisqu'elles sont incrémentiels, si vous souhaitez restaurer la base de données à un point particulier dans le temps, vous devez disposer de tous les transactions enregistrements du journal nécessaires pour relire jusqu'à des modifications de la base de données qui pointent dans le temps. Ils figurent dans la chaîne de sauvegarde du journal.

Une chaîne de sauvegarde de journal est une série ininterrompue de sauvegardes de journaux qui contiennent tous les enregistrements de journal transaction nécessaires pour récupérer une base de données à un point dans le temps. Une chaîne commence à une sauvegarde complète de base de données et se poursuit jusqu'à ce que quelque chose interrompe la chaîne, empêchant ainsi plusieurs sauvegardes du journal effectuées jusqu'à ce qu'une autre sauvegarde complète (ou différentielle) est effectuée.

Basculer vers le modèle de récupération SIMPLE, restauration à partir d'une capture instantanée de base de données et force effacement du journal à l'aide des options WITH NO_LOG ou TRUNCATE_ONLY (qui ne sont pas disponibles dans SQL Server 2008) sont des opérations rompre la chaîne de sauvegarde du journal. Il est déconseillé pour rompre la chaîne de sauvegarde du journal, car il force une autre sauvegarde complète (potentiellement grande police) à prendre.

Bien qu'une chaîne de sauvegarde du journal s'étend à une sauvegarde complète, vous ne devez nécessairement restaurer toutes les sauvegardes du journal au cours de récupération. Si vous avez effectué une complète sauvegarde, par exemple, dimanche et mercredi soir, aux sauvegardes de journal toutes les demi-heures depuis dimanche soir, puis en restaurant la base de données après un incident vendredi pourrait utiliser sauvegarde complète du mercredi ainsi que toutes les sauvegardes du journal depuis des mercredi soir au lieu de passer tout sauvegarder sur sauvegarde complète de dimanche soir. (Le deuxième article de notre série va accéder plus profond dans cette rubrique).

Les sauvegardes du journal sont également nécessaires pour aider à gérer la taille du journal des transactions. Dans les modèles de récupération FULL ou BULK_LOGGED, le journal n'effacera pas jusqu'à ce qu'une sauvegarde du journal a été effectuée (voir l'article de février pour plus d'informations de ce que signifie effacement du journal), afin que sauvegardes du journal standard doivent être exécutées pour empêcher le fichier journal de grandir de sortie du contrôle. Si le journal ne peut pas effacer, le journal augmentera jusqu'à ce qu'il soit insuffisant. En tant que tel, si vous ne souhaitez pas récupération point-à-temps à l'aide de sauvegardes du journal, l'option simple est de passer dans le modèle de récupération SIMPLE et de pas utiliser les modèles de récupération FULL ou BULK_LOGGED. Aborder, cela plus en détail dans le billet de blog» Importance de la gestion des transactions approprié journal taille."

Il existe un cas spécial dans l'enregistrement qui améliore les performances en permettant à certaines opérations à exécuter comme opérations journalisées minimales, où les allocations de page sont consignées, pas l'insertion réelle des données. Cela peut améliorer les performances des opérations telles que chargements en bloc et index reconstruit. Dans ce cas, pas tout sur l'opération est connecté, afin que la sauvegarde de journal enregistrements ne contiennent pas suffisamment informations complètement relire l'opération. Dans ce cas, comment peuvent restauration et récupération éventuellement travailler si il n'y pas suffisamment d'informations ?

La réponse est que la première sauvegarde du journal après une opération journalisée contiendra également des données. Comme les images bitmap différentielles je l'ai mentionné précédemment, il est un autre bitmap appelée la bitmap journalisées (parfois appelée le mappage modifié en bloc). Cette bitmap suit les extensions d'un fichier de données ont été modifiées en raison d'une opération journalisée.

La sauvegarde du journal après une opération journalisée analyse via ces bitmaps et sauvegardez également les extensions de données qui sont marquées comme ayant été modifié. Les bitmaps sont effacés après avoir analysé. Cela signifie que la sauvegarde du journal a suffisamment d'informations pour relire complètement les effets de l'opération journalisée dans la base de données, lorsque la sauvegarde du journal est restaurée. Il existe cependant un Zigzag : il y rien dans cette sauvegarde du journal indiquant lorsque n'importe quelle étendue de données particulier a été modifié. Une sauvegarde de journal qui contienne également des données d'une opération journalisée ne peut pas être restauré vers n'importe quel point dans le temps à l'exception la fin de la période couverte (ou au-delà, si la sauvegarde du journal fait partie d'une chaîne de sauvegarde de journal que vous restaurez à partir de). Par conséquent, tandis que vous pouvez obtenir des améliorations de performances lorsque vous basculez vers le modèle de récupération BULK_LOGGED, prenez modification comme une opération temporaire, juste pour améliorer votre processus de traitement par lots et une fois le processus de traitement par lots terminé, vous devez revenir au point et effectuer une sauvegarde journal dès que possible.

Il existe également une sauvegarde de journal cas spécial pour permettre le journal pour être sauvegardées après un sinistre endommage les fichiers de données. Il s'agit une sauvegarde de fin du journal (ou fichier journal), où les fichiers de données peuvent être endommagés ou détruits, mais tout le journal des transactions menant haut le point d'urgence peut être sauvegardé. Cela permet de perte de travail minimale (appelée récupération temps réel) lorsque la base de données est ensuite restaurée ; cependant, il est pris en charge uniquement lorsque la base de données est exécuté dans le modèle de récupération FULL. Plus d'informations sur ces et restrictions des opérations journalisées se trouve dans la rubrique documentation en ligne» Sauvegardes du journal fin." Le premier écran cast qui accompagne cet article montre moi illustrant les sauvegardes de fin du journal.

Dans les versions de SQL Server antérieures à SQL Server 2005, les sauvegardes du journal des transactions Impossible d'effectuer simultanément avec complète de la base de données ou sauvegarde différentielle de base de données, qu'ils s'est bloquée jusqu'à ce que la sauvegarde de niveau de base de données terminée. Fichier et les sauvegardes basées sur le groupe de fichiers ne provoque pas bloquer les sauvegardes du journal. Bien que ceci compliqué le processus de récupération de sauvegardes de fichiers et, il donné les un avantage en bloquant ne pas les sauvegardes du journal. Dans SQL Server 2005, toutes les sauvegardes complètes et différentielles (indépendamment de composant) fonctionnent de la même façon. Le comportement est maintenant que la sauvegarde du journal des transactions simultanées se termine, mais le journal des transactions n'est pas désactivé jusqu'à ce que l'intégralité ou sauvegarde différentielle (qui nécessite le journal) se termine également.

Planification de stratégie de sauvegarde

Maintenant que vous savez sur les trois types de sauvegardes et leur fonctionnement, je vais vous montrer comment vous pouvez placer les ensemble dans une stratégie de sauvegarde.

Une question courante que m'est comment pencher sur une stratégie de sauvegarde. J'apprécie toujours de dire que vous ne devez pas concevoir une stratégie de sauvegarde. Vous devez concevoir une stratégie de restauration, qui permet de restaurer aussi peu que possible en cas d'incident donc votre temps d'arrêt est aussi réduite que possible tout en conservant vos données. Une fois que vous avez travaillé qu'out, puis déterminer les sauvegardes, vous devez pour vous pouvez d'effectuer les restaurations que vous avez besoin. En d'autres termes, votre stratégie de sauvegarde doit vous permettre répondre à votre objectif de temps récupération (RTO) et un RPO (objectif de point de récupération).

Avec une stratégie qui inclut uniquement des sauvegardes complètes vous n'êtes quelque peu limité que vous pouvez faire avec les restaurations. En fait, vous pouvez restaurer uniquement à l'heure de chaque sauvegarde complète, comme dans la figure 2 . Si sinistre à 23 : 59 des samedi, juste avant la sauvegarde intégrale suivante est planifiée, puis tout le travail depuis la dernière sauvegarde complète peut être perdu. Pour cette raison, si perte de données doit être évité et les données ne peut pas être recréées, les sauvegardes du journal sont également inclus, comme illustré figure 3 .

La figure 2 stratégie de sauvegarde avec uniquement les sauvegardes intégrales

La figure 3 stratégie de sauvegarde complète des sauvegardes du journal

Imaginez que les sauvegardes du journal sont retirés de toutes les 30 minutes. Tant que toutes les sauvegardes sont disponibles, cela signifie que la base de données peut être restaurée jusque n'importe quel moment. Peut toutefois, cela ne pas être la meilleure stratégie. Que se passe-t-il si sinistre à 23 : 59 samedi avec cette stratégie en place ? Première chose consisterait à prendre un fin-de-la-journal de sauvegarde, puis démarrez la restauration.

Pour restaurer la base de données de point de l'incident signifie restauration sauvegarde complète de dimanche dernier et sauvegardes du journal puis 336 (c'est six jours de sauvegardes du journal 48 par jour, plus 47 samedi ainsi que la sauvegarde du corps du journal). Selon l'évolution du produite dans la base de données de la semaine qui peut être une quantité énorme de journal des transactions est long une très longue à relire. C'est clairement pas une stratégie de restauration optimale, mais c'est une stratégie courante dans le champ. Si vous disposez d'une stratégie de celle-ci, vérifiez que vous êtes entraîné effectuant une restauration afin de savoir si vous pouvez respecter votre RTO en cas d'incident.

Pour atténuer ce problème, certaines stratégies utilisez plus fréquemment des sauvegardes complètes, mais il peuvent être trop volumineux pour prendre tous les jours, par exemple. L'alternative consiste à utiliser les sauvegardes différentielles, qui contiennent uniquement les données qui a changé depuis la sauvegarde complète précédente. Poursuivre notre exemple, cette stratégie est illustrée à la figure 4 .

La figure 4 stratégie de sauvegarde avec complet, journal et les sauvegardes différentielles

Avec cette stratégie, la récupération d'une récupération d'urgence à 23 : 59 samedi est beaucoup plus rapide. Souvenez-vous qu'une sauvegarde différentielle est cumulative, la stratégie de restauration est la sauvegarde complète de dimanche, la sauvegarde différentielle du samedi 00 : 00, ainsi que tout les sauvegardes du journal à partir de samedi. Avoir la sauvegarde différentielle de 00 : 00 samedi signifie que toutes les sauvegardes du journal avant que des peuvent être ignorées, que la sauvegarde différentielle contient le même que le résultat net de restauration de toutes les sauvegardes du journal.

C'était un exemple assez simple et fictive, mais il indique clairement les avantages de chaque type de sauvegarde. Une fois que vous avez conçu votre stratégie de sauvegarde, assurez-vous que vous le tester pour vous assurer qu'il permet d'effectuer vos restaurations souhaitées.

Voici un exemple que j'ai vu un visage client quelques années. Un client a une base de données endommagée et souhaite récupérer avec aucune perte de données. Ils étaient réticents à utiliser leurs sauvegardes et avez essayé d'exécution de réparation sur une copie de la base de données, mais il devait supprimer des données, les forcer dans à l'aide de leurs sauvegardes. Il s'est avéré qu'ils avaient une sauvegarde complète de janvier et une sauvegarde du journal tous une demi-heure d'avril, sauvegardes plus de 5 000 au total et sur bande ! Je suis sûr que vous êtes propagées vos yeux et pensez «Je parie fonctionné,» mais en réalité il ne ; toutefois, il fallait faire les trois jours ! Le client en quelque sorte qu'ils avaient une excellente stratégie de sauvegarde, récupération FULL modèle plus journal des sauvegardes, mais leur stratégie de sauvegarde n'a pas les autoriser à faire les restaurations ils souhaitaient.

Sauvegarde de l'intégrité

Il est inutile dans des sauvegardes si vous trouvez qu'ils sont endommagés lorsque vous essayez de restaurer à partir de celles-ci. Bien entendu, la meilleure façon vérifier la validité de vos sauvegardes consiste à les restaurer sur un autre serveur, mais dans SQL Server 2005 a été introduite une nouvelle fonctionnalité qui autorisé certains l'intégrité des sauvegardes vérifie être effectuée sans avoir à les restaurer. Vous pouvez utiliser l'option avec total de contrôle lorsque vous prenez une sauvegarde (de n'importe quel divers).

Cela crée un total de contrôle sur le flux de sauvegarde complète, qui est stocké dans la sauvegarde elle-même. Si la sauvegarde est complète ou différentielle, et la base de données dispose de pagination activée, cette option entraînera également tout pagination existant à tester que le processus de sauvegarde lit les pages. Si un contrôle de page incorrect est trouvé, l'opération de sauvegarde échoue. Cela offre une grande protection contre accidentellement sauvegarde d'une base de données qui est déjà endommagé de manière. (Vous trouverez plus d'informations sur pagination dans l'article «Conseils à haut pour effet maintenance de base de données» à partir d'août 2008.)

Une fois la sauvegarde terminée, il peut être vérifiée en utilisant une commande semblable à celui-ci :

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

Vous recalculez la somme de contrôle au flux de sauvegarde complète et comparer à celle stockée dans la sauvegarde. Pour les sauvegardes complètes et différentielles, il est également tester toute pagination sur les pages de la sauvegarde. Si un problèmes sont détectés, vous savez que la sauvegarde a été corrompue.

Naturellement, il existe les exceptions à la règle, dans laquelle vous souhaiterez peut-être sauvegarder une base de données endommagée (si elle est la seule copie de la base de données que vous ont et que vous allez exécuter réparation, par exemple). Dans ce cas, vous pouvez forcer la sauvegarde pour terminer l'aide de l'option WITH CONTINUE_AFTER_ERROR.

Vous trouverez plus d'informations sur la sauvegarde de validation sur informations sur la validation sauvegarde sur mon bloget vous constaterez également me montrer certains aspects de validation de sauvegarde dans le deuxième écran cast qui accompagne cet article.

Résumé

Comme avec n'importe quel sujet complexe, il existe beaucoup de zones de sauvegardes que je n'ai pas d'espace pour couvrir, mais maintenant que les notions de base sont traitées, vous pouvez plonger dans certains liens documentation en ligne et blog pour plus d'informations. Le meilleur endroit pour démarrer dans la documentation en ligne est la rubrique" Présentation de sauvegarde (SQL Server)." Sur mon blog, vous pouvez démarrer avec le Catégorie de sauvegarde/restauration.

Une zone peut penser est visible dans son absence est compression de sauvegarde. C'est délibérée car vous allez il couvrant plus loin dans l'année dans un article sur toutes les technologies de compression nouveau dans SQL Server 2008. En attendant, vous pouvez consulter la rubrique documentation en ligne» Compression de sauvegarde (SQL Server)"et également sur mon blog.

Si j'ai dû additionner cet article en trois points de puce, il serait :

• Assurez-vous que vous disposez de sauvegardes.
• Assurez-vous de qu'avoir sauvegardes valides.
• Assurez-vous de qu'avoir les sauvegardes de droite.

En d'autres termes, sauvegardes prennent si vous souhaitez pouvoir restaurer votre base de données, procédez quelque chose afin de savoir les sauvegardes fonctionnent lorsque vous en avez besoin pour et assurez-vous que vous pouvez restaurer à partir de vos sauvegardes et répondent à vos RTO et LANCÉ.

Dans le prochain article, j'expliquerai tout sur restauration à partir de vos sauvegardes, y compris les différents types d'opérations de restauration et leur fonctionnement, restauration à partir de plusieurs sauvegardes et la disponibilité de base de données partielle.

En attendant et comme toujours, si vous avez des commentaires ou questions, supprimer m'une ligne à Paul@SQLskills.com.

Paul s. Randal est directeur général de SQLskills.com, un SQL Server MVP et directeur régional Microsoft. Il a travaillé sur le moteur de stockage de SQL Server chez Microsoft de 1999 à 2007. Paul a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Paul est un expert de récupération après incident, haute disponibilité et la maintenance de la base de données et un présentateur régulièrement à des conférences dans le monde entier. Blogs d'a à SQLskills.com/blogs/paul.