Garder les sauvegardes (partielles) petites lors de l'utilisation de SQL Server FILESTREAM

J'ai une base de données avec près de 1 To de FILESTREAMdonnées que je n'ai pas besoin de sauvegarder (si les données étaient supprimées, elles seraient recréées automatiquement en quelques heures, donc ce n'est tout simplement pas important). La plupart des données sont modifiées tous les deux jours, donc les sauvegardes différentielles n'aideraient pas vraiment à réduire la taille.

J'ai eu les sauvegardes fonctionnant de la façon dont j'avais besoin en définissant le mode de récupération sur Full, en créant un séparé FILEGROUPpour le FILESTREAM, puis en prenant des sauvegardes uniquement du "principal" FILEGROUP. Le problème que cela a causé était que le fichier journal (qui est également sauvegardé) est maintenant inutilement volumineux car il inclut les FILESTREAMdonnées.

SIMPLELe mode de récupération m'enlève ma capacité à faire des sauvegardes de FILEGROUPs spécifiques , donc je ne pense pas que ce sera une option non plus.

Mes pensées sont de simplement déplacer les FILESTREAMdonnées vers une base de données distincte, mais maintenant je perds l'intégrité référentielle et hérite sûrement d'une foule d'autres problèmes également.

Existe-t-il un moyen de créer des sauvegardes partielles en Simplemode de récupération (sans définir la FILESTREAMtable en lecture seule)? Sinon, existe-t-il d'autres solutions sensées à mon problème?

Le problème que cela a causé était que le fichier journal (qui est également sauvegardé) est désormais inutilement volumineux car il inclut les données FILESTREAM.

Je ne sais pas si vous voulez dire que le fichier journal lui-même est trop volumineux ou que les sauvegardes du fichier journal deviennent trop volumineuses.

Si c'est le premier, à quelle fréquence sauvegardiez-vous la connexion? Selon la conception de l'application, vous pourrez peut-être réduire la taille en sauvegardant plus fréquemment (et toutes les 5 minutes ce n'est pas trop fréquent). Cependant, si vous le faisiez déjà et qu'il faisait encore du ballon, vous n'avez probablement pas de chance. Pourquoi le gros fichier journal est-il à nouveau un problème?

Si c'est le dernier - il semblait que vous étiez heureux de continuer avec un modèle de récupération simple et aucune restauration à un moment donné si cela vous permettait d'avoir des sauvegardes plus petites; dans ce cas, restez en mode complet et supprimez vos sauvegardes de journaux.

Une solution pour une base de données définie sur le mode de récupération SIMPLE consiste à avoir les données FILESTREAM dans un groupe de fichiers en lecture seule (ce qui n'est pas votre option idéale), puis à sauvegarder uniquement les groupes de fichiers en lecture / écriture avec DIFFÉRENTIEL comme ceci:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

Il obtiendra toutes les données qui ont changé dans tous les groupes de fichiers en lecture / écriture. C'est le plus simple, prêt à l'emploi, que vous pouvez garder des sauvegardes partielles gérables sans obtenir les données FILESTREAM. Il faudrait toutefois que le processus de chargement des données susmentionnées doive modifier le groupe de fichiers à lire / écrire, charger toutes les données supplémentaires, puis définir à nouveau en lecture seule. Certainement pas idéal.

Je me sens sale en fournissant cela en option, mais si vous choisissez de séparer les données FILESTREAM dans sa propre base de données, vous pouvez maintenir le RI entre les tables dans les dbs séparés au moyen de déclencheurs :

Déclencheurs -> Remarques -> Limitations:
Un déclencheur est créé uniquement dans la base de données actuelle; cependant, un déclencheur peut référencer des objets en dehors de la base de données actuelle.

Attendez-vous à ce que les problèmes de performance et une partie de votre cuir chevelu deviennent glabres après avoir retiré les touffes de votre fourrure de tête de frustration, mais théoriquement, vous pourriez le faire. Je ne recommande pas cette approche à quelque niveau que ce soit, au lieu de cela, je vous suggère fortement d'augmenter la fréquence de vos sauvegardes tlog et / ou de basculer vers le modèle de récupération enregistré en masse et de voir combien d'espace vous économise, MAIS c'est une solution possible. Vraiment, il faudrait peser l'avantage de séparer ces données et de gérer une conception de base de données frankensteinienne, mais c'est une option.

... Je dois aller prendre une douche maintenant ...

Je sais que cette question a déjà reçu une réponse, mais il existe une autre solution qui pourrait aider les autres. Récemment, j'ai appris du blog de Brent Ozar qu'il existe une option pour supprimer immédiatement vos sauvegardes de journaux:

BACKUP LOG MyDb TO DISK='NUL:'

Vous pouvez donc laisser votre base de données en Fullmode de récupération et faire des sauvegardes de groupes de fichiers. Lorsque votre journal des transactions devient trop volumineux, lancez simplement la commande de sauvegarde du journal et vous avez terminé.