Приложения резервного копирования SQL Server — служба теневого копирования томов (VSS) и модуль записи SQL

Область применения: SQL Server

SQL Server обеспечивает поддержку службы теневого копирования томов (VSS), предоставляя модуль записи (модуль записи SQL), чтобы стороннее приложение резервного копирования могло использовать платформу VSS для резервного копирования файлов базы данных. В этом документе описывается компонент модуля записи SQL и его роль в процессе создания и восстановления моментальных снимков VSS для баз данных SQL Server. Кроме того, здесь приводятся сведения о настройке и использовании модуля записи SQL для работы с приложениями резервного копирования на платформе VSS.

Инфраструктура VSS

Служба VSS обеспечивает системную инфраструктуру для запуска приложений VSS в системах Windows. Служба VSS почти полностью прозрачна как для пользователя, так и для разработчика и выполняет следующие задачи.

• Координирует действия поставщиков, модулей записи и инициаторов запроса при создании и использовании теневых копий.
• Предоставляет поставщика системы по умолчанию.
• Реализует функциональные возможности драйвера нижнего уровня, необходимые для работы любого поставщика.

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

Компоненты VSS

VSS координирует действия следующих совместно работающих компонентов:

• Поставщики владеют данными теневого копирования и создают экземпляры теневых копий.
• Модули записи — это приложения, которые изменяют данные и участвуют в процессе синхронизации теневых копий.
• Инициаторы запроса запускают создание и уничтожение теневых копий. Наше проектирование основано на сценарии, в котором инициатор запроса является приложением резервного копирования.

Служба VSS обеспечивает координацию между этими сторонами:

На этой диаграмме показаны все компоненты, участвующие в типичном действии с моментальными снимками VSS. В этом сценарии SQL Server (включая модуль записи SQL) выступает в роли модуля записи в одном из окон модуля записи. Другими такими модулями записи могут быть Exchange Server и т. д.

• Интерфейс виртуального устройства: SQL Server предоставляет интерфейс программирования приложений с именем VDI, который помогает независимым поставщикам программного обеспечения интегрировать SQL Server в свои продукты, предоставляя поддержку операций резервного копирования и восстановления. Эти API обеспечивают максимальную надежность и производительность, а также поддерживают все функции резервного копирования и восстановления SQL Server, включая полный набор возможностей оперативного и моментального резервного копирования. Дополнительные сведения см. в разделе Спецификация интерфейса виртуальных устройств резервного копирования (VDI) для SQL Server 2005.

• Запроситель: процесс (автоматический или графический интерфейс), который запрашивает один или несколько наборов моментальных снимков из одного или нескольких исходных томов. В этой статье инициатором запроса также называется приложение резервного копирования, которое создает моментальный снимок баз данных SQL Server.

Дополнительные сведения см. в документации по службе теневого копирования томов.

Модуль записи SQL

Модуль записи SQL — это модуль записи VSS, предоставляемый SQL Server. Он обрабатывает взаимодействие VSS с SQL Server. Модуль записи SQL поставляется с SQL Server в качестве автономной службы и устанавливается как часть установки SQL Server.

Роль модуля записи SQL в операции резервного копирования моментальных снимков VSS:

Настройка модуля записи SQL

Служба модуля записи SQL устанавливается в систему в процессе установки SQL Server и настраивается на автоматический запуск при запуске Windows.

Учетная запись службы модуля записи SQL

Во время установки учетная запись модуля записи SQL будет установлена для использования локальной системной учетной записи. Так как модуль записи SQL должен взаимодействовать с SQL Server с использованием эксклюзивных интерфейсов API VDI, учетная запись модуля записи SQL должна иметь достаточные права доступа как для SQL Server, так и для VSS. Настройка службы в качестве локальной системной учетной записи предоставляет достаточные права для правильной работы службы.

Примечание.

Чтобы служба модуля записи SQL работала правильно, важно убедиться, что локальная системная учетная запись не удалена из роли "SA" экземпляра SQL Server.

Повторное включение и запуск модуля записи SQL

По умолчанию модуль записи SQL включен и запускается автоматически. Если эта конфигурация была изменена, для возврата к параметрам по умолчанию нужно сделать следующее.

Службу модуля записи SQL можно включить, пометив ее как "автоматическую". Чтобы открыть службы на панели управления, нажмите кнопку "Пуск", щелкните "Панель управления", дважды щелкните "Администрирование", а затем дважды щелкните "Службы". В области "Службы" дважды щелкните службу модуля записи SQL и измените значение свойства "Тип запуска" на "Автоматически".

После этого следует запустить службу, нажав кнопку "Пуск" рядом со свойством "Состояние службы" на экране свойств, упомянутом выше.

Примечание.

В некоторых случаях, когда установлен экземпляр SQL Server Express и приложение использует функцию пользовательских экземпляров, модуль записи SQL может автоматически запускаться через SQL Server. Это делается для того, чтобы упростить перечисление этих пользовательских экземпляров во время операции резервного копирования VSS.

Функции, поддерживаемые модулем записи SQL

