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

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

0 голосов
/ 04 сентября 2018

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

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

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

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

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

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

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

1 Ответ

0 голосов
/ 05 сентября 2018

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

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

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

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

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

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

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

...