Tous les jours, nous expédions nos sauvegardes SQL Server sur le réseau étendu. Nous devons minimiser la taille de ces sauvegardes pour que cela ne prenne pas une éternité.
Cela ne nous dérange pas si notre processus de sauvegarde prend un peu plus longtemps; dans l'état actuel des choses, nous devons transférer 30 Go de sauvegarde compressée sur le réseau étendu, ce qui prend plus de 10 heures.
Il existe 2 options pour obtenir des sauvegardes quotidiennes plus petites.
- Log expédition, ce qui signifie que nous aurions à restructurer le processus de reprise après sinistre.
- Supprime les informations de la base de données et les reconstruit de l'autre côté (supprime les index non clusterisés, compresse les index clusterisés à 100% - reconstruit de l'autre côté)
Les deux impliqueraient pas mal de travail de notre part. Nous utilisons SQL Server 2008 pro, toutes les sauvegardes sont compressées.
Existe-t-il des produits commerciaux pouvant nous donner une taille de sauvegarde similaire à celle de l'option (2)?
Existe-t-il un script complet qui nous permettra d'accomplir (2)? (gestion des vues indexées, des index filtrés, des clés étrangères, etc.)
la source
Réponses:
Première pensée basée sur les commentaires ...
Utilisez des sauvegardes différentielles toutes les 6 heures, par exemple, pour réduire la taille / la durée de la sauvegarde + FTP. Ensuite, réduisez votre sauvegarde complète + FTP aux week-ends uniquement. Cela évite la complexité de l'envoi de journaux, simple à faire, et ajoute seulement une légère complexité à la reprise après sinistre.
Je pense que les sauvegardes différentielles sont négligées ... J'ai déjà suggéré de les utiliser:
Utilisation de sauvegardes DIFF pour résoudre ce problème
Utilisation de sauvegardes DIFF pour accélérer la migration d'un serveur de sauvegarde / restauration
Edit: après le commentaire de jcolebrand je vais essayer d'expliquer plus
Une sauvegarde différentielle ne prend que les pages qui ont été modifiées. En dehors de la maintenance de l'index (qui peut affecter une grande partie de la base de données), seuls quelques% des pages changeront au cours d'une journée. Ainsi, une sauvegarde différentielle est beaucoup plus petite qu'une sauvegarde complète avant toute compression.
Si vous disposez d'une sauvegarde complète, hebdomadaire par exemple, vous pouvez ensuite effectuer des différentiels quotidiens et les expédier hors site. Une sauvegarde complète quotidienne avec des différentiels nécessitera toujours les deux fichiers hors site.
Cela devrait résoudre le problème de l'obtention rapide des données de A à B, C et D.
Vous aurez probablement besoin de restaurer le différentiel complet et le dernier différentiel pour obtenir les dernières données, mais vous pouvez peut-être contourner ce problème avec NORECOVERY et un fichier STANDBY (je ne l'ai pas essayé avec une restauration diff depuis des années que j'étais dans un pur DBA emploi).
Un avantage supplémentaire est que les sauvegardes diff ne sont pas liées aux sauvegardes de journal en cours, ce qui vous permet de séparer toute exigence de haute disponibilité / DR de l'exigence "Obtenir les données dans les codes des singes".
Je vois des problèmes si vous avez des sauvegardes complètes quotidiennes par stratégie ou par audit, mais la restauration différentielle peut être appliquée avant toute restauration de journal pour réduire le temps de récupération. Contrairement aux sauvegardes, les restaurations de diff et de journal interagissent.
J'espère que j'ai couvert la plupart des bases ...
la source
Il existe des produits commerciaux qui peuvent vous aider à compresser vos sauvegardes mieux que la compression native de 2008. Les exemples sont RedGate Backup , Hyperbac , Idera SQL Backup , Litespeed Backup .
Ils viennent avec le coût supplémentaire de types de processeur et de processeur élevés qui devront être gérés avec des outils autres que ceux fournis par MS. Ceci à l'exception de la compression Hyperbac (maintenant acquise par Redgate), qui gère les fichiers de manière transparente et permet de créer des fichiers compatibles avec le zip (et ne nécessite également aucun outil tiers).
Mais aucun outil ne vous proposera un fichier de la taille que vous obtiendriez en effectuant un nettoyage manuel. Consultez l'article de Brent Ozar: Comment compresser réellement vos sauvegardes SQL Server , il vous conseillera de suivre la même procédure qu'au point no. 2
la source
Question 1: Existe-t-il un produit de sauvegarde commercial qui donnera une taille de sauvegarde similaire à la suppression de données non essentielles telles que des index de la base de données?
Il existe de nombreux produits de compression de sauvegarde (Quest LiteSpeed, Sauvegarde Red Gate SQL, Idera SQLSafe, Hyperbac, etc.), mais ils fonctionnent tous en compressant simplement la sortie du processus de sauvegarde normal de SQL Server. Certains le font de manière délicate - HyperBac et l'option Engine de LiteSpeed sont des pilotes de filtre de système de fichiers, ce qui signifie qu'ils interceptent la sortie sur son chemin vers le disque - mais le résultat final de tous ces produits est simplement une sortie de sauvegarde compressée.
Question 2. Existe-t-il un script complet permettant de vider toutes ces données supplémentaires?
Au fil du temps, au fur et à mesure que vous gardez plus d'historique dans la base de données (4, 5, 8, 10 ans), vous ne voudrez plus extraire toutes les données d'index et les reconstruire de l'autre côté du réseau étendu. Au lieu de cela, vous souhaitez simplement transférer les données modifiées, et c’est là que l’expédition de journaux entre en jeu.
Tu ne devrais pas faire ça.
Mais si vous voulez vraiment faire cela (et non, je ne vous aiderai pas), vous pouvez le faire avec des sauvegardes de groupe de fichiers. Configurez vos groupes de fichiers de base de données comme ceci:
Commencez à faire des sauvegardes compressées des groupes de fichiers des deux premières et copiez les plus petites sur votre serveur de reprise après incident. Vous pouvez utiliser la fonctionnalité de sauvegarde et de restauration de groupe de fichiers de SQL Server 2008 pour restaurer simplement les groupes de fichiers primaire et ClusteredIndex, qui seront immédiatement disponibles pour l'interrogation. Ils ne fonctionneront pas vraiment tant que vous n’aurez pas mis ce groupe de fichiers ExtraneousCrap en ligne, mais il existe une astuce pour cela aussi: dans le livre de MVP Deep Dives , il existe un chapitre sur la modification des tables système afin de créer le groupe de fichiers ExtraneousCrap et autres. des index associés disparaissent. Cette astuce est dangereuse, totalement non supportée, et une sacrée mauvaise idée - mais bon, vous l'avez demandée.
la source
Je recommande de passer à quelque chose comme l'envoi de journaux. Essentiellement, si vous avez le choix d’envoyer 30 concerts en 24 heures ou plus en fin de journée dans un laps de temps réduit, la vitesse du réseau sera moins gênante.
Vos développeurs sur le réseau lent pourront également télécharger des fichiers de taille plus pratique, via FTP ou tout autre processus en place. Ils peuvent également configurer des tâches qui se téléchargent tout au long de la journée.
En plus de la compression de serveur SQL, vous pouvez implémenter un outil tiers tel que Litespeed ou Redgate sqlbackup.
De plus, côté réseau, vous pouvez installer des périphériques réseau permettant d'optimiser votre débit sur le site de reprise après sinistre. Dans le passé, j'ai utilisé Riverbed Appliance avec succès pour obtenir une sauvegarde de 90 Go de FL à VA en moins de 3 heures.
Une autre option serait de sauvegarder des groupes de fichiers spécifiques, en excluant les index, etc., mais vous êtes toujours bloqué avec les index en cluster et, en fonction de votre structure de base de données, vous pouvez obtenir plus de coûts que d’avantages de cette approche.
Merci
la source
Si vous en avez les moyens et que votre architecture le permet, vérifiez dans les technologies de Riverbed (http://www.riverbed.com/us/). Un appareil de ce type associé à un scénario de réplication ou d'envoi de journaux peut être votre meilleur choix.
Sinon, quelques questions. Si vous ne devez effectuer une actualisation que tous les quelques mois, pourquoi vous inquiétez-vous de la bande passante? La seule fois où vous auriez à vous soucier du transfert, c’est une fois, obtenir la sauvegarde complète là-bas pour effectuer une restauration localement, ou est-ce que je me trompe en disant que c’est votre configuration?
Une autre possibilité consiste à installer un environnement Citrix au lieu de s’occuper de leur transmettre toutes ces données. Avec Citrix, vos besoins en bande passante entre client / hôte sont minimes et vous avez la possibilité de faire ce dont vous avez besoin localement sans vous soucier de la réplication de ces modifications ailleurs. Juste mon 0,02 $
la source
Je voudrais utiliser la réplication transactionnelle SQL. Votre chargement initial prendrait un certain temps, mais une fois que vous êtes opérationnel, vous ne pouvez envoyer que les informations que vous souhaitez. Par exemple, si vous ne disposez que de 3 ou 4 tables mises à jour, vous ne pouvez envoyer que ces 3 ou 4 tables.
Vous pouvez également choisir ce que vous voulez expédier. FK, index clusterisés / non-clusterisés, schémas de partition de table, procs stockés, et plus encore.
http://www.sql-server-performance.com/2010/replication-transactionale-2008-r2/
Si ce n'est pas une option, vous pouvez utiliser REDGATE SQL BACKUP - http://www.red-gate.com/products/dba/sql-backup/ . Je l'ai déjà utilisé et mes taux de compression ont atteint 90%. Beaucoup plus petit que SQL.
la source