• Fulltext: средство записи SQL сообщает контейнеры полнотекстового каталога с рекурсивными спецификациями файлов в компонентах базы данных в документе метаданных записи. Они автоматически включаются в резервную копию при выборе компонента базы данных
• Разностное резервное копирование и восстановление. Модуль записи SQL поддерживает разностное резервное копирование и восстановление через два механизма разностных операций VSS: частичный файл и разностный файл по времени последнего изменения.
• Частичный файл: модуль записи SQL использует механизм частичного файла VSS для создания отчетов об измененных диапазонах байтов в файлах базы данных.
• Различаемый файл по времени последнего изменения: модуль записи SQL использует разностный файл VSS по механизму последнего изменения времени для создания отчетов об измененных файлах в полнотекстовых каталогах.
• Восстановление с помощью перемещения: модуль записи SQL поддерживает спецификацию VSSs New Target во время восстановления. Спецификация нового целевого объекта VSS позволяет переместить файл базы данных или журнала или контейнер полнотекстового каталога в ходе операции восстановления.
• Переименование базы данных: запросчику может потребоваться восстановить базу данных SQL с новым именем, особенно если база данных должна быть восстановлена параллельно с исходной базой данных. Модуль записи SQL поддерживает переименование базы данных во время операции восстановления, если база данных остается в исходном экземпляре SQL.
• Резервное копирование только для копирования: иногда требуется создать резервную копию, предназначенную для специального назначения, например, если необходимо создать копию базы данных для тестирования. Эта резервная копия не влияет на обычные процедуры резервного копирования и восстановления базы данных. Параметр COPY_ONLY указывает, что резервная копия выполняется по внешнему каналу и не должна влиять на нормальную последовательность резервных копий. Модуль записи SQL поддерживает тип резервного копирования "только для копирования" с экземплярами SQL Server.
• Автоматическое восстановление моментального снимка базы данных: обычно моментальный снимок базы данных SQL Server, полученный с помощью платформы VSS, находится в невосстановленном состоянии. К данным в моментальном снимке нельзя безопасно получить доступ до этапа восстановления, чтобы выполнить откат транзакций в реальном состоянии и перевести базу данных в целостное состояние. Приложение резервного копирования VSS может запрашивать автовосстановление моментальных снимков в рамках процесса создания моментального снимка.

Эти новые возможности и их использование более подробно описаны в разделе "Дополнительные сведения о резервном копировании и восстановлении" в этой статье.

Что не поддерживается

• Резервные копии журналов не поддерживаются модулем записи SQL.
• Резервное копирование файлов и файловых групп не поддерживается.
• Восстановление страниц не поддерживается.
• Моментальные снимки базы данных не поддерживаются и игнорируются при создании одновременно моментальных снимков VSS на основе компонента и не основе компонента.
• Автоматически закрытые базы данных или базы данных с включенным завершением работы.
• Linux не предоставляет платформу VSS, поэтому модуль записи SQL недоступен в Linux

В следующей таблице перечислены типы резервных копий моментальных снимков, которые поддерживаются модулем записи SQL или SQL Server, работающим с платформой VSS, для всех выпусков SQL Server.

Операция резервного копирования и восстановления	На основе компонентов	Не на основе компонентов
Полное резервное копирование данных (включая полнотекстовый каталог)	Да	Да
Полное восстановление	Да	Да
Полное восстановление (без последнего этапа восстановления)	Да	Нет
Разностное резервное копирование	Да	Нет
Разностное восстановление	Да	Нет
Восстановление с перемещением	Да	Нет
Переименование базы данных	Да	Нет
Резервная копия только для копирования	Да	Нет
Автоматические восстановленные моментальные снимки	Да	Нет
Резервное копирование журналов	No	No
Моментальные снимки базы данных	No	No
Автоматические базы данных баз данных с завершением работы	Да	Нет
Базы данных группы доступности	Да	Не на вторичных

Операции резервного копирования

SQL Server (с помощью модуля записи SQL) будет поддерживать следующие режимы операций резервного копирования на основе VSS:

• Не на основе компонентов
• На основе компонентов

Поддерживаемые версии

Модуль записи SQL поставляется в составе SQL Server и поддерживает только экземпляры SQL Server. Модуль записи SQL также будет перечислять экземпляры SQL Server Express. Пользовательские экземпляры, запущенные SQL Server Express, также будут перечисляться модулем записи SQL.

Операции резервного копирования, не основанные на компонентах

Резервные копии не на основе компонентов неявным образом выбирают базы данных, используя список томов в наборе снимков. Модуль записи SQL проверяет наличие разорванных баз данных, вызывая ошибку, если они найдены. Разорванной считается база данных, в которой подмножество файлов выбирается списком томов.

В модели, не основанной на компонентах, поддерживаются только базы данных с простой моделью восстановления. Накат после восстановления не поддерживается.

Операции резервного копирования, основанные на компонентах

Резервные копии на основе компонентов являются предпочтительными и рекомендуются для модуля записи SQL, так как приложение (приложение резервного копирования VSS) явно выбирает базы данных из метаданных, возвращаемых из модуля записи SQL. Набор моментальных снимков должен включать все тома, необходимые для резервного копирования этих баз данных. Инфраструктура VSS не добавляет тома, необходимые для выбранного набора баз данных, автоматически. Все резервные тома должны быть добавлены в набор моментальных снимков тома. Приложение резервного копирования следит за тем, чтобы все резервные тома включались в набор моментальных снимков. Модуль записи SQL обнаружит разорванные базы данных (с резервными томами за пределами набора моментальных снимков) и не сможет создать резервную копию.

В оставшейся части этого раздела предполагается, что при создании моментального снимка VSS для SQL Server используются резервные копии на основе компонентов.

Процесс создания моментального снимка

Платформа VSS координирует действия инициатора запроса (приложения резервного копирования) и модуля записи SQL во время создания моментальных снимков SQL Server. Чтобы обеспечить эту координацию, платформа VSS определяет интерфейсы инициатора запроса и модуля записи. Эти интерфейсы должны реализовываться приложениями инициатора запроса и модулями записи. Модуль записи SQL реализует необходимые интерфейсы модуля записи. В рамках процесса создания моментального снимка интерфейсы модуля записи SQL вызываются платформой VSS. Модуль записи SQL взаимодействует с экземплярами SQL Server в системе для упрощения создания моментального снимка.

Платформа VSS определяет набор API для использования в инициаторе запроса или приложении резервного копирования. Разработчик приложения резервного копирования должен следовать этим шаблонам вызова API для работы с процессом создания моментальных снимков на платформе VSS. В следующих разделах описывается процесс создания моментального снимка с точки зрения модуля записи SQL. В них также описываются некоторые внутренние взаимодействия между инициатором запроса, платформой VSS, модулем записи SQL и экземплярами SQL Server. Дополнительные сведения об этих действиях и интерфейсах платформы VSS см. в документации по службе теневого копирования томов.

Примечание.

Предполагается, что читатель знаком с платформой VSS и процессом создания резервной копии в целом. Эти разделы содержат дополнительную информацию о том, как модуль записи SQL участвует в процессе создания резервной копии VSS.

Рабочий процесс создания моментального снимка

