SQL Server - частые резервные копии базы данных

Question

У меня есть служба, которая синхронизирует данные между двумя базами данных. Это довольно рискованно в основном потому, что это новое программное обеспечение, которое не очень хорошо протестировано. Вот почему мне нужно делать частые резервные копии - перед каждой синхронизацией (служба выполняет это сама). После одного дня я получил 13,9 ГБ файл с резервными копиями. Это слишком много.

Я рассматриваю, какие у меня есть варианты и что с этим делать. Я пытаюсь разделить эту базу данных на две файловые группы - основной и фотографии. После этого я получил 16 МБ и 120 МБ файлов. Здесь важно сделать резервную копию этих 16 Мб и иметь возможность восстановить их при необходимости.

Я действительно не знаю, какие здесь риски и что может случиться. Кто-нибудь может кратко объяснить или дать ссылку, чтобы я мог читать?

Какие еще есть варианты?

(конечной целью является частое резервное копирование с относительно небольшими размерами файлов резервных копий)

Answer 1

Вы пометили этот вопрос MSSQL 2008.

MS SQL 2008 может использовать FILESTREAM для хранения наборов файлов в файловой системе, а не в виде двоичных объектов в БД. Тем не менее, он сохраняет возможность отслеживать и индексировать расположение файлов.

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

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

Вот информативная ссылка на функцию FILESTREAM:
http://msdn.microsoft.com/en-us/library/cc949109(v=sql.100).aspx

Answer 2

У меня есть служба, которая синхронизирует данные между двумя базами данных. Это довольно рискованно в основном потому, что это новое программное обеспечение, которое не очень хорошо протестировано. Вот почему мне нужно делать частые резервные копии - перед каждой синхронизацией ( сервис выполняет это сам). После однажды я получил 13,9 ГБ файл с резервное копирование. Это слишком много.

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

USE DatabaseName
GO
DBCC SHRINKFILE(LogFileName, 1)
BACKUP LOG DatabaseName WITH TRUNCATE_ONLY
DBCC SHRINKFILE(LogFile, 1)
GO