Отключение базы данных в качестве стратегии резервного копирования

Question

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

Позвольте мне рассмотреть некоторые из общих вопросов.

1. Мои файлы базы данных почти заполнены, поэтому тот факт, что резервные копии копируют только используемые страницы, мне не важен;
2. Я не использую файловое хранилище;
3. мое приложение может обрабатывать небольшие периоды простоя, когда я отсоединяюсь и делаю копию;
4. Различные кошмары прав доступа к файлам, которые сопровождают отключение баз данных, уже решены.

Общий размер БД составляет около 1 ТБ. Моя главная причина отсоединения и присоединения вместо использования резервных копий - производительность. В моем тестировании значительно быстрее отсоединить базу данных, сделать копию базовых файлов и снова прикрепить исходные файлы, чем выполнять резервное копирование. Во время восстановления также значительно быстрее прикреплять файлы (даже если мне нужно сначала скопировать их в нужное место), чем восстанавливать их.

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

Последний пункт, который я часто читаю, это то, что отсоединение базы данных сопряжено с некоторым риском. Так же, как мы должны выполнить тестовое восстановление резервных копий, я немедленно присоединяю любые скопированные файлы MDF/LDF/NDF к SQL Server для аварийного восстановления, чтобы убедиться, что копия исправна. Я полагаю, что здесь я могу отсоединить базу данных и сломать что-нибудь, чтобы исходные файлы БД больше не могли быть повторно присоединены. Честно говоря, я никогда не видел этого, поэтому, если это действительно возможно, я чувствую, что это довольно далеко. Я делаю это каждую ночь, так что я потерял бы дневную стоимость отчетов в этом (маловероятном?) Сценарии.

Я что-то пропустил?

Answer 1

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

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

Вы не упомянули резервные копии журнала транзакций. Для большинства людей резервные копии журналов дают оптимальное время восстановления и точку восстановления. Рассматривали ли вы относительно редкие резервные копии журналов как альтернативную стратегию?

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

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

При отсоединении и повторном подключении убедитесь, что вы включили файл (ы) журнала. Сохраните автономную копию в дополнение к копии, которую вы приложите. Если произойдет сбой вложения (скажем, из-за того, что один из файлов был перемещен), то в некоторых случаях файлы могут быть "затронуты", поэтому их невозможно будет легко снова прикрепить. Мой совет - никогда не пытаться прикреплять из вашей единственной копии файлов базы данных.

Вам все равно нужно будет использовать BACKUP для резервного копирования базы данных Master (и модели /msdb, если требуется).