В настоящее время нашими резервными копиями управляет сторонняя компания. Создано множество заданий агентов, которые выполняют полное резервное копирование (4 раза в день) и резервное копирование журнала транзакций (4 раза в час).
Теперь мы хотим управлять нашими резервными копиями внутри компании, но не хотим отключать сторонние задания, пока не убедимся, что у нас все правильно настроено внутри.
Поэтому я предлагаю иметь короткий период (скажем, пару дней), когда резервные копии будут выполняться как старой, так и новой системой.
Мне интересно, каковы последствия того, что обе эти две разные системы управляют резервным копированием, и потенциальные ловушки одновременного создания резервных копий. Это вообще поддерживается? Если это так, и учитывая, что система может справиться с одним резервным копированием без какого-либо заметного снижения производительности, достаточно ли логично предположить, что она должна быть способна справиться с двумя одновременными резервными копиями?
В настоящее время нагрузка на сервер довольно мала, и с ней редко возникают проблемы.
Любой совет приветствуется
У вас возникнут проблемы с одновременным запуском обеих резервных копий с одинаковым временем.
Для начала, ваши журналы транзакций будут разделены между двумя сайтами, и все они понадобятся вам для восстановления до последней транзакции.
Кроме того, существует высокая вероятность того, что задания резервного копирования будут конфликтовать, и это приведет к сбою одного (или обоих) операторов резервного копирования, потенциально оставляя пробелы в вашей резервной копии.
Восстановление тоже будет сложнее.
Я рекомендую начать с того, чтобы оставить существующие задания и просто делать ежедневные полные резервные копии на вашем сайте, проверить, все ли они в порядке, а затем переключить резервные копии журнала транзакций со стороннего поставщика на вашу систему резервного копирования.
Конечно, протестируйте свои сценарии и сценарии восстановления. Я предполагаю, что ваша новая схема резервного копирования поместит файлы резервных копий в безопасное и надежное место вдали от основных серверов!
Больше информации: Конфликт резервного копирования SQL Server
В дополнение к вышеупомянутому сообщению вы можете использовать T-SQL для создания резервной копии только для копирования, которая не нарушит график резервного копирования, установленный этой сторонней компанией в настоящее время. В зависимости от времени их резервного копирования и того, сколько (резервных копий) вам нужно делать каждый день в начале, вы можете просто сделать что-то вроде:
BACKUP DATABASE [database_name]
TO DISK = 'E:\Backups\DBName\20100611-whatever-you-call-it.bak'
WITH COPY ONLY
NAME = 'NameYourBackup'
DESCRIPTION = 'BriefDescriptionOfTheDatabase'
Это создаст копию базы данных, которая не повлияет на текущее расписание, и отправит ее на любое устройство, на котором вы собираетесь хранить свои резервные копии. Затем вы можете восстановить базы данных на сервере test / dev, чтобы убедиться, что они не повреждены и все, что вам нужно, есть.
Используя приведенный выше код, вы можете изменить его для создания резервных копий журнала транзакций и поместить код по шагам в задание SQL, которое будет запланировано на заданное время.
Больше информации здесь: http://msdn.microsoft.com/en-us/library/ms186865.aspx