Пути восстановления
Владение знаниями о путях восстановления существенно важно, если используются разностные резервные копии или резервные копии журналов, а восстановление базы данных на более ранний момент времени выполняется одним из следующих методов:
Выполнение восстановления на момент времени
Выполнение восстановления без предварительного восстановления из всех резервных копий журналов и последних разностных резервных копий.
При восстановлении базы данных до более раннего момента времени с последующим использованием базы данных с этой точки создается новый путь восстановления. Путь восстановления представляет из себя последовательность резервных копий данных и журналов, при помощи которых возможно восстановление базы данных до определенного момента времени либо при обычном использовании базы данных, либо в процессе специальной последовательности восстановления данных и журналов. Путь восстановления состоит из уникального набора специальных преобразований, отражающих развитие базы данных в течение времени и поддерживающих согласованность данных в ней. На следующем рисунке показана связь между точкой восстановления и конечными путями восстановления.
.gif "Точка восстановления и результирующие пути восстановления")
Следующие ситуации приводят к созданию нового пути восстановления, так как база данных не восстанавливается «до конца времен». Соответственно, существуют резервные копии, которые реализуют один или несколько путей восстановления, каждый из которых использует один и тот же диапазон номеров LSN.
Восстановление полной резервной копии и восстановление базы данных по журналу без использования каких-либо других типов резервных копий.
Восстановление базы данных с конца разностной резервной копии, отличной от самой последней разностной резервной копии.
Восстановление полной резервной копии и разностной резервной копии и восстановление базы данных без применения существующих резервных копий журнала транзакций.
Восстановление базы данных с конца резервной копии журнала транзакций, отличной от самой последней резервной копии журнала транзакций.
Восстановление базы данных с определенного момента времени или с помеченной транзакции внутри резервной копии журнала транзакций.
В общем случае, точка восстановления создает новый путь восстановления, если она приводит к откату транзакций. Существовавшие ранее резервные копии теперь могут иметь номера LSN большие, чем номер LSN этой точки восстановления. В таких резервных копиях они существуют в различных ветвях восстановления, которые создаются в текущей операции восстановления.
Рекомендация Чтобы избежать создания пути восстановления, который имеет несколько вилок, необходимо создать полный набор резервных копий данных сразу же после восстановления базы данных. Этот подход гарантирует, что все резервные копии будут находиться в одной и той же ветви восстановления. Чтобы проверить это, необходимо просмотреть столбец last_recovery_fork_guid в таблице backupset или результирующий набор инструкции RESTORE HEADERONLY, выполненной после резервного копирования данных.
Примеры пути восстановления
Изначально все резервные копии базы данных образуют один путь восстановления, как показано на следующем рисунке. На этом рисунке путь восстановления включает резервную копию базы данных, созданную в момент t1, и три резервных копии журнала, созданные в моменты t2, t3 и t4.
.gif "Исходный путь восстановления")
На приведенном ниже рисунке показана вилка восстановления, которая получается после восстановления базы данных на более ранний момент времени. Проблема с резервной копией t4 приводит к тому, что администратору базы данных приходится восстанавливать базу данных в точке окончания резервной копии журнала t3. В этом случае образуется вилка восстановления. В момент t5 новое резервное копирование журнала порождает новую ветвь восстановления 2.
.gif "Создание второй ветви восстановления")
.gif "Примечание") Примечание |
|---|
Резервная копия t5 содержит метаданные о вилке восстановления, которые связывают эту резервную копию с резервной копией журнала t3 в ветви восстановления 1. Дополнительные сведения о метаданных о вилке восстановления см. в разделе «Управление вилками восстановления» ниже. |
В примере, представленном на предыдущей иллюстрации, создается новый путь восстановления, показанный на следующем рисунке. Новый путь восстановления включает некоторые резервные копии из ветви восстановления 1 (t1-t3) и все резервные копии журнала из ветви восстановления 2 (t5-t9). Для этой ветви восстановления резервная копия журнала t4 является устаревшей.
.gif "Новый путь восстановления")
После восстановления на определенный момент времени создание следующей резервной копии всегда приводит к возникновению вилки восстановления. На следующем рисунке восстановление на момент времени выполняется наполовину с помощью резервной копии журнала t4. Восстановление базы данных на этот момент времени приводит к созданию вилки восстановления. Затем в момент t5 в восстановленной базе данных создается резервная копия журнала, которая задает ветвь восстановления 2 и порождает новый путь восстановления. Первая резервная копия журнала в новой ветви t5 содержит такой же номер LSN, что и у резервной копии t3, и заменяет ее. Поэтому обе резервные копии, t3 и t4, являются устаревшими для новой ветви восстановления.
.gif "Новый путь восстановления после восстановления на определенный момент времени")
Для восстановления резервных копий в этой новой ветви восстановления последовательность восстановления будет t1, t2 и t5. При создании новых резервных копий в ветви восстановления 2 они будут включаться в новый путь восстановления.
Восстановление и накат вдоль старого пути
Как правило, при наличии нескольких путей восстановления предпочтительным для восстановления базы данных является самый последний из них. Рекомендуется избегать использования старых путей восстановления. Однако при необходимости можно выполнить накат по старому пути восстановления, используя последовательность резервных копий, сделанных перед созданием текущего пути восстановления. Например, можно использовать резервные копии, созданные перед восстановлением на определенный момент времени, чтобы достигнуть более поздних точек на старом пути.
Например, на основе резервных копий, созданных в предыдущем примере, после создания резервной копии журнала t5 остается возможность произвести восстановление из полной резервной копии базы данных, созданной в момент t1, до конца резервной копии журнала t4. Это выполняется на старом пути восстановления.
Восстановление и накат от старого пути до нового
Компонент SQL Server Database Engine предотвращает использование в одной последовательности восстановления нескольких резервных копий, накат в которых происходит по различным путям восстановления. Это ограничение обеспечивает согласованность базы данных после восстановления.
Для восстановления и наката по новому пути восстановления создайте различные последовательности восстановления для резервных копий перед точкой восстановления и для резервных копий после точки восстановления:
Восстановите резервные копии, которые были созданы до восстановления, соответствующего новому пути восстановления. Исключите резервную копию, которая содержит точку восстановления.
Произведите накат по новому пути восстановления, восстановив резервные копии, созданные с момента создания пути восстановления.
Управление вилками восстановления
Ветвь восстановления является диапазоном номеров LSN, для которых установлен одинаковый идентификатор GUID. Путь восстановления описывает диапазон номеров LSN от точки запуска (LSN,GUID) до конечной точки (LSN,GUID). Диапазон номеров LSN в пути восстановления может пересекать одну или более ветвей от начала до конца. Новая ветвь восстановления возникает при создании базы данных, а также если инструкция RESTORE WITH RECOVERY формирует вилку восстановления.
Вилка восстановления является точкой (LSN,GUID), на которой новая ветвь восстановления запускается каждый раз, когда выполняется инструкция RESTORE WITH RECOVERY. Каждая вилка восстановления определяет связь типа родители-потомки между ветвями восстановления.
Восстановление базы данных приводит состояние всей базы данных, включая следующий номер LSN, к точке восстановления. Затем номера LSN используются повторно, начиная с fork_point_lsn. Таким образом, при создании последовательности восстановления резервные копии должны быть связаны веткой восстановления и номерами LSN, так как один и тот же номер LSN может присутствовать более чем на одной ветке. На следующем рисунке показано повторное использование номера LSN. На нем видно, как номера LSN повторно используются в разных ветвях восстановления. Зеленые прямоугольники на иллюстрации указывают две резервные копии, для которых используется один номер LSN.
.gif "Как номера LSN повторно используются в разных вилках восстановления")
Если в последовательности восстановления необходимо использовать резервные копии, которые пересекают вилку восстановления, то последовательность восстановления должна быть создана так, чтобы используемые резервные копии следовали к точке восстановления по правильному пути восстановления. Для этого резервные копии содержат идентификатор GUID первой и последней вилки восстановления.
Эти идентификаторы вместе с другими метаданными, связанными с отслеживанием путей восстановления, хранятся в таблице журнала backupset и возвращаются инструкцией RESTORE HEADERONLY. В следующей таблице приводится сводка значений метаданных, релевантных для создания последовательностей восстановления, пересекающих вилку восстановления. Обратите внимание, что имена столбцов для этих значений отличаются в таблице журнала и результирующем наборе инструкции RESTORE HEADERONLY.
Номер LSN |
Описание |
Название столбца таблицы backupset |
Название столбца результирующего набора RESTORE HEADERONLY |
|---|---|---|---|
Идентификатор GUID первой вилки восстановления |
Идентификатор первой вилки восстановления. |
first_recovery_fork_guid |
FirstRecoveryForkID |
Идентификатор GUID последней вилки восстановления |
Идентификатор последней вилки восстановления. |
last_recovery_fork_guid |
RecoveryForkID |
Первый номер LSN |
Регистрационный номер транзакции в журнале первой или самой ранней записи журнала в резервном наборе данных. |
first_lsn |
FirstLSN |
Последний номер LSN |
Регистрационный номер транзакции из следующей записи в журнале резервного набора данных. |
last_lsn |
LastLSN |
Номер LSN вилки |
Регистрационный номер вилки в журнале, если идентификатор GUID первой точки восстановления не равен идентификатору GUID последней точки восстановления. В противном случае при резервном копировании вилка не образуется и номер LSN вилки равен NULL. |
fork_point_lsn |
ForkPointLSN |
Идентификатор GUID базовой копии для разностного копирования |
Для однобазового разностного резервного копирования значение является уникальным идентификатором основы для разностной копии. Для многобазового разностного резервного копирования значение равно NULL, а базовая копия для разностного копирования должна быть определена на файловом уровне. Дополнительные сведения см. в разделе backupfile (Transact-SQL). Для неразностных типов резервного копирования значение равно NULL. |
differential_base_guid |
DifferentialBaseGUID |
В оставшейся части этого раздела используются только имена значений из таблицы журнала backupset.
Идентификаторы GUID последней и первой вилки восстановления используются для связи резервных копий, чтобы гарантировать проход последовательности по правильным разветвлениям. Для каждой восстанавливаемой резервной копии журнала в последовательности идентификатор first_recovery_fork_guid должен быть равен идентификатору last_recovery_fork_guid предыдущей резервной копии в последовательности.
.gif "Значение first_recovery_fork_guid равно значению last_recovery_fork_guid")
Резервные копии данных и разностные резервные копии также должны быть связаны.
Если в резервной копии журналов одновременно содержатся и вилка, и последний номер LSN полной резервной копии или разностной резервной копии, то проверка связи зависит от местоположения последнего номера LSN относительно вилки.
Проверка связи выполняется, как описано ниже, при использовании значений из таблицы backupset.
Если номер last_lsn меньше или равен fork_point_lsn, то идентификатор last_recovery_fork_guid резервной копии данных или разностной резервной копии должен быть равен first_recovery_fork_guid резервной копии журналов. На следующем рисунке показана ситуация, где last_lsn меньше fork_point_lsn.
.gif "Значение last_lsn меньше значения fork_point_lsn")
Если номер last_lsn больше fork_point_lsn, то идентификатор last_recovery_fork_guid резервной копии данных или разностной резервной копии должен быть равен last_recovery_fork_guid резервной копии журналов. На следующем рисунке показана ситуация, когда last_lsn больше fork_point_lsn.
.gif "Значение last_lsn больше значения fork_point_lsn")
Для разностной резервной копии найдите базовую копию через backupset.differential_base_guid.
Если разностная резервная копия является многобазовой, то значение backupset.differential_base_guid равно NULL, а базовые копии для разностного копирования для каждого из файлов необходимо определить через backupfile.differential_base_guid.
См. также