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 sur le lecteur isilon EMC de partage réseau.

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 (que faire 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!

Reportez-vous également à ma réponse à la sauvegarde SQL pour le réglage de grandes bases de données

Il existe des moyens de régler les sauvegardes en jouant avec différents boutons comme MAXTRANSFERSIZE ou BUFFERCOUNT , ou en agrégeant le fichier (ce que vous avez noté que vous faites déjà).

Le problème est que le fait de 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 avec 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 sur NUL , vous pouvez chronométrer combien de temps cela prend juste la partie de lecture de votre sauvegarde, sans avoir à 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:

1. Passer d'une sauvegarde complète uniquement à une sauvegarde hebdomadaire complète et à un différentiel nocturne peut être une solution facile.

2. Il existe un certain nombre de paramètres liés aux performances que vous pouvez modifier dans les scripts d'Ola, vous pourrez 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' BLOCKSIZEoption de 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' BUFFERCOUNToption de la BACKUPcommande SQL Server .

   • MaxTransferSize Spécifiez la plus grande unité de transfert, en octets, à utiliser entre SQL Server et le support de sauvegarde.

     L'option MaxTransferSize de DatabaseBackup utilise l' MAXTRANSFERSIZEoption de la BACKUPcommande SQL Server .

Il existe de nombreuses options possibles, mais comme les bases de données deviennent plus volumineuses et que les sauvegardes complètes prennent plus de temps, vous devrez probablement incorporer des 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 à l'aide du 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 , à l'aide d' EMC DD vous êtes en train de faire 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.