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

Применимо к:SQL Server в Windows

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 Writer устанавливается с использованием учетной записи локальной системы. Так как модуль записи SQL должен взаимодействовать с SQL Server с использованием эксклюзивных интерфейсов API VDI, учетная запись модуля записи SQL должна иметь достаточные права доступа как для SQL Server, так и для VSS. Настройка службы в качестве локальной системной учетной записи предоставляет достаточные права для правильной работы службы.

Это важно

Убедитесь, что служба записи SQL выполняется под учетной записью локальной системы и что учетная запись SQL Server NT SERVICE\SQLWriter входит в роль sysadmin .

Повторно активируйте и запустите службу записи SQL

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

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

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

Примечание.

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

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

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

• Разностное резервное копирование и восстановление: модуль записи SQL поддерживает разностное резервное копирование и восстановление с помощью двух разностных механизмов VSS:

  • Частичный файл: модуль записи SQL использует механизм частичного файла VSS для создания отчетов об измененных диапазонах байтов в файлах базы данных.

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

• Восстановление с перемещением: модуль записи SQL поддерживает спецификацию VSS "New Target" во время восстановления. Спецификация New Target позволяет переместить файл базы данных или файл журнала или контейнер полнотекстового каталога в рамках операции восстановления.

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

• Резервное копирование только для копирования: иногда необходимо создать резервную копию, предназначенную для специального назначения, например, если необходимо создать копию базы данных для тестирования. Эта резервная копия не должна влиять на общие процедуры резервного копирования и восстановления для базы данных. COPY_ONLY При использовании параметра указывается, что резервное копирование выполняется вне полосы и не должно влиять на обычную последовательность резервных копий. Модуль записи SQL поддерживает тип резервного копирования copy-only для экземпляров SQL Server.

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

Эти новые функции и их использование подробно описаны в разделе "Сведения о параметрах резервного копирования и восстановления " в этой статье.

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

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

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

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

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

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

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

Поддержка версий

Модуль записи SQL поставляется в составе SQL Server и поддерживает только экземпляры SQL Server. Запись SQL также перечисляет экземпляры SQL Server Express, включая пользовательские экземпляры, запускаемые в редакции SQL Server Express.

Некомпонентные операции резервного копирования

Некомпонентные резервные копии неявно выбирают базы данных с помощью списка томов в наборе моментальных снимков. Модуль записи 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).

Примечание.

Предполагается, что вы знакомы с платформой 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 Writer зафиксировал базовые резервные копии для дифференциального копирования. Если это событие не получено, созданная резервная копия не является подходящей разностной базовой резервной копией.

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

Пользователь должен сохранить документ резервного компонента и метаданные каждого резервного компонента вместе с данными, полученными из моментального снимка. Эти метаданные модуля записи необходимы для модуля записи 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
  • Имя — имя компонента (имя базы данных)
  • Логический путь — экземпляр сервера (в виде "server\instance-name" для именованных экземпляров и "сервера" для экземпляра по умолчанию).
  • Флаги компонента
  • VSS_CF_APP_ROLLBACK_RECOVERY — указывает на то, что моментальные снимки SQL Server всегда требуют этапа "восстановления", чтобы файлы становились согласованными и пригодными для использования в сценариях, не связанных с резервным копированием (то есть, при откате приложений).
  • Возможность выбора — да
  • Возможность выбора для восстановления — true
  • Поддерживаемые методы восстановления: VSS_RME_RESTORE_IF_CAN_REPLACE

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

Пример файла метаданных записи представлен в конце документа.

Инициализация моментального снимка

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

Создать моментальный снимок

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

1. Подготовьте моментальный снимок. Программа записи SQL обращается к SQL Server для подготовки к созданию моментального снимка.

2. Заморозка. Средство записи SQL вызывает SQL Server для замораживания всех операций ввода-вывода базы данных для каждой базы данных, резервной копии которой выполняется в моментальном снимке. После возвращения события заморозки в платформу VSS VSS создает моментальный снимок.

3. Разморозка. В этом событии средство записи SQL вызывает экземпляры SQL Server для оттаивания или возобновления обычных операций ввода-вывода.

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

Моментальный снимок после создания моментального снимка

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

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

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

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

На следующем рисунке показана схема потока данных во время операции восстановления VSS.

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

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

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

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

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

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

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

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

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

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

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

IVssBackupComponents::SetAdditionalRestores(true)

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

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

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

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

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

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

Сведения о параметрах резервного копирования и восстановления

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

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

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

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

Модуль записи 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. Завершите восстановление (с NORECOVERY). Базы данных переводятся в онлайн-режим, но в состояние восстановления.

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

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

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

дифференциальное резервное копирование и восстановление

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Файлы сократились после того, как база была взята

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

Файлы выросли после того, как база была взята

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

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

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

Для получения дополнительной информации см. в этой статье пример документа метаданных Writer ниже.

Файл физически переименован после того, как база была взята

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

Восстановить

Во время разностного восстановления метаданные резервного копирования, которые инициатор запроса передает в модуль записи 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 Server, в которой существует одна база меток времени для каждого контейнера полнотекстового каталога.

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

OnIdentify

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

Настройка базовой метки времени

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

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

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

Ответственность приложения резервного копирования во время разностной резервной копии

Во время разностной резервной копии приложение резервного копирования отвечает за:

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

• Отслеживание и обнаружение удаленных файлов.

Обязанности приложения резервного копирования во время разностного восстановления

Во время разностного восстановления приложение резервного копирования отвечает за:

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

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

• Усечение файла до того же размера, что и у восстановленного файла, если восстановленный файл меньше, чем существующий файл.

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

Только копирование

Иногда необходимо создать резервную копию, предназначенную для специального назначения. Например, может потребоваться создать копию базы данных для тестирования. Эта резервная копия не должна влиять на общие процедуры резервного копирования и восстановления для базы данных. COPY_ONLY При использовании параметра указывается, что резервное копирование выполняется вне полосы и не должно влиять на обычную последовательность резервных копий. Модуль записи SQL поддерживает тип резервного копирования copy-only для экземпляров 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 Server с новым именем, особенно если база данных должна быть восстановлена параллельно с исходной базой данных. Этот параметр можно указать в запросе во время операции восстановления, задав настраиваемый параметр восстановления как "Новое имя компонента" = <"Новое имя"> с помощью вызова IVssBackupComponents::SetRestoreOptions() VSS (в параметре wszRestoreOptions ).

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

Примечание.

В настоящее время модуль записи 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 Server базы данных моментальных снимков иногда могут содержать активные транзакции с несколькими базами данных. Во время операции восстановления средство записи SQL присоединяет базу данных к моментальным снимкам с параметром предполагаемого прерывания. Это приведет к откату всех транзакций с несколькими базами данных, которые еще не зафиксированы (включая транзакции, которые находятся в состоянии подготовки к фиксации). Это может привести к некоторым несоответствиям между базами данных в наборе моментальных снимков.

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

Более новые версии Windows имеют улучшенный компонент координатора распределенных транзакций Майкрософт (MS DTC), который устраняет эту проблему несоответствия для транзакций, охватывающих базы данных в экземплярах SQL Server. Новые версии SQL Server исправляют эти несоответствия для транзакций, охватывающих базы данных в экземпляре SQL Server.

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

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

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

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

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

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

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

1. Убедитесь, что экземпляр SQL Server остановлен.

2. Выполните восстановление в два этапа.

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

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

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

   2. Запустите экземпляр SQL Server с помощью -f параметра. (При использовании -f параметра запуска можно восстановить только master базу данных.)

      1. ALTER DATABASE <database> SET OFFLINE Для переката каждой базы данных (или детатации базы данных).

      2. Остановка экземпляра SQL Server.

      3. Запустите экземпляр SQL Server (файлы для пользовательских баз данных для переката не отображаются в SQL Server).

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

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

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

• Файл базы данных с именем primary, хранящийся в c:\db\DB1.mdf
• Файл базы данных с именем "вторичный", хранящийся в 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

Полнотекстовый файл журнала:

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

Полнотекстовая строка:

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 онлайн без остановки экземпляра.

Связанный контент

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