На рисунке показана схема потока данных во время создания или резервного копирования моментальных снимков на основе компонентов. Чтобы лучше понять основные задачи, связанные с выполнением резервного копирования, полезно разбить этот обзор на следующие этапы:

• Инициализация резервного копирования
• Этап обнаружения резервных копий
• Задачи перед резервным копированием
• Фактическое резервное копирование файлов
• Завершение резервного копирования

Инициализация резервного копирования

На этом этапе резервного копирования запрашивающее приложение привязывается к интерфейсу IvssBackupComponents моментального снимка и инициализирует его при подготовке к резервному копированию. Он также вызывает API IVssGatherWriterMetadata VSS, чтобы сообщить платформе VSS собирать метаданные со всех записи.

Платформа VSS будет вызывать каждый из зарегистрированных модулей записи, включая модуль записи SQL для метаданных модуля записи, с помощью события Onidentify. Модуль записи SQL отправит запрос к экземплярам SQL Server, чтобы получить сведения о метаданных резервной копии для каждой базы данных и создать документ метаданных модуля записи. Этот этап также называется перечислением метаданных.

Документ метаданных модуля записи содержит сведения, передаваемые от модуля записи инициатору запроса (приложению резервного копирования). Документ метаданных модуля записи содержит следующие сведения:

• Идентификатор и понятное имя приложения.
• Где существуют файлы и компоненты.
• Какие файлы необходимо включить в резервную копию или исключить из нее.
• Какие параметры следует использовать во время восстановления.
• Эти сведения передаются обратно инициатору запроса через платформу VSS.

Обнаружение резервных копий

На этом этапе инициатор запроса проверяет документ метаданных модуля записи и создает и заполняет документ компонентов резервного копирования, указывая каждый компонент, для которого необходимо выполнить резервное копирование. В этом документе также указываются необходимые параметры и настройки резервного копирования. Для модуля записи SQL каждый экземпляр базы данных, для которого требуется создать резервную копию, является отдельным компонентом.

Документ компонентов резервного копирования

Это XML-документ, созданный запрашивателем (с помощью IVssBackupComponents интерфейса) в ходе настройки операции восстановления или резервного копирования. Документ компонентов резервного копирования содержит список явно добавленных компонентов из одного или нескольких модулей записи, участвующих в операции резервного копирования или восстановления. Он не содержит сведения о неявно включаемых компонентах. В отличие от этого, документ метаданных модуля записи содержит только компоненты модуля записи, которые могут участвовать в резервном копировании. Сведения о структуре документа компонентов резервного копирования описаны в документации по API VSS.

Задачи перед резервным копированием

Задачи перед резервным копированием в VSS направлены на создание теневой копии томов, содержащих данные для резервного копирования. Приложение резервного копирования сохранит данные из теневой копии, а не из фактического тома.

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

Подготовка к резервному копированию

Инициатору запроса необходимо задать требуемый тип операции резервного копирования (IVssBackupComponents::SetBackupState), а затем через VSS уведомить модули записи, что нужно подготовиться к операции резервного копирования, с помощью IVssBackupComponents::PrepareForBackup.

Модуль записи SQL получает доступ к документу компонента резервного копирования, который содержит сведения о том, какие базы данных подлежат резервному копированию. Все резервные тома должны быть добавлены в набор моментальных снимков тома. Модуль записи SQL обнаружит разорванные базы данных (с резервными томами за пределами набора моментальных снимков) и не сможет создать резервную копию во время события PostSnapshot.

Фактическое резервное копирование файлов

На этом этапе инициатор запроса может переместить данные на резервный носитель, если это необходимо. Взаимодействия на этом этапе происходят между инициатором запроса и платформой VSS. Модуль записи SQL не задействован.

1. Получает состояние модулей записи. Возвращает состояние модулей записи. Инициатору запроса может потребоваться обработать возможные сбои.
2. Выполнение резервного копирования.

Инициатор запроса может переместить данные на носитель резервной копии на этом этапе, если это необходимо.

Резервное копирование завершено

Это событие указывает, что резервное копирование успешно завершено.

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

Примечание.

Инициатор запроса должен явно отправить это событие (событие завершения резервного копирования), чтобы модуль записи SQL зафиксировал резервные копии базовой копии для разностного копирования. Если это событие не получено, создаваемая резервная копия не будет доступной в качестве резервной копии базовой копии для разностного копирования.

Сохранение метаданных модуля записи

Инициатор запроса должен сохранить документ компонентов резервного копирования и все метаданные резервных копий каждого компонента вместе с данными, сохраненными из моментального снимка. Эти метаданные модуля записи необходимы для модуля записи SQL или SQL Server для операций восстановления.

Завершение резервного копирования

Запроситель завершает теневое копирование путем освобождения IVssBackupComponents интерфейса или вызова IVssBackupComponents::DeleteSnapshots.

Документ метаданных модуля записи SQL

Это XML-документ, созданный средством записи (средство записи SQL в данном случае) с помощью IVssCreateWriterMetadata интерфейса и содержащий сведения о состоянии и компонентах средства записи. Сведения о структуре документа метаданных модуля записи описаны в документации по API VSS. Ниже приведены некоторые сведения о документе метаданных модуля записи SQL.

• Сведения об идентификации записи
  • Имя модуля записи — L"SqlServerWriter"
  • Идентификатор класса модуля записи — 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
  • Идентификатор экземпляра модуля записи — L"SQL Server:SQLWriter"
  • VSSUsageType — VSS_UT_USERDATA
  • VSSSourceType — VSS_ST_TRANSACTEDDB
• Сведения об уровне модуля записи — VSS_APP_BACK_END
• Спецификация метода восстановления — VSS_RME_RESTORE_IF_CAN_REPLACE.
• Поддерживаемая схема резервного копирования (API IVssCreateWriterMetadata::SetBackupSchema)
  • VSS_BS_DIFFERENTIAL — разностная резервная копия
  • VSS_BS_TIMESTAMPED — на основе метки времени — для файлов полнотекстового каталога.
  • VSS_BS_LAST_MODIFY — разностное резервное копирование на основе времени последнего изменения.
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET — поддерживает новый параметр целевого расположения.
  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE — поддерживает восстановление с перемещением.
  • VSS_BS_COPY — поддерживает параметр резервного копирования "только для копирования".
