Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 3 - Restore.
Иногда вещи должны немного выскальзывать из рук. Во всяком случае давайте немного поговорим о том, как все эти замечательные параметры резервного копирования в SQL Server 2012 могут повлиять на процесс восстановления.
Первое, что следует усвоить, - невозможно восстановить базу данных, которая является частью группы доступности. Если вы обнаружите, что вам нужно восстановить любую из ваших реплик или вашу главную реплику, вы должны исключить ее из группы доступности. Ход мысли здесь похож на то, к чему вы привыкли в сценарии доставки журналов или зеркального отображения. Поскольку вы нарушаете цепи общего журнала, то восстанавливаемая вами база данных больше не может быть частью этой цепочки журналов. Вот пример очень информативного сообщения об ошибке, которое вы можете увидеть:
Второе соображение связано с новой возможностью иметь переменное местоположение для резервного копирования. Если вы используете функцию sys.fn_hadr_backup_is_preferred_replica, чтобы определить надлежащее место для резервного копирования, описанное в моем предыдущем посте, то вы можете иметь полную резервную копию на сервере Server1, некоторые резервные копии журналов транзакций на Server2, и т.д.. Это может доставить неудобства и немного разочаровать, например, при использовании графического интерфейса Management Studio для выполнения восстановления. Они используют таблицы истории журнала резервного копирования в базе данных msdb, чтобы определить все наборы резервных копий (backupsets) для базы данных. Эти данные не разделяются и не дублируются между экземплярами. Вы увидите только те резервные копии, которые были созданы на этом конкретном экземпляре.
Например, предположим, что я создал полную резервную копию на экземпляре SQL1, но у меня есть резервные копии журнала транзакций, запущенных на SQL2. Если я пытаюсь восстановить базу данных на SQL1 в среде Management Studio, то я увижу только полную резервную копию, но не обнаружу резервные копии журнала транзакций, которые были созданы на SQL2. В это же время, если я делаю то же самое в SQL2, то я не увижу каких-либо резервных копий, которые могут быть восстановлены. Теперь, если вы посмотрите внимательно, вы увидите сообщение, которое я выделил на скриншоте ниже:
Перерыв в цепочке журналов – это потому что нет никаких признаков полного резервного копирования в базе данных msdb, которые вы можете четко видеть в следующем скриншоте запроса и результата. Резервные копии журналов транзакций здесь, но нет полной резервной копии, которая нужна, так как полная резервная копия была выполнена на другом экземпляре.
Если бы мы ДЕЙСТВИТЕЛЬНО хотели восстановить эту базу данных, мы могли бы взять файл полного резервного копирования, который был сделан на SQL1 и восстановить этот файл, а затем применить эти 4 резервные копии журнала транзакций из SQL2. Конечно, нам бы нужно сначала удалить базу данных из группы доступности, но обычно вам нужно будет делать это восстановление в другой среде для тестирования плана восстановления, восстановления копии продуктивных данных для тестирования продуктивной среды и т.д.
Я хочу вновь подчеркнуть важность использования сетевого расположения для всех ваших полных, дифференциальных копий и резервных копий журнала транзакций, которые взяты с участвующей в группе доступности базы данных. Когда множество экземпляров может быть драйвером файла резервной копии, который является частью цепочки общих журналов, наличие единственного месторасположения для всех файлов является обязательным. Наверняка, вы же не захотите потерять все файлы и не захотите собирать по частям множество файлов из различных мест, каждый раз, когда вам потребуется сделать восстановление. Думайте так, как будто вы находитесь в сценарии восстановления при реальной катастрофе в продуктивной среде. Вам уже придется разобрать ваши группы доступности для восстановления основной базы. Вы, вероятно, уже "отливаете пули", так как это, скорее всего, ваше "последнее средство" вернуть всё назад... Сделайте эту задачу как можно проще для себя! Всегда имейте документированный план восстановления, так чтобы все, что нужно было бы сделать – это прочитать и выполнить пошагово этот самый план!
RSS - Записи
Добавить комментарий