Стратегия резервного копирования для большой базы данных FileStream на Sql Server

Question

Справочная информация:

Я создал систему управления документами для своей компании для управления документами компании (~ 1 ТБ, 1 миллион + строк в таблице файлов).

Приложение было построено с использованием .net 4.8 с EF6. БД - это SQL Server 2017. Файл сохраняется как BLOB-файл FileStream в SQL Server. Файлы могут быть загружены / загружены через веб-интерфейс / API.

Размер БД составляет примерно 1 ТБ, и 95% из них - это файловые потоки с темпом роста около 20% в год.

Наша текущая стратегия резервного копирования:

• Полное резервное копирование (еженедельно)
• Дифференциальное резервное копирование (ежедневно)
• Резервное копирование журнала (каждые 15 минут)

Проблемы , с которыми мы сталкиваемся:

1. Полное резервное копирование займет 7-8 часов - на нормальные операции может повлиять потребление ресурсов ввода-вывода при операции резервного копирования.
2. Восстановление БД займет очень много времени, еслипроизошла любая катастрофа (это нас больше всего беспокоит).
3. Слишком большой размер файла резервной копии (полный файл резервной копии составляет около 900 ГБ)
4. Все исторические данные должны быть доступны, поэтому мы не можем в действительности архивировать данные.

Вопрос:

1. Учитывая этот сценарий, какова будет для нас лучшая стратегия в отношении резервного копирования SQL?
2. Я видел людей, использующих файловые группы для разделения холодных / горячих данных. Поскольку все загруженные файлы будут доступны только для чтения, есть ли способ использовать Filegroup в нашей системе?

Answer 1

Учитывая этот сценарий, какова будет для нас лучшая стратегия в отношении SQL Backup?

Я считаю, что текущая стратегия резервного копирования (которую вы упомянули), кажется, хороша в вашем случае.

Полное резервное копирование займет 7-8 часов - на нормальные операции может повлиять потребление ресурсов ввода-вывода при операции резервного копирования.

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

Определение задержки ввода-вывода во время резервного копирования (будь то чтение / запись) поможет вам лучше планировать, т. Е. Задержка (7-8 часов) из-за задержки ввода-вывода при чтении резервных копий или записи резервных копий в общее хранилище. Поскольку у вас уже есть полная продолжительность, вы можете определить задержку операции чтения, выполнив BACKUP TO DISK = 'null'. Вероятность (задержки) больше с операцией записи, в этом случае вы можете сократить время резервного копирования, сохранив его локально / более быстрый накопитель и переместившись в обычное общее хранилище после завершения резервного копирования.

Восстановление БД займет очень много времени, если произойдет какое-либо бедствие (это наша самая большая проблема).

Учтите, что ПОЛНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ медленное во время РЕЗЕРВНОГО КОПИРОВАНИЯ и более быстрое во время ВОССТАНОВЛЕНИЯ, что совершенно противоположно в случае LO РЕЗЕРВНОГО КОПИРОВАНИЯ. Таким образом, упомянутая ваша стратегия резервного копирования хороша.

Однако в вашем случае для DR лучшим вариантом будет Доставка журналов , который периодически восстанавливает резервные копии журналов на вторичном сервере, поскольку ПОЛНАЯ резервная копия восстанавливается только тогда, когда не будет большой нагрузки с обеих сторон. (Основной сайт и DR Site). Примите во внимание, что регулярное РЕЗЕРВНОЕ КОПИРОВАНИЕ ЖУРНАЛА (15 минут) будет заменено заданиями Доставка журналов.

При использовании LS as DR Solution время восстановления равно времени, которое может занять недавнее восстановление LOG.

Слишком большой размер файла резервной копии (размер полной резервной копии составляет около 900 ГБ)

Я полагаю, что это стандартная степень сжатия, и максимум возможен в SQL Engine, и вариантов для уменьшения размера резервной копии будет немного.