Alternatives à la sauvegarde réseau
Dans notre environnement, nous avons certains serveurs qui sont dans un groupe de disponibilité Always On, et certains qui sont autonomes.
Nous sauvegardons normalement sur un partage réseau, mais nous avons récemment observé que plus les bases de données grossissent, plus le temps nécessaire s'allonge, ce qui ralentit l'ensemble du réseau.
Le script d'Ola hallengren est utilisé avec la compression et également le fractionnement des fichiers de sauvegarde. J'effectue uniquement des sauvegardes "complètes" quotidiennes. Les sauvegardes vont au lecteur réseau EMC isilon.
Je ne suis jamais à l'aise avec EMC DD Boost. La seule alternative consiste à effectuer une sauvegarde locale, puis à copier sur le même partage réseau.
Existe-t-il un moyen efficace autre que ce qui précède?
L'alternative que vous avez mentionnée semble être le meilleur choix.
Ce que vous pouvez faire est un processus en 2 étapes:
- Prenez les sauvegardes natives du serveur SQL avec compression en utilisant la solution de sauvegarde d'Ola localement.
- Utilisez Robocopy pour effectuer les transferts vers un partage réseau. Ceci est découplé et peut s'exécuter en tant que tâche planifiée Windows.
De cette façon, vos sauvegardes sont locales et elles seront rapides. Vous aurez besoin de plus d'espace disque et évidemment de la redondance (et si le disque de sauvegarde échoue - vous ne voulez pas perdre toutes vos sauvegardes).
Alternativement, comme recommandé par Max Vernon, effectuez la Robocopy en tant qu'étape dans le travail de sauvegarde pour vous assurer que la robocopy ne se produit que si la sauvegarde est terminée avec succès et dès que possible après la fin de la sauvegarde. La sauvegarde est au même risque que les données, tant qu'elle reste locale.
Aussi, testez régulièrement vos restaurations car si vous ne pouvez pas restaurer une sauvegarde - à quoi sert-elle!
Référez-vous également à ma réponse à SQL Backup tuning large databases
Il existe des moyens de régler les sauvegardes en jouant avec différents boutons comme MAXTRANSFERSIZE ou BUFFERCOUNT , ou en supprimant le fichier (ce que vous avez déjà fait).
Le problème est que toucher ces boutons peut toujours avoir pour conséquence d'atteindre les limites de votre réseau et/ou de votre stockage, et qu'ils n'ont aucun impact réel sur le temps de sauvegarde.
Votre premier travail devrait être de comparer le stockage que vous sauvegardez jusqu'à utiliser Crystal Disk Mark ou DiskSpd . Cela vous donnera une idée de la vitesse à laquelle vous pouvez vous attendre à ce que les écritures soient à leur meilleur.
La prochaine chose que vous devez tester est la lecture des lecteurs à partir desquels vous sauvegardez. Si vous exécutez une sauvegarde vers NUL , vous pouvez chronométrer combien de temps cela prend juste la partie lue de votre sauvegarde, sans avoir pour l'écrire sur le disque.
Avec ces deux nombres à l'esprit, vous pouvez commencer à jouer avec d'autres boutons pour voir lesquels vous rapprochent le plus d'eux, que votre cible de sauvegarde soit locale ou en réseau.
Quelques solutions potentielles:
- Passer d'une sauvegarde complète uniquement à une sauvegarde complète hebdomadaire et à un différentiel nocturne peut être une solution facile.
Il existe un certain nombre de paramètres liés aux performances que vous pouvez modifier dans les scripts d'Ola, vous pouvez peut-être les modifier pour obtenir les performances que vous souhaitez:
BlockSize
Spécifiez la taille de bloc physique en octets.L'option BlockSize dans DatabaseBackup utilise l'option
BLOCKSIZEdans la commande SQL Server BACKUP.BufferCount
Spécifiez le nombre de tampons d'E/S à utiliser pour l'opération de sauvegarde.L'option BufferCount dans DatabaseBackup utilise l'option
BUFFERCOUNTdans la commande SQL ServerBACKUP.MaxTransferSize Spécifiez la plus grande unité de transfert, en octets, à utiliser entre SQL Server et le support de sauvegarde.
L'option MaxTransferSize dans DatabaseBackup utilise l'option
MAXTRANSFERSIZEdans la commande SQL ServerBACKUP.
Il existe de nombreuses options possibles, mais à mesure que les bases de données s'agrandissent et les sauvegardes complètes prennent plus de temps, vous devrez probablement incorporer sauvegardes différentielles , si vous ne l'avez pas déjà fait:
La création d'une sauvegarde différentielle peut être très rapide par rapport à la création d'une sauvegarde complète. Une sauvegarde différentielle enregistre uniquement les données qui ont changé depuis la sauvegarde complète sur la base de la sauvegarde différentielle. Cela facilite la prise de sauvegardes de données fréquentes, ce qui diminue le risque de perte de données.
Ma compréhension est que les scripts d'Ola peuvent même être définis pour décider entre une sauvegarde complète ou différentielle en fonction de la quantité de changement dans la base de données en utilisant le paramètre ModificationLevel .
Nous utilisons EMC DD Boost, et vous êtes le bienvenu pour votre propre opinion à ce sujet, mais nous avons constaté, en raison des méthodes de déduplication côté client qu'il utilise, que les sauvegardes complètes de bases de données même multi-To peuvent être très rapides, au point que nous n'avons pas à nous soucier des sauvegardes différentielles SQL Server. En effet, en utilisant EMC DD, vous effectuez des sauvegardes différentielles, mais pas dans SQL Server. L'utilisation de plusieurs fichiers de destination améliore également considérablement la vitesse, même sur DDBoost.