Mantener copias de seguridad (parciales) pequeñas cuando se utiliza SQL Server FILESTREAM

Tengo una base de datos con casi 1 TB de FILESTREAMdatos de los que no necesito hacer una copia de seguridad (si los datos se eliminan, se volverán a crear automáticamente en un par de horas, por lo que simplemente no es importante). La mayoría de los datos se cambian cada dos días, por lo que las copias de seguridad diferenciales realmente no ayudarían a mantener el tamaño bajo.

Hice que las copias de seguridad funcionaran como lo necesitaba, configurando el Modo de recuperación en Full, creando un separado FILEGROUPpara el FILESTREAM, luego tomando copias de seguridad de solo el "Primario" FILEGROUP. El problema que esto causó fue que el archivo de registro (que también se respalda) ahora es innecesariamente grande porque incluye los FILESTREAMdatos.

SIMPLEEl modo de recuperación me quita la capacidad de hacer copias de seguridad de correos electrónicos específicos FILEGROUP, por lo que tampoco creo que sea una opción.

Mis pensamientos son simplemente mover los FILESTREAMdatos a una base de datos separada, pero ahora estoy perdiendo integridad referencial y seguramente también heredé una serie de otros problemas.

¿Hay alguna forma de crear copias de seguridad parciales en Simplemodo de recuperación (sin configurar la FILESTREAMtabla como de solo lectura)? Si no, ¿hay alguna otra solución sensata para mi problema?

El problema que esto causó fue que el archivo de registro (que también se respalda) ahora es innecesariamente grande porque incluye los datos de FILESTREAM.

No estoy seguro si quiere decir que el archivo de registro en sí es demasiado grande o que las copias de seguridad del archivo de registro se vuelven demasiado grandes.

Si es lo primero, ¿con qué frecuencia respaldaba el registro? Dependiendo del diseño de la aplicación, es posible que pueda reducir el tamaño haciendo una copia de seguridad con más frecuencia (y cada 5 minutos no es demasiado frecuente). Sin embargo, si ya lo estaba haciendo y todavía se disparaba, probablemente no tenga suerte. ¿Por qué el archivo de registro grande vuelve a ser un problema?

Si es lo último, sonó como si estuviera contento de continuar con un modelo de recuperación simple y no se restaura ningún punto en el tiempo si le permite tener copias de seguridad más pequeñas; en cuyo caso, permanezca en modo completo y descarte las copias de seguridad de sus registros.

Una solución para una base de datos establecida en modo de recuperación SIMPLE es tener los datos de FILESTREAM en un grupo de archivos de solo lectura (que no es su opción ideal), y luego hacer una copia de seguridad solo de los grupos de archivos de lectura / escritura con DIFERENCIALES como esta:

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

Obtendrá cualquier dato que haya cambiado en cualquier grupo de archivos de lectura / escritura. Es lo más fácil, listo para usar, que puede mantener manejables las copias de seguridad parciales sin obtener los datos de FILESTREAM. Sin embargo, requeriría que el proceso de carga de los datos antes mencionados necesitara modificar el grupo de archivos para leer / escribir, cargar cualquier información adicional y luego configurarlo para que se vuelva a leer. Ciertamente no es ideal.

Me siento sucio al proporcionar esto como una opción, pero si elige segregar los datos de FILESTREAM en su propia base de datos, podría mantener RI entre las tablas en los dbs separados a través de disparadores :

Desencadenantes -> Observaciones -> Limitaciones:
un desencadenador se crea solo en la base de datos actual; sin embargo, un activador puede hacer referencia a objetos fuera de la base de datos actual.

Espere que los problemas de rendimiento y una sección de su cuero cabelludo se vuelvan sin pelo después de sacar los mechones de su cabeza con frustración, pero en teoría podría hacer esto. No recomiendo este enfoque en ningún nivel, en cambio le sugiero que aumente la frecuencia de sus copias de seguridad de tlog y / o cambie al modelo de recuperación de registro masivo y vea cuánto espacio le ahorra, PERO esta es una posible solución. Realmente necesitaría sopesar el beneficio de separar estos datos y tratar con un diseño de base de datos frankensteiniana, pero es una opción.

... tengo que ir a ducharme ahora ...

Sé que esta pregunta ya está respondida, pero hay otra solución que podría ayudar a otros. Recientemente supe del blog de Brent Ozar que hay una opción para descartar sus copias de seguridad de registros de inmediato:

BACKUP LOG MyDb TO DISK='NUL:'

Para que pueda dejar su base de datos en Fullmodo de recuperación y hacer copias de seguridad de grupos de archivos. Cuando su registro de transacciones sea demasiado grande, simplemente emita el comando de registro de copia de seguridad y listo.