D'après ce que je peux dire, il existe trois façons possibles de sauvegarder votre base de données SQL Server
Quels sont les avantages et les inconvénients de chaque stratégie et dans quelles situations devraient-elles être utilisées?
Réponses:
L'envoi de journaux n'est pas un scénario de sauvegarde. C'est un scénario de disponibilité semi-élevé.
Pour les sauvegardes, il existe des sauvegardes complètes, différentielles et des journaux de transactions. Ils doivent tous être utilisés ensemble. Votre SLA dicte comment vous les utilisez. La plupart des scénarios typiques sont une sauvegarde complète, disons à minuit, une sauvegarde différée à midi et des sauvegardes du journal des transactions toutes les 30 ou 15 minutes.
Et rappelez-vous: vous n'avez pas de sauvegarde valide tant que vous ne l'avez pas restaurée pour tester si elle est correcte.
Il n'y a sans doute pas de concept de stratégie de sauvegarde: vous avez une stratégie de restauration car cela détermine combien de temps jusqu'à ce que vous soyez de nouveau opérationnel *.
Toutes les stratégies nécessitent une sauvegarde complète pour baser toute restauration ultérieure de sauvegardes différentielles et / ou de journaux.
En pratique, vous pouvez avoir une sauvegarde complète d'il y a 6 mois avec des sauvegardes de journaux de 15 minutes: cependant, vous devez appliquer chaque sauvegarde de journal à partir de la dernière complète.
À titre d'exemple aléatoire, un scénario pourrait être hebdomadaire complet, différentiel quotidiennement, enregistrer 15 minutes.
L'intervalle de sauvegarde détermine la quantité de données que vous perdrez dans le pire des cas: les sauvegardes de journaux de 15 minutes vous donnent une perte de données entre 1 seconde et 14 minutes 59 secondes, 7,5 minutes en moyenne. Est-ce acceptable?
L'envoi de journaux est une veille à chaud avec basculement manuel: ce n'est pas une sauvegarde mais une option de haute disponibilité.
Il n'y a pas de stratégie unique adaptée à chaque situation. Mais il est important de comprendre ce dont vous disposez. Les sauvegardes complètes sont exactement ce à quoi elles ressemblent: une sauvegarde complète de votre base de données, moins le journal des transactions. Les sauvegardes différentielles sont des sauvegardes des modifications des fichiers de données depuis la dernière sauvegarde complète. Les sauvegardes du journal des transactions sauvegarderont toutes les transactions stockées dans le journal des transactions depuis la dernière sauvegarde du journal des transactions. Les sauvegardes du journal des transactions vous permettront de restaurer à un moment donné. S'il s'agit d'une exigence, vous devrez définir votre mode de récupération sur «Complet» et vous devrez effectuer des sauvegardes régulières du journal des transactions en fonction de la quantité de données que vous êtes prêt à perdre en cas de situation de récupération.
Lorsque vous traitez des sauvegardes de journaux de transactions, il est important de comprendre ce qu'est une chaîne de journaux. Selon mes mots, une chaîne de journaux est la série de sauvegardes qui doivent être restaurées afin de restaurer votre base de données à un moment donné. Pour commencer à restaurer les journaux de transactions, vous devez d'abord restaurer une sauvegarde complète à l'aide de l'option WITH NORECOVERY. Si vous effectuez également des sauvegardes différentielles, vous souhaiterez restaurer la sauvegarde différentielle la plus récente avant le moment où vous souhaitez restaurer en utilisant la même option AVEC NORECOVERY. À ce stade, vous devrez restaurer les sauvegardes du journal des transactions, séquentiellement, en utilisant l'option WITH NORECOVERY sur toutes les sauvegardes à l'exception de la sauvegarde finale. Pour plus d'informations sur les restaurations ponctuelles, consultez ce lien. http://msdn.microsoft.com/en-us/library/ms175093.aspx
Comme mentionné, Log Shipping n'est pas une stratégie de sauvegarde, mais il peut réduire considérablement les temps de restauration en cas de reprise après sinistre. Un problème à rechercher est que toutes les publications de réplication devront être scriptées sur le serveur Log Shipping et initialisées pour que la réplication fonctionne comme avant la catastrophe. Avec des publications plus volumineuses, cela pourrait entraîner une augmentation significative du temps nécessaire pour revenir à un niveau de production.
J'espère que cela t'aides,
Mat
J'appuie Mladen Prajdic. Cet article vous aidera à choisir la bonne stratégie de sauvegarde en fonction du modèle de récupération des bases de données.
ce ne sont pas des stratégies de sauvegarde pour SQL Server. Les sauvegardes complètes et différentielles sont des types de sauvegardes que vous pouvez effectuer sur une base de données SQL Server, tandis que l'envoi de journaux est une stratégie de haute disponibilité (en déplaçant les sauvegardes de journaux à une heure planifiée d'un serveur vers un autre et en synchronisant ces 2 bases de données jusqu'au limite de vos sauvegardes).
De belles informations sur la récupération après sinistre (sauvegarde et restauration :-)) que vous pouvez trouver sur MSDN: ici et ici . En bref, vous devez choisir la quantité de données que vous pouvez récupérer des sauvegardes en cas d'échec. Un exemple sain de stratégie de sauvegarde serait une sauvegarde complète tous les jours et des sauvegardes de journal toutes les heures (cela dépend de vos besoins), dans ce cas, vous seriez en mesure de restaurer la base de données à partir de la sauvegarde complète + de toute la sauvegarde quotidienne du journal.
Une autre belle référence sur DR que vous pouvez trouver sur Simple_Talk .
Bien sûr, non seulement vous devez restaurer votre base de données, mais il y a une récupération dans le contexte du serveur et de l'application dont la base de données fait partie. Je ne l'ai pas encore utilisé moi-même, mais Data Protection Manager cherche à faire un travail plus complet, si vous en avez besoin.
La meilleure façon consiste à utiliser les trois types de sauvegarde ensemble. Bien sûr, vous pouvez ignorer la sauvegarde différentielle de la sauvegarde du journal des transactions. Tout dépend de votre base de données, de sa vitesse de croissance, de la fréquence à laquelle vous apportez des modifications dans votre base de données et autres. Avant de choisir votre plan de sauvegarde, réfléchissez à la quantité de données que vous êtes prêt à perdre? Combien de temps êtes-vous prêt à consacrer à la récupération de votre base de données?
Par exemple, si la croissance de votre base de données est rapide, vous pouvez utiliser la stratégie de sauvegarde SQL Server suivante: sauvegarde complète - une fois par jour, sauvegardes différentielles - toutes les deux heures et sauvegardes du journal des transactions - toutes les 20 minutes. Dans ce cas, si la panne se produit, vous ne perdrez pas plus de 19 minutes de votre travail. Un autre exemple, si la croissance de votre base de données est lente, vous pouvez effectuer une sauvegarde complète une fois par jour, une sauvegarde différentielle toutes les six heures et toutes les heures effectuer une sauvegarde du journal des transactions.
Un autre conseil - pour être sûr que votre base de données est en sécurité, de temps en temps, restaurez vos sauvegardes sur un serveur de test.