Actuellement, nous utilisons des plans de maintenance standard pour les sauvegardes sur les serveurs SQL Server 2005/2008 / 2008R2 / 2012 dans notre environnement, et la case "Vérifier l'intégrité de la sauvegarde" a toujours été cochée.
Certaines sauvegardes s'exécutent très longtemps, j'ai donc recommandé de désactiver cette option, mais la direction a besoin de moi pour documenter l'impact et les risques de ce changement.
Je comprends l'utilisation et l'historique de cette option, il me semble simplement inutile de doubler la durée du travail de sauvegarde lorsque (à mon avis), toute erreur susceptible de se produire se produirait pendant l' étape de sauvegarde , pas pendant la vérification.
Ai-je tort? Est-ce un risque minimal de désactiver cette fonction si je sauvegarde sur le disque et non sur une bande en streaming ou quelque chose? (Le cas échéant, nous sauvegardons sur le réseau une appliance de sauvegarde EMC DD-800.)
Existe-t-il des recommandations officielles des États membres pour savoir quand il est possible de désactiver cette option?
Exécutez-vous "vérifier" sur chaque sauvegarde de votre environnement? Les vérifiez-vous ponctuellement?
EDIT : pour clarifier, lorsque vous cochez «vérifier l'intégrité de la sauvegarde» dans le plan de maintenance, SQL effectuera une RESTAURATION VÉRIFIÉE complète sur chaque base de données immédiatement après chaque sauvegarde. C'est tout aussi intensif en données / E / S que la sauvegarde d'origine, et (en gros) double le temps global du travail de sauvegarde. Ce n'est pas la même chose que d'activer l'option "checksum" lors de la sauvegarde (ce qui ne peut pas être fait dans l'assistant, pour autant que je sache).
la source
Réponses:
Non, tu as raison :-)
RESTORE VERIFYONLYne garantira pas seulement que vous pourrez récupérer votre base de données en cas de corruption. Par nature, il n'effectuera aucun contrôle d'intégrité.Une meilleure façon consiste à effectuer périodiquement vos sauvegardes et à effectuer une restauration valide sur un autre serveur et à exécuter DBCC CHECKDB dessus.
C'est une des raisons pour lesquelles je ne suis pas un grand fan des plans de maintenance car l'interface graphique n'expose pas beaucoup d'options comme
backup .. with CHECKSUMcelle-ci peut être réalisée par T-SQL.Du blog Mythe de Paul Randal
Je ne lance pas le VERIFYONLY. Au lieu de cela, je prends une sauvegarde avec CHECKSUM puis je les fais restaurer + CHECKDB sur un autre serveur. Vous pouvez suivre l' approche d' échantillonnage statistique pour vérifier les sauvegardes de base de données si vous voulez être créatif.
Vous pouvez activer Trace Flag 3023 pour que l'
CHECKSUMoption soit automatiquement activée pour la commande BACKUP. Comme toujours, testez le comportement de tout indicateur de trace dans votre environnement!L'essentiel est de - abandonner les plans de maintenance et utiliser une solution de sauvegarde plus judicieuse (indice: la solution de sauvegarde d'Ola) qui vous permettra de la personnaliser en fonction de vos besoins.
Sauvegardez localement sur le disque, puis effectuez un travail de transfert PowerShell qui copiera la sauvegarde localement du serveur vers un partage réseau (serveur de sauvegarde). Ce sera plus rapide que de copier directement sur un partage réseau.
En outre, activez l'initialisation instantanée des fichiers, ce qui aidera à la croissance automatique des fichiers de données ainsi qu'à réduire le temps de restauration (au cas où vous devriez restaurer vos bases de données). C'est toujours bien d'avoir des options à portée de main.
Une bonne lecture sera: Sauvegardes: Planification d'une stratégie de récupération
la source
TSQLpar opposition àGUI(plans de maintenance) afin que vous puissiez tirer parti de la flexibilité et l'adapter à mains ouvertes. Tout comme un FYI .. les plans de maintenance ont été améliorés dans SQL Server 2016CTP 2.4que MS appelle des plans de maintenance intelligents SQL Server - intègre les meilleures pratiques et peut identifier les stratégies optimales à la volée. Toujours aucune interface graphique ne peut battre TSQL :-)L'essentiel est qu'à moins que vous ne fassiez une restauration de base de données quelque part, vous ne pouvez pas être totalement sûr qu'un fichier de sauvegarde donné est bon.
Le test idéal pour vérifier vos sauvegardes consiste à configurer un environnement dans lequel les sauvegardes de la base de données et les sauvegardes du journal de la base de données sont restaurées tout le temps dans le cadre de votre processus quotidien. C'est l'un des avantages de l'utilisation de l'envoi de journaux ...
Si vous souhaitez toujours vous en tenir à Verifyonly, vous pouvez configurer un environnement spécifiquement pour cela. Cela déchargerait le travail de votre (vraisemblablement) serveur de production et réduirait le temps de travail.
Enfin, avez-vous envisagé de vous éloigner des plans de maintenance? Les scripts comme les scripts d'Ola sont à l'exception des sauvegardes et de la maintenance: https://ola.hallengren.com/
la source
Techniquement, la restauration est comme effectuer une restauration, mais il n'y a pas de meilleur contrôle que la restauration de la base de données pour vérifier qu'il s'agit d'une sauvegarde valide. Nous avons eu une instance où la vérification a réussi, mais la base de données ne sera pas restaurée en raison d'une corruption, mon point est de ne pas compter sur cela comme une vérification de la sauvegarde. Nous avons maintenant développé un système qui restaure toutes nos bases de données sur une instance distincte pour vérifier leur validité, ce qui n'est clairement pas toujours possible, alors essayez d'échantillonner certaines bases de données par semaine. Les longs et les courts ne font pas confiance à 100% seulement.
la source