Хранение (частичных) резервных копий небольшого размера при использовании SQL Server FILESTREAM

У меня есть база данных с почти 1 ТБ FILESTREAMданных, резервное копирование которых мне не нужно (если данные были удалены, они автоматически восстанавливаются через пару часов, так что это просто не важно). Большая часть данных меняется каждые пару дней, поэтому дифференциальное резервное копирование не поможет уменьшить размер.

У меня были резервные копии, работающие так, как мне нужно, установив режим восстановления на Full, создав отдельное FILEGROUPдля FILESTREAM, а затем создав резервные копии только «Первичного» FILEGROUP. Проблема, которую это вызвало, состояла в том, что файл журнала (который также резервируется) теперь неоправданно велик, потому что он включает в себя FILESTREAMданные.

SIMPLEРежим восстановления лишает меня возможности делать резервные копии определенных FILEGROUPфайлов, поэтому я не думаю, что это тоже будет вариант.

Мои мысли состоят в том, чтобы просто переместить FILESTREAMданные в отдельную базу данных, но теперь я теряю ссылочную целостность и, конечно, унаследую множество других проблем.

Есть ли способ создать частичное резервное копирование в Simpleрежиме восстановления (без настройки FILESTREAMтаблицы только для чтения)? Если нет, есть ли другие здравые решения моей проблемы?

Проблема, которую это вызвало, заключалась в том, что файл журнала (который также резервируется) теперь неоправданно велик, потому что он содержит данные FILESTREAM.

Я не уверен, если вы имеете в виду, что сам файл журнала слишком велик или что резервные копии файлов журнала становятся слишком большими.

Если это первое, то как часто вы поддерживали журнал? В зависимости от дизайна приложения, вы можете уменьшить размер за счет более частого резервного копирования (и каждые 5 минут не слишком часто). Однако, если вы уже делали это, и это все еще развивалось, то вам, вероятно, не повезло. Почему большой файл журнала снова является проблемой?

Если это последнее - это звучало так, как будто вы были рады продолжить простую модель восстановления, и ни один момент времени не восстанавливается, если она позволяет создавать резервные копии меньшего размера; в этом случае оставайтесь в полном режиме и откажитесь от резервных копий журнала.

Решение для базы данных, настроенной на режим восстановления SIMPLE, заключается в размещении данных FILESTREAM в файловой группе, доступной только для чтения (что не является вашим идеальным вариантом), а затем резервное копирование только групп файлов для чтения / записи с помощью DIFFERENTIAL, например:

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

Он получит любые данные, которые изменились в любых файловых группах для чтения / записи. Это самое простое, из коробки, что вы можете поддерживать частичное управление резервными копиями без получения данных FILESTREAM. Однако для этого потребуется, чтобы процесс загрузки вышеупомянутых данных изменил файловую группу для чтения / записи, загрузил любые дополнительные данные и затем снова установил чтение. Конечно, не идеал.

Я чувствую себя грязно, предоставляя это в качестве опции, но если вы решите разделить данные FILESTREAM в своей собственной базе данных, вы можете поддерживать RI между таблицами в отдельных базах данных с помощью триггеров :

Триггеры -> Примечания -> Ограничения:
Триггер создается только в текущей базе данных; однако триггер может ссылаться на объекты вне текущей базы данных.

Ожидайте проблем с производительностью и часть вашей кожи головы, чтобы стать безволосой после вытаскивания пучков шерсти вашей головы в расстройстве, но теоретически вы могли бы сделать это. Я не рекомендую этот подход на любом уровне, вместо этого я настоятельно рекомендую вам увеличить частоту резервного копирования tlog и / или переключиться на модель восстановления с массовой регистрацией и посмотреть, сколько места сэкономит вам, НО это возможное решение. На самом деле вам нужно взвесить выгоду от разделения этих данных и работы с базой данных Франкенштейна, но это вариант.

... Я должен пойти принять душ сейчас ...

Я знаю, что на этот вопрос уже дан ответ, но есть другое решение, которое может помочь другим. Недавно я узнал из блога Брента Озара, что есть возможность сразу же удалить ваши резервные копии журналов:

BACKUP LOG MyDb TO DISK='NUL:'

Таким образом, вы можете оставить свою базу данных в Fullрежиме восстановления и делать резервные копии файловых групп. Когда ваш журнал транзакций становится слишком большим, просто выполните команду резервного копирования журнала, и все готово.