• Сведения уровня компонентов. Это сведения уровня компонентов, предоставляемые модулем записи SQL.
  • Тип — VSS_CT_FILEGROUP
  • Имя — имя компонента (имя базы данных)
  • Логический путь — экземпляра сервера (будет иметь вид "сервер\имя_экземпляра" для именованных экземпляров и "сервер" для экземпляра по умолчанию.)
  • Флаги компонента
  • VSS_CF_APP_ROLLBACK_RECOVERY — указывает, что моментальным снимкам SQL Server всегда требуется этап восстановления, чтобы сделать файлы согласованными и пригодными для использования в сценариях без резервного копирования (то есть в случае отката приложений).
  • Возможность выбора — true
  • Возможность выбора для восстановления — true
  • Поддерживаемые методы восстановления — VSS_RME_RESTORE_IF_CAN_REPLACE

Единственным дополнением структуры набора компонентов в SQL Server является введение полнотекстовых каталогов. Полнотекстовые каталоги — это каталоги контейнеров, которые не могут быть выражены в виде файлов журналов или базы данных VSS с учетом того, что файлы журналов и базы данных VSS не имеют рекурсивной спецификации. Таким образом, модуль записи SQL будет использовать компонент файловой группы VSS (VSS_CT_FILEGROUP) для представления компонента уровня базы данных и файлы файловой группы для представления файлов базы данных, журнала и полнотекстового каталога.

Пример документа метаданных модуля записи содержится в конце этого документа.

Инициация моментального снимка. Инициатор запроса запустит процесс создания моментального снимка, вызвав интерфейс платформы VSS DoSnapshotSet.

Создание моментального снимка. Этот этап включает ряд взаимодействий между платформой VSS и модулем записи SQL.

1. Подготовка моментального снимка. Модуль записи SQL вызовет SQL Server для подготовки к созданию моментального снимка.
2. Заморозка. Модуль записи SQL вызовет SQL Server, чтобы заморозить все операции ввода-вывода в каждой из баз данных, для которых выполняется резервное копирование в моментальном снимке. После подтверждения события заморозки на платформе VSS служба VSS создаст моментальный снимок.
3. Разморозка. В этом событии модуль записи SQL вызывает экземпляры SQL Server для "разморозки", или возобновления обычных операций ввода-вывода.

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

После создания моментального снимка. Если для моментального снимка требуется автовосстановление, модуль записи SQL выполняет автовосстановление для каждой базы данных, выбранной для включения в моментальный снимок. Подробное описание см. в разделе "Автоматическое восстановление моментальных снимков".

Процесс восстановления

В этом разделе описывается рабочий процесс операции восстановления и выполняются различные действия.

Рабочий процесс операции восстановления

На следующем рисунке показана схема потока данных во время операции восстановления VSS. Чтобы лучше понять основные задачи, связанные с восстановлением, полезно разбить этот обзор на следующие разделы:

• Инициализация восстановления
• Подготовка к восстановлению
• Фактическое восстановление файлов
• Восстановление, очистка и завершение

Во всех сценариях восстановления VSS на основе компонентов восстановление базы данных осуществляется модулем записи SQL в два отдельных этапа.

• PreRestore: модуль записи SQL обрабатывает проверку, закрытие дескрипторов файлов и т. д.
• После восстановления: модуль записи SQL подключает базу данных и выполняет аварийное восстановление при необходимости.

Между этими двумя этапами приложение резервного копирования отвечает за перемещение соответствующих данных в SQL.

Инициализация восстановления

На этапе инициализации восстановления инициатор запроса должен иметь доступ к хранящимся документам компонентов резервного копирования.

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

Подготовка к восстановлению

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

Если приложение резервного копирования планирует применить разностное резервное копирование или резервное копирование журналов поверх текущей операции восстановления (т. е. требуется "Восстановление WITH NORECOVERY"), следует установить следующий параметр в процессе создания компонента для каждой восстанавливаемой базы данных.

IVssBackupComponents::SetAdditionalRestores(true)

После установки всех необходимых сведений в документе компонента резервного копирования запрос выполняет IVssBackupComponents::PreRestore вызов для создания события PreRestore с помощью VSS, который будет обрабатываться средствами записи.

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

Восстановление файлов

Это просто действие, зависящее от инициатора запроса. Инициатор запроса (приложение резервного копирования) должен скопировать необходимые файлы базы данных (или скопировать соответствующие диапазоны данных для разностного восстановления) в соответствующие места. Модуль записи SQL не задействован в этой операции.

Очистка и завершение

После восстановления всех данных в соответствующие места вызов от инициатора запроса, уведомляющий о завершении операции восстановления (IvssBackupComponents::PostRestore), сообщает модулю записи SQL, что можно запустить действия, выполняемые после восстановления. Модуль записи SQL на этом этапе выполняет стадию повтора восстановления после сбоя. Если восстановление не запрашивается (то есть SetAdditionalRestores(true) не указывается инициатором запроса), стадия отката шага восстановления также выполняется на этом этапе.

Дополнительные сведения о резервном копировании и восстановлении

В этом разделе подробно описаны все параметры резервного копирования и восстановления, поддерживаемые модулем записи SQL.

Инициатор запроса создает теневую копию тома

Модуль записи SQL может участвовать в процессе создания теневого копирования томов (вне контекста резервного копирования и восстановления), так как в набор моментальных снимков тома были добавлены резервные тома файлов базы данных. В этом случае модуль записи SQL Server участвует только в перечислении метаданных, заморозке, разморозке, подготовке к моментальному снимку и координации операций после моментальных снимков (подробные сведения см. на схеме потока данных).

Полное резервное копирование и восстановление

Модуль записи SQL поддерживает операции полного резервного копирования и восстановления в режимах на основе компонентов и не на основе компонентов.

Резервное копирование и восстановление не на основе компонентов

При резервном копировании и восстановлении не на основе компонентов инициатор запроса указывает том или дерево папок для резервного копирования или восстановления. Все данные в указанном томе или папке подлежат резервному копированию и восстановлению.

Резервное копирование

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

Восстановление

Инициатор запроса восстанавливает базы данных, резервные копии которых были созданы в режиме, не основанном на компонентах. Такие восстановления не могут быть выполнены только накатом, например восстановлением журнала или разностным восстановлением.

Для операций восстановления, не основанных на компонентах, восстановление необходимо выполнить с экземпляром SQL Server в автономном режиме или целевые базы данных нужно удалить или отсоединить, чтобы убедиться, что файлы находятся в автономном режиме. Файлы копируются на месте, а затем присоединяются базы данных. Все это происходит за пределами модуля записи SQL.

Резервное копирование и восстановление на основе компонентов

При резервном копировании на основе компонентов инициатор запроса явным образом выбирает компоненты базы данных (из метаданных, которые модуль записи SQL возвращает клиенту) для резервного копирования и восстановления.

Резервное копирование

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

Полное восстановление без наката

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

Нет метаданных/не нужен накат

Если метаданные модуля записи (метаданные резервного копирования на основе компонентов) не сохранены во время операции восстановления, восстановление необходимо выполнить с экземпляром SQL Server в автономном режиме или целевые базы данных нужно удалить или отсоединить, чтобы убедиться, что файлы находятся в автономном режиме. Файлы копируются на месте, а затем присоединяются базы данных. Все это происходит за пределами модуля записи SQL.

Метаданные существуют, но дополнительный накат не требуется

Инициатор запроса восстанавливает базы данных, резервные копии которых были созданы в режиме, не основанном на компонентах, но накат не запрошен. В этом случае SQL Server выполняет восстановление после сбоя в базе данных в ходе восстановления.

Полное восстановление с дополнительными накатами

Инициатор запроса может запустить восстановление, указав параметр SetAdditionalRestores(true). Этот параметр указывает, что инициатор запроса будет выполнять дальнейшие восстановления с накатом (например, восстановление журнала, разностное восстановление и т. д.). Это указывает SQL Server не выполнять последний шаг восстановления в конце операции восстановления.

Это возможно только в том случае, если метаданные модуля записи были сохранены во время резервного копирования и доступны модулю записи SQL во время восстановления. Необходимо запустить службу SQL Server, чтобы инициатор запроса мог указать VSS, что необходимо выполнить действие восстановления.

Модуль записи SQL Server ожидает следующую последовательность:

1. Подготовка к восстановлению каждой базы данных. Это действие включает закрытие всех дескрипторов файлов, чтобы разрешить копирование или подключение файлов базы данных приложением, инициирующим запрос.
2. Файлы копируются или подключаются приложением, инициирующим запрос.
3. Завершение восстановления (WITH NORECOVERY). Базы данных подключаются к сети, но в состоянии "Восстановление".

Затем можно использовать традиционные резервные копии SQL, разностные или копии журнала, для наката базы данных с помощью VDI/T-SQL или путем применения разностного восстановления с помощью платформы VSS.

Поддержка полнотекстовых каталогов

Модуль записи SQL сообщает о контейнерах полнотекстового каталога с рекурсивными спецификациями файлов в компонентах базы данных в документе метаданных модуля записи. Они автоматически включаются в резервную копию при выборе компонента базы данных

разностное резервное копирование и восстановление;

Операция разностного резервного копирования сохраняет только данные, которые были изменены с момента создания последней полной резервной копии. Разностная резервная копия содержит только те части файлов базы данных, которые были изменены. Для такого резервного копирования приложению резервного копирования или инициатору запроса потребуется информация о расположении изменений в файлах базы данных, чтобы можно было выполнить резервное копирование соответствующих разделов файлов. Во время разностной операции резервного копирования средство записи SQL предоставляет эти сведения в формате, указанном в разделе "Сведения о частичном файле VSS". Эти сведения можно использовать для резервного копирования только измененной части файлов базы данных.

Резервное копирование

Инициатор запроса может выдать разностную резервную копию, задав параметр DIFFERENTIAL (VSS_BT_DIFFERENTIAL) в документе компонентов резервного копирования (IVssBackupComponents::SetBackupState) при запуске операции резервного копирования с помощью VSS. Модуль записи SQL передает сведения о частичном файле (которые возвращаются SQL Server) в VSS. Инициатор запроса может получить эти сведения о файле путем вызова API VSS IVssComponent::GetPartialFile. Эти сведения о частичном файле позволяют инициатору запроса выбрать только измененные диапазоны байтов для резервного копирования файлов базы данных.

На этапе выполнения задач перед резервным копированием модуль записи SQL проверяет, существует ли отдельная базовая копия для разностного копирования для каждой выбранной базы данных.

Во время события PostSnapshot модуль записи SQL получит частичные сведения о файле из SQL Server и добавит его в документ компонента резервного копирования с помощью IVssComponent::AddPartialFile вызова.

Примечание.

Модуль записи SQL поддерживает только один базовый план для разностного резервного копирования для разностных резервных копий. Несколько базовых планов не поддерживается.

Формат сведений о частичном файле

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

Запрашивающий может определить эти файлы путем вызова IVssComponent::GetPartialFileCount и IVssComponent::GetPartialFile. IVssComponent::GetPartialFile возвращает путь и имя файла, указывающее на файл, и строку диапазонов, указывающую, что необходимо создать резервную копию в файле.

Дополнительные сведения об извлечении сведений о частичном файле см. в документации по VSS.

Файлы для резервного копирования

На этом этапе приложение резервного копирования должно просмотреть метаданные модуля записи, хранящиеся в документе компонентов резервного копирования, и выполнить резервное копирование только соответствующих частей файлов. (Для файлов полнотекстового каталога эта резервная копия должна выполняться на основе меток времени файла. Это описано далее в этом документе.

Разностная резервная копия всегда будет соответствовать последней базовой резервной копии, существующей для базы данных. Во время восстановления SQL Server обнаружит несоответствие базовой и разностной резервных копий. Таким образом, приложение резервного копирования или системный администратор обязаны убедиться, что разностная копия относится к ожидаемому полному резервному копированию. Если какая-то процедура из внешнего канала создала другую полную резервную копию, приложение резервного копирования может не восстановить разностную копию, так как не является владельцем базовой резервной копии.

В настоящее время, если сведения о диапазоне байтов (сведения о частичном файле) слишком велики (превышают размера буфера 64 Кбайт), SQL Server выдаст сообщение об ошибке с указанием выполнить полное резервное копирование.

Устранение неполадок

Добавление, удаление, сжатие, увеличение, логическое переименование и физическое переименование файла составляют интересные случаи при резервном копировании.

Новые файлы, добавленные после создания базовой копии

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

Файлы, удаленные после создания базовой копии

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

Файлы, сжатые после создания базовой копии

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

Файлы, увеличенные после создания базовой копии

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

Файл логически переименован после создания базовой копии

Логическое переименование файла не влияет на резервное копирование или восстановление, так как на логическое имя файла нет ссылок в документе метаданных модуля записи или в документе компонентов резервного копирования. (См. документ метаданных записи: пример для получения дополнительных сведений.)

Файл физически переименован после создания базовой копии

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

Восстановление

Во время разностного восстановления метаданные резервного копирования, которые инициатор запроса передает в модуль записи SQL, имеют сведения о типе резервного копирования. Поэтому специальная обработка от модуля записи SQL не требуется. SQL Server узнает, что это разностное восстановление. SQL Server обрабатывает такое разностное восстановление так же, как и собственное разностное восстановление, которое не выполняется с помощью VSS.

Этап до восстановления

На этом этапе SQL Server изменит размер всех файлов до нужного на основе метаданных файла разностной резервной копии. Если файл увеличился, SQL Server исключает увеличенную часть. Если требуется создать новый файл (он был создан после создания базовой копии), SQL Server исключает новый файл. Он также закрывает все дескрипторы файлов, чтобы приложение резервного копирования могло перезаписывать файлы с восстановленными данными с резервного носителя.

Восстановление файлов

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

Добавление, удаление, увеличение, сжатие, логическое переименование или физическое переименование файла базы данных представляет интересные случаи во время восстановления.

Если файл базы данных был добавлен после создания полной базовой копии

Такие файлы должны быть предварительно созданы SQL Server на этапе подготовки к восстановлению. Они должны были быть расширены до правильного размера и отсчитываются от нуля. Клиенту необходимо указать данные только в соответствии с частичной спецификацией (частичная спецификация включает все выделенные экстенты).

Если файл базы данных был удален после создания полной базовой копии

Частичные сведения, предоставленные SQL Server, не включают сведения об отслеживании для такого удаления файлов. SQL Server выполняет обнаружение удаляемых файлов путем сравнения метаданных восстановленных файлов с существующими контейнерами и их фактического удаления. Это делается перед восстановлением на этапе подготовки.

Если файл базы данных был увеличен после создания полной базовой копии

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

Если файл базы данных был сжат после создания полной базовой копии

SQL Server должен усечь файл до требуемого размера в соответствии с метаданными. Это делается перед восстановлением на этапе подготовки.

Если файл базы данных был логически переименован после создания полной базовой копии

Это не повлияет на восстановление, так как логическое имя не отображается в документе метаданных модуля записи или в документе компонентов резервного копирования. Логическое переименование будет восстановлено, когда клиент применит изменение к файлу базы данных-источника, который содержит сведения о системном каталоге.

Если файл базы данных был физически переименован после создания полной базовой копии

Если к моменту создания разностной резервной копии переименование не было применено, клиент восстановит данные в старом расположении. Перезагрузка базы данных после восстановления приведет к тому, что физическое переименование вступит в силу. Если в момент создания разностной резервной копии физическое переименование файла уже применено, то резервная копия части данных создается по новому физическому пути.

После восстановления

Во время событий после восстановления модуль записи SQL выполняет обычную операцию повтора и восстановления (если SetAdditionalRestores() имеет значение False) базы данных.

Разностное резервное копирование и восстановление полнотекстовых каталогов

Полнотекстовые каталоги SQL Server являются частью ресурсов базы данных, которые необходимо архивировать или восстанавливать вместе с остальными файлами базы данных. Разностная резервная копия для полнотекстового каталога основывается на метке времени. При разностном резервном копировании и восстановлении SQL Server VSS используется одна базовая резервная копия. Иными словами, для разных контейнеров не будет разных базовых копий. Для резервного копирования полнотекстового каталога VSS это означает, что для всех контейнеров полнотекстового каталога разностная резервная копия будет основываться на одной метке времени, в отличие от собственной разностной резервной копии SQL, в которой имеется одна база меток времени для каждого контейнера полнотекстового каталога.

В VSS эта метка времени выражается как свойство на уровне компонента, которое задается во время полного резервного копирования и используется во время последующего разностного резервного копирования.

OnIdentify

В OnIdentify модуль записи SQL вызывает IVssCreateWriterMetadata::SetBackupSchema(), чтобы задать значение VSS_BS_TIMESTAMPED. Это указывает приложению резервного копирования, что модуль записи SQL владеет управлением базовой копией.

Задание базовой метки времени

Базовая метка времени задается во время полного резервного копирования. В OnPostSnapshot()записи вызывается IVssComponent::SetBackupStamp() для хранения метки времени с компонентом в документе резервной копии.

Разностное резервное копирование

Приложение резервного копирования получит эту метку времени из базовой полной резервной копии и сделает метку времени доступной для записи путем вызова IVssComponent::GetBackupStamp() для получения базовой метки из предыдущей базовой резервной копии. Затем он делает его доступным для средства записи путем вызова IVssBackupComponent::SetPreviousBackupStamp(). Затем модуль записи извлекает метку путем вызова IVssComponent::GetPreviousBackupStamp() и преобразует ее в метку времени, используемую для IVssComponent::AddDifferencedFilesByLastModifyTime().

Задачи приложения резервного копирования во время разностного резервного копирования. Во время разностного резервного копирования приложение резервного копирования отвечает за следующие задачи:

• Резервное копирование любого файла (всего файла), метка времени последнего изменения которого превышает метку времени, заданную "временем последнего изменения" для набора файлов в компоненте.
• Отслеживание и обнаружение удаленных файлов.

Задачи приложения резервного копирования во время разностного восстановления. Во время разностного восстановления приложение резервного копирования отвечает за следующие задачи:

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

Резервная копия, предназначенная только для копирования

Иногда необходимо создать резервную копию, предназначенную для особой цели. Например, может потребоваться создать копию базы данных для тестирования. Эта резервная копия не влияет на обычные процедуры резервного копирования и восстановления базы данных. Параметр COPY_ONLY указывает, что резервная копия выполняется по внешнему каналу и не должна влиять на нормальную последовательность резервных копий. Модуль записи SQL поддерживает тип резервного копирования "только для копирования" с экземплярами SQL Server.

Во время этапа обнаружения резервных копий средство записи SQL будет указывать его возможность выполнять резервное копирование только для копирования, задав поддерживаемый параметр схемы резервного копирования VSS_BS_COPY с помощью IVssCreateWriterMetadata::SetBackupSchema вызова. Запрашивающий объект может задать тип резервного копирования как резервную копию только для копирования, задав параметр VSS_BACKUP_TYPE как VSS_BT_COPY с вызовом IVssBackupComponents::SetBackupState.

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

Восстановление с перемещением

VSS позволяет приложению резервного копирования (запрашивателю) указать новый целевой объект восстановления с помощью IVssComponent::SetNewTarget вызова. В PreRestore() и PostRestore() модуль записи SQL проверяет, указан ли хотя бы один новый целевой объект. Приложение резервного копирования должно физически скопировать файлы в новое место во время фактического восстановления или копирования файлов.

Приложению резервного копирования разрешено указывать только новые целевые объекты для физического пути, но не спецификацию файла. Например, для файла базы данных, расположенного по адресу c:\data\test.mdf, фактическое имя файла test.mdf изменить нельзя. Можно изменить только путь c:\data. Для контейнера полнотекстового каталога, расположенного по адресу c:\ftdata\foo, так как спецификация файла в VSS имеет значение "*", а спецификация пути в VSS — c:\ftdata\foo, можно изменить весь путь.

Переименование базы данных

Инициатору запроса может потребоваться восстановить базу данных SQL с новым именем, особенно если база данных должна быть восстановлена параллельно с исходной базой данных. Этот параметр можно указать инициатором запроса во время операции восстановления, установив настраиваемый параметр восстановления как "Новое имя компонента" = <"Новое имя"> с помощью вызова IVssBackupComponents::SetRestoreOptions() VSS (в параметре wszRestoreOptions).

Модуль записи SQL будет принимать все содержимое значения нового имени компонента и использовать его в качестве нового имени для восстановленной базы данных. Если параметр не указан, SQL восстановит базу данных с исходным именем (имя компонента).

Примечание.

Сейчас модуль записи SQL не поддерживает "Переименование между экземплярами" для перемещения базы данных в новый экземпляр.

Автоматические восстановленные моментальные снимки

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

Моментальные снимки можно автоматически восстановить в рамках процесса создания моментального снимка. В рамках документа метаданных модуля записи модуль записи SQL будет устанавливать флаг компонента VSS_CF_APP_ROLLBACK_RECOVERY, чтобы указать, что необходимо выполнить восстановление базы данных в моментальном снимке, прежде чем можно будет получить доступ к базе данных при указании набора снимков. Инициатор запроса может указать, что моментальный снимок должен быть моментальным снимком отката приложения (то есть все файлы базы данных в моментальном снимке должны быть в согласованном состоянии для использования приложением) или моментальным снимком резервной копии (моментальным снимком, используемым для резервного копирования данных с целью восстановления позже в случае сбоя системы).

Инициатор запроса должен задать VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, чтобы указать, что для этого компонента выполняется резервное копирование не для целей создания резервной копии. Тогда VSS сопоставит флаг VSS_CF_APP_ROLLBACK_RECOVERY, указанный модулем записи SQL для выбранного компонента, с VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, и определит, что выполняется автоматическое восстановление. VSS сделает моментальный снимок доступным для записи на ограниченный период времени и автоматически добавит VSS_VOLSNAP_ATTR_AUTORECOVERY в контекст моментального снимка.

В SQL Server автоматическое восстановление следует применять только к моментальным снимкам отката приложений, но не к моментальным снимкам резервных копий. Для моментальных снимков отката приложений процесс автовосстановления инициируется модулем записи SQL во время PostSnapShotevent. Этот процесс выполняет следующие действия для каждой явно выбранной (инициатором запроса) базы данных SQL Server в наборе моментальных снимков:

• Присоедините базу данных моментальных снимков к исходному экземпляру SQL Server (то есть к экземпляру, к которому присоединена исходная база данных).

• Восстановите базу данных (это происходит как часть операции "присоединение").

• Уменьшение размера файла журнала.

  Это действие сокращает объем ненужного "копирования при записи", которое должно выполняться платформой VSS, если поставщик VSS является "поставщиком программного обеспечения". Сжатие файлов журнала является поведением по умолчанию. Его можно отключить, присвоив параметру следующего раздела реестра значение 1.

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\ Settings\DisableLogShrink

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

• Отсоединение базы данных.

Теперь у нас есть согласованный и восстановленный моментальный снимок, который можно присоединить к запросам.

Транзакции с несколькими базами данных

В некоторых случаях базы данных моментальных снимков могут содержать некоторые активные транзакции с несколькими базами данных. Во время операции восстановления модуль записи SQL присоединяет базу данных к моментальным снимкам с параметром предполагаемого прерывания. Это приведет к откату любой транзакции с несколькими базами данных, которая еще не зафиксирована (включая все транзакции, которые находятся в состоянии "Подготовлено к фиксации"). Это может привести к несогласованности баз данных в наборе снимков. Например, рассмотрим две базы данных A и B. Между этими двумя базами данных имеется распределенная транзакция, и эта транзакция находится в зафиксированном состоянии в базе данных A и в состоянии "Подготовлено к фиксации" в базе данных B. В рамках процесса автовосстановления эта транзакция будет зафиксирована в базе данных A и откачена в базе данных B. Это может привести к некоторой несогласованности в наборе снимков.

Координатор распределенных транзакций Майкрософт (MS DTC), который должен быть выпущен в сроки выпуска Longhorn платформой VSS, устранит эту проблему несогласованности для транзакций, охватывающих несколько баз данных, в экземплярах SQL Server. В следующей версии SQL Server эти несоответствия для транзакций в нескольких базах данных исправлены в экземпляре SQL Server.

Влияние автоматически восстанавливаемых моментальных снимков на безопасность

Для моментальных снимков VSS после автоматического восстановления файлы будут защищены с помощью списков контроль доступа (ACL), чтобы разрешить доступ только к специальной встроенной группе, к которой принадлежит учетная запись SQL Server. Это означает, что член группы администраторов или этой специальной группы сможет присоединить базу данных. Клиент, запрашивающий присоединение файлов базы данных в моментальном снимке, должен быть членом встроенной группы, группы администраторов или учетной записи SQL Server.

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

Если база данных master восстанавливается вместе с пользовательскими базами данных, использующими простую модель восстановления, пользовательские базы данных можно восстановить с помощью той же методики, что и в базе данных master: при завершении работы экземпляра просто скопируйте или подключите тома. При запуске экземпляра SQL все восстанавливается.

Пользовательские базы данных с накатом

Если пользовательские базы данных необходимо восстановить и выполнить накат вместе с восстановлением базы данных master, экземпляр не должен запускать и восстанавливать базы данных master и пользовательские базы данных вместе.

Процедура происходит следующим образом:

1. Убедитесь, что экземпляр SQL Server остановлен.
2. Выполните восстановление в два этапа.
   1. Восстановите системные базы данных и пользовательские базы данных, которые следует восстановить одновременно (то есть пользовательские базы данных в простой модели восстановления) с помощью копирования файлов /volume-mount через VSS.
      1. Если пользовательские базы данных, для которых выполняется накат, находятся не на том же томе, что и системные базы данных, то этот том не следует возвращать на этом этапе. Для этого сценария требуется планирование перед резервным копированием.
      2. Если пользовательские базы данных находятся на том же томе, что и системные базы данных, то пользовательские базы данных должны быть скрыты от SQL Server.
   2. Запустите экземпляр SQL Server с помощью параметра -f. (При использовании параметра запуска -f можно восстановить только базу данных master.)
      1. Проблема с ALTER DATABASE <x> SET OFFLINE для каждой базы данных, для переключаемой на нее. (Также можно отсоединить базу данных)
      2. Остановка экземпляра SQL Server.
      3. Запустите экземпляр SQL Server (файлы пользовательских баз данных для наката не видны для SQL Server).

Используйте VSS для восстановления пользовательских баз данных с параметром WITH NORECOVERY, как описано в разделе "Полное восстановление с накатом".

Документ метаданных записи: пример

База данных DB1, которая принадлежит экземпляру SQL Server Instance1 на компьютере Server1 и содержит следующие файлы базы данных или журнала:

• Файл базы данных "primary", находящийся по адресу c:\db\DB1.mdf
• Файл базы данных "secondary", находящийся по адресу c:\db\DB1.ndf
• Файл журнала базы данных "log", находящийся по адресу c:\db\DB1.ldf
• Полнотекстовый каталог с именем "foo", хранящийся в каталоге c:\db\ftdata\foo
• Полнотекстовый каталог с именем "bar", хранящийся в каталоге c:\db\ftdata\bar

Ниже приведены метаданные модуля записи базы данных:

Компонент файловой группы уровня базы данных

Файл базы данных-источника:

ComponentType: VSS_CT_FILEGROUP
LogicalPath: "Server1\Instance1"
ComponentName: "DB1"
Caption: NULL
pbIcon: NULL
cbIcon: 0
bRestoreMetadata: FALSE
NotifyOnBackupComplete: TRUE
Selectable: TRUE
SelectableForRestore: TRUE
ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

Файл базы данных-получателя:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.mdf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ndf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Полнотекстовый файл log:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ldf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Полнотекстовый файл foo:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\foo"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Полнотекстовый файл bar:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\bar"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Если экземпляр сервера является экземпляром по умолчанию на компьютере, то логический путь становится одной частью — "Server1".

Особые случаи

В этом разделе описываются некоторые особые случаи, возникающие при операциях резервного копирования и восстановления на основе модуля записи SQL.

Автоматически закрытые базы данных

Для резервных копий, не основанных на компонентах, автозакрытие баз данных выполняется при проверке на наличие разрывов, но при выполнении операций резервного копирования автоматически закрытые базы данных не замораживаются явным образом.

Ожидаемый сценарий заключается в том, что может существовать множество закрытых баз данных, и мы хотим максимально сократить затраты моментального снимка. Автоматически закрытые базы данных обычно используются в бюджетных конфигурациях, где ресурсы ограничены.

Список файлов

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

Остановленные экземпляры

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

Если экземпляр останавливается в интервале между перечислением и событием подготовки к резервному копированию, все базы данных в остановленном экземпляре игнорируются.

Системные и пользовательские базы данных

Системные базы данных в SQL Server включают базы данных master, model и msdb, которые поставляются и устанавливаются в составе SQL Server. В этом разделе описывается обработка этих баз данных в процессе резервного копирования моментальных снимков VSS.

Базу данных master можно восстановить только путем остановки экземпляра, замены файлов базы данных (выполняемой приложением резервного копирования) и перезапуска экземпляра. Накат невозможен.

Модуль записи SQL поддерживает восстановление баз данных model и msdb в сети без завершения работы экземпляра.

См. также

Приложения резервного копирования SQL Server — ведение журнала модуля записи SQL
BACKUP (Transact-SQL)
RESTORE (Transact-SQL)
Резервное копирование и восстановление баз данных SQL Server
Резервные копии только для копирования (SQL Server)
Резервные копии журналов транзакций (SQL Server)
Применение резервных копий журналов транзакций (SQL Server)
Руководство по архитектуре журнала транзакций SQL Server и управлению им