Инструкции RESTORE (Transact-SQL)

Восстанавливает резервные копии баз данных SQL, созданные с помощью команды BACKUP.

Выбор продукта

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

Дополнительные сведения о соглашениях о синтаксисе см. в статье Соглашения о синтаксисе в Transact-SQL.

* SQL Server *  

Управляемый экземпляр SQL

Analytics Platform
System (PDW)

 

SQL Server

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

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

Другие ресурсы

• Дополнительные сведения о сценариях восстановления в SQL Server см. в статье Обзор процессов восстановления (SQL Server).
• При восстановлении базы данных из другого экземпляра примите во внимание сведения из раздела Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).
• Для дополнительных сведений о восстановлении с помощью хранилища BLOB-объектов Microsoft Azure см. Резервное копирование и восстановление SQL Server с помощью хранилища BLOB-объектов Microsoft Azure.
• В SQL Server 2022 (16.x) впервые появилось резервное копирование и восстановление в совместимое с S3 хранилище объектов. Дополнительные сведения о восстановлении из хранилища объектов, совместимого с S3, см. в статье о резервном копировании и восстановлении SQL Server с хранилищем объектов, совместимым с S3. Также просмотрите параметр резервного копирования SQL Server по URL-адресу для хранилища объектов, совместимого с S3.

Синтаксис

• Дополнительные сведения об аргументах см. в статье Аргументы инструкций RESTORE (Transact-SQL).

--To Restore an Entire Database from a Full database backup (a Complete Restore):
RESTORE DATABASE { database_name | @database_name_var }
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH
   {
    [ RECOVERY | NORECOVERY | STANDBY =
        {standby_file_name | @standby_file_name_var }
       ]
   | ,  <general_WITH_options> [ ,...n ]
   | , <replication_WITH_option>
   | , <change_data_capture_WITH_option>
   | , <FILESTREAM_WITH_option>
   | , <service_broker_WITH options>
   | , <point_in_time_WITH_options-RESTORE_DATABASE>
   } [ ,...n ]
 ]
[;]

--To perform the first step of the initial restore sequence of a piecemeal restore:
RESTORE DATABASE { database_name | @database_name_var }
   <files_or_filegroups> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
      PARTIAL, NORECOVERY
      [  , <general_WITH_options> [ ,...n ]
       | , <point_in_time_WITH_options-RESTORE_DATABASE>
      ] [ ,...n ]
[;]

--To Restore Specific Files or Filegroups:
RESTORE DATABASE { database_name | @database_name_var }
   <file_or_filegroup> [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
   {
      [ RECOVERY | NORECOVERY ]
      [ , <general_WITH_options> [ ,...n ] ]
   } [ ,...n ]
[;]

--To Restore Specific Pages:
RESTORE DATABASE { database_name | @database_name_var }
   PAGE = 'file:page [ ,...n ]'
 [ , <file_or_filegroups> ] [ ,...n ]
 [ FROM <backup_device> [ ,...n ] ]
   WITH
       NORECOVERY
      [ , <general_WITH_options> [ ,...n ] ]
[;]

--To Restore a Transaction Log:
RESTORE LOG { database_name | @database_name_var }
 [ <file_or_filegroup_or_pages> [ ,...n ] ]
 [ FROM <backup_device> [ ,...n ] ]
 [ WITH
   {
     [ RECOVERY | NORECOVERY | STANDBY =
        {standby_file_name | @standby_file_name_var }
       ]
    | , <general_WITH_options> [ ,...n ]
    | , <replication_WITH_option>
    | , <point_in_time_WITH_options-RESTORE_LOG>
   } [ ,...n ]
 ]
[;]

--To Revert a Database to a Database Snapshot:
RESTORE DATABASE { database_name | @database_name_var }
FROM DATABASE_SNAPSHOT = database_snapshot_name

<backup_device>::=
{
   { logical_backup_device_name |
      @logical_backup_device_name_var }
 | { DISK
     | TAPE
     | URL
   } = { 'physical_backup_device_name' |
      @physical_backup_device_name_var }
}

<files_or_filegroups>::=
{
   FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 | READ_WRITE_FILEGROUPS
}

<general_WITH_options> [ ,...n ]::=
--Restore Operation Options
   MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'
          [ ,...n ]
 | REPLACE
 | RESTART
 | RESTRICTED_USER | CREDENTIAL

--Backup Set Options
 | FILE = { backup_set_file_number | @backup_set_file_number }
 | PASSWORD = { password | @password_variable }
 | [ METADATA_ONLY | SNAPSHOT ] [ DBNAME = { database_name | @database_name_variable } ]

--Media Set Options
 | MEDIANAME = { media_name | @media_name_variable }
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

--Data Transfer Options
 | BUFFERCOUNT = { buffercount | @buffercount_variable }
 | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options
 | { CHECKSUM | NO_CHECKSUM }
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Monitoring Options
 | STATS [ = percentage ]

--Tape Options.
 | { REWIND | NOREWIND }
 | { UNLOAD | NOUNLOAD }

<replication_WITH_option>::=
 | KEEP_REPLICATION

<change_data_capture_WITH_option>::=
 | KEEP_CDC

<FILESTREAM_WITH_option>::=
 | FILESTREAM ( DIRECTORY_NAME = directory_name )

<service_broker_WITH_options>::=
 | ENABLE_BROKER
 | ERROR_BROKER_CONVERSATIONS
 | NEW_BROKER

<point_in_time_WITH_options-RESTORE_DATABASE>::=
 | {
   STOPAT = { 'datetime'| @datetime_var }
 | STOPATMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime']
 | STOPBEFOREMARK = 'lsn:lsn_number'
                 [ AFTER 'datetime']
   }

<point_in_time_WITH_options-RESTORE_LOG>::=
 | {
   STOPAT = { 'datetime'| @datetime_var }
 | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime']
 | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
                 [ AFTER 'datetime']
   }

Аргументы

Описание аргументов см. в статье Аргументы инструкций RESTORE (Transact-SQL).

Сведения о сценариях восстановления

SQL Server поддерживает разные сценарии восстановления.

• полное восстановление базы данных

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

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

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

• Восстановление страницы

  Производится восстановление отдельных страниц. Восстановление страницы возможно только в моделях полного восстановления и восстановления с неполным протоколированием. Дополнительные сведения см. в статье Восстановление страниц (SQL Server).

• Поэтапное восстановление

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

• Только восстановление

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

• Восстановление журнала транзакций

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

• Подготовка базы данных доступности для группы доступности AlwaysOn

  Дополнительные сведения см. в статье Подготовка базы данных-получателя для присоединения к группе доступности Always On.

• Подготовка зеркальной базы данных к зеркальному отображению

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

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

  Примечание.

  Оперативное восстановление допускается только в выпуске SQL Server Enterprise.

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

Примечание.

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

Дополнительные сведения см. в статье Восстановление в сети (SQL Server).

Дополнительные сведения о параметрах инструкции RESTORE

Неподдерживаемые ключевые слова инструкции RESTORE

Следующие ключевые слова были прекращены в SQL Server 2008 (10.0.x):

Неподдерживаемое ключевое слово	Заменены на...	Пример заменяющего ключевого слова
LOAD	RESTORE	RESTORE DATABASE
ТРАНЗАКЦИЯ	ЖУРНАЛ	RESTORE LOG
DBO_ONLY	RESTRICTED_USER	RESTORE DATABASE ... WITH RESTRICTED_USER

RESTORE LOG

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

Примечание.

Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, необходимо, чтобы перед восстановлением базы данных была создана резервная копия конца журнала. Восстановление базы данных без создания резервной копии заключительного фрагмента журнала приведет к ошибке, если инструкция RESTORE DATABASE не содержит предложение WITH REPLACE или WITH STOPAT, в котором должно указываться время или транзакция, выполняемая после завершения резервного копирования данных. Дополнительные сведения о резервных копиях заключительного фрагмента журнала см. в статье Резервные копии заключительного фрагмента журнала (SQL Server).

Сравнение параметров RECOVERY и NORECOVERY

Откат контролируется инструкцией RESTORE при помощи параметров [ RECOVERY | NORECOVERY ].

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

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

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

  Для восстановления базы данных необходимо, чтобы весь набор восстанавливаемых данных (набор данных наката) был согласован с базой данных. Если набор данных наката, необходимый для согласования с базой данных, достаточно велик и указан параметр RECOVERY, ядро СУБД формирует ошибку. Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).

Поддержка совместимости

Резервные копии баз данных master, model и msdb, созданные в более ранней версии SQL Server, восстановить невозможно.

Примечание.

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

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

При восстановлении в SQL Server базы данных предыдущей версии она автоматически обновляется. Как правило, база данных сразу становится доступной. Но если база данных SQL Server 2005 (9.x) содержит полнотекстовые индексы, при обновлении будет произведен их импорт, сброс или повторное создание в зависимости от установленного на сервере значения свойства upgrade_option. Если при обновлении выбран режим импорта (upgrade_option = 2) или перестроения (upgrade_option = 0), полнотекстовые индексы во время обновления будут недоступны. В зависимости от объема индексируемых данных процесс импорта может занять несколько часов, а перестроение — в несколько (до десяти) раз больше. Обратите внимание, что если для обновления выбран режим «Импортировать», а полнотекстовый каталог недоступен, то связанные с ним полнотекстовые индексы будут перестроены. Чтобы изменить значение свойства сервера upgrade_option , следует использовать процедуру sp_fulltext_service.

При первом присоединении базы данных к новому экземпляру SQL Server или ее восстановлении копия главного ключа базы данных (зашифрованная главным ключом службы) еще не хранится на сервере. Необходимо расшифровать главный ключ базы данных с помощью инструкции OPEN MASTER KEY. Как только главный ключ базы данных будет расшифрован, появится возможность разрешить автоматическую расшифровку в будущем с помощью инструкции ALTER MASTER KEY REGENERATE, чтобы оставить на сервере копию главного ключа базы данных, зашифрованного с помощью главного ключа службы. После обновления базы данных с переходом от более ранней версии главный ключ базы данных должен быть создан повторно для использования нового алгоритма шифрования AES. См. дополнительные сведения о повторном создании главного ключа базы данных. Время, необходимое для повторного создания главного ключа базы данных с обновлением до алгоритма шифрования AES, зависит от числа объектов, защищаемых главным ключом базы данных. Повторное создание главного ключа базы данных с обновлением до алгоритма шифрования AES необходимо произвести только один раз. Это никак не повлияет на последующие операции повторного создания, выполняемые в соответствии со стратегией смены ключей.

Замечания

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

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

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

Инструкция RESTORE недопустима в явной или неявной транзакции.

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

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

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

Интегрированное ускорение и разгрузка для сжатия и распаковки резервных копий

В версии SQL Server 2022 (16.x) представлен ALGORITHM, который определяет алгоритм сжатия для операции. Дополнительные сведения о сжатии см. в статье Сжатие резервной копии.

Дополнительные сведения приведены в разделе Операция восстановления.

Восстановление из URL-адреса

URL-адрес — это формат, который используется для указания расположения и имени файла для хранилища BLOB-объектов Microsoft Azure или совместимого с S3 хранилища объектов. Хотя хранилище BLOB-объектов Azure является службой, реализация аналогична дисковому и ленточному хранилищу, чтобы обеспечить единообразное и эффективное восстановление для всех устройств.

• Для дополнительных сведений о восстановлении с помощью хранилища BLOB-объектов Microsoft Azure см. Резервное копирование и восстановление SQL Server с помощью хранилища BLOB-объектов Microsoft Azure.

• В SQL Server 2022 (16.x) впервые появилось резервное копирование и восстановление в совместимое с S3 хранилище объектов. Дополнительные сведения о восстановлении из хранилища объектов, совместимого с S3, см. в статье о резервном копировании и восстановлении SQL Server с хранилищем объектов, совместимым с S3. Также просмотрите параметр резервного копирования SQL Server по URL-адресу для хранилища объектов, совместимого с S3.

Совместимость

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

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

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

Восстановление зашифрованной базы данных

Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, должен храниться в течение всего времени, пока есть необходимость в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

Восстановление базы данных с включенным форматом хранения vardecimal

Резервное копирование и восстановление правильно работают с форматом хранения vardecimal. Дополнительные сведения о формате хранения vardecimal см. в статье sp_db_vardecimal_storage_format (Transact-SQL).

Восстановление полнотекстовых данных

Во время полного восстановления полнотекстовые данные восстанавливаются вместе с другими данными базы данных. С помощью обычного синтаксиса RESTORE DATABASE database_name FROM backup_device полнотекстовые файлы восстанавливаются как часть файлов базы данных.

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

Примечание.

Полнотекстовые каталоги, импортированные из SQL Server 2005 (9.x), по-прежнему рассматриваются как файлы базы данных. Для них также применяется процедура SQL Server 2005 (9.x) по резервному копированию полнотекстовых каталогов, но теперь нет необходимости временно останавливать работу на время выполнения резервного копирования. Дополнительные сведения см. в разделе Резервное копирование и восстановление полнотекстовых каталогов.

Восстановление до SQL Server 2022 и функция автоматического удаления

При восстановлении базы данных в SQL Server 2022 (16.x) из предыдущей версии рекомендуется выполнить sp_updatestats в базе данных соответствующие метаданные для функции автоматического удаления статистики. Дополнительные сведения см. в разделе "Автоматическое удаление статистики".

Кластеры больших данных SQL Server

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

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

Метаданные

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

Влияние параметра REPLACE

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

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

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

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

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

  При использовании параметра REPLACE возможна потеря зафиксированных данных, поскольку последние записанные в журнал данные еще не были скопированы в резервную копию.

• Перезапись существующих файлов.

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

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

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

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

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

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

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

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

Ограничения на отмену изменений

Возврат не поддерживается в следующих условиях.

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

Дополнительные сведения см. в разделе Восстановление базы данных до состояния, сохраненного в моментальном снимке.

Безопасность

В операции создания резервной копии могут дополнительно указываться пароли для набора носителей, резервного набора данных или и того и другого. Если для набора носителей или резервного набора данных установлен пароль, то в инструкции RESTORE необходимо указывать правильные пароли. Пароли предотвращают несанкционированные операции восстановления и присоединения резервных наборов данных к носителю при помощи инструментов SQL Server. Однако защищенный паролем носитель может быть переписан инструкцией BACKUP с параметром FORMAT.

Внимание

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

• Для получения сведений о резервном копировании и восстановлении SQL Server в хранилище BLOB-объектов Microsoft Azure см. Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

• В SQL Server 2022 (16.x) впервые появилось резервное копирование и восстановление в совместимое с S3 хранилище объектов. Дополнительные сведения о восстановлении из хранилища объектов, совместимого с S3, см. в статье о резервном копировании и восстановлении SQL Server с хранилищем объектов, совместимым с S3. Также просмотрите параметр резервного копирования SQL Server по URL-адресу для хранилища объектов, совместимого с S3.

Разрешения

Если восстанавливаемая база данных не существуют, для выполнения инструкции RESTORE у пользователя должны быть разрешения CREATE DATABASE. Если база данных существует, нужно восстановить (RESTORE) разрешения по умолчанию для членов предопределенных ролей сервера sysadmin и dbcreator и владельца (dbo) базы данных (для параметра FROM DATABASE_SNAPSHOT база данных всегда существует).

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

Примеры

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

Примеры выполнения инструкции RESTORE.

• А. Восстановление всей базы данных
• B. Восстановление полной и разностной резервных копий базы данных
• В. Восстановление базы данных с использованием синтаксиса RESTART
• D. Восстановление базы данных и перемещение файлов
• Е. Копирование базы данных с помощью инструкций BACKUP и RESTORE
• F. Восстановление состояния на определенный момент времени с помощью STOPAT
• G. Восстановление журнала транзакций до метки
• H. Восстановление с использованием синтаксиса TAPE
• I. Восстановление с использованием синтаксиса FILE и FILEGROUP
• J. Восстановление базы данных из моментального снимка
• K. Восстановление из службы хранилища BLOB-объектов Microsoft Azure
• L. Восстановление из резервной копии моментального снимка

Примечание.

Дополнительные примеры см. в разделах по восстановлению из статьи Обзор процессов восстановления (SQL Server).

А. Восстановление полной базы данных

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

RESTORE DATABASE AdventureWorks2022
  FROM AdventureWorks2022Backups;

Примечание.

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

[Начало примеров]

B. Восстановление полной и разностной резервной копии базы данных

В данном примере производится восстановление полной резервной копии базы данных, за которым следует восстановление из разностной резервной копии с устройства резервного копирования Z:\SQLServerBackups\AdventureWorks2022.bak, на котором содержатся обе резервные копии. Полная резервная копия базы данных — это шестой резервный набор данных на устройстве (FILE = 6), а разностная резервная копия базы данных — девятый резервный набор данных на устройстве (FILE = 9). База данных будет восстановлена после восстановления разностной резервной копии.

RESTORE DATABASE AdventureWorks2022
    FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
    WITH FILE = 6,
      NORECOVERY;
RESTORE DATABASE AdventureWorks2022
    FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2022.bak'
    WITH FILE = 9,
      RECOVERY;

[Начало примеров]

В. Восстановление базы данных с помощью синтаксиса RESTART

В данном примере параметр RESTART используется для перезапуска операции RESTORE, прерванной ошибкой питания на сервере.

-- This database RESTORE halted prematurely due to power failure.
RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups;
-- Here is the RESTORE RESTART operation.
RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups WITH RESTART;

[Начало примеров]

D. Восстановление базы данных и перемещение файлов

В следующем примере производится полное восстановление базы данных и журнала транзакций, после чего восстановленная база данных перемещается в каталог C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data.

RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups
    WITH NORECOVERY,
      MOVE 'AdventureWorks2022_Data' TO
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf',
      MOVE 'AdventureWorks2022_Log'
TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH RECOVERY;

[Начало примеров]

Е. Копирование базы данных с помощью BACKUP и RESTORE

В следующем примере с помощью инструкций BACKUP и RESTORE создается копия базы данных AdventureWorks2022. Инструкция MOVE восстанавливает файлы данных и журнала в указанные места. Количество и имена восстанавливаемых файлов базы данных можно определить с помощью инструкции RESTORE FILELISTONLY. Новая копия базы данных называется TestDB. Дополнительные сведения см. в статье Инструкции RESTORE — FILELISTONLY (Transact-SQL).

BACKUP DATABASE AdventureWorks2022
    TO AdventureWorksBackups ;

RESTORE FILELISTONLY
    FROM AdventureWorksBackups ;

RESTORE DATABASE TestDB
    FROM AdventureWorksBackups
    WITH MOVE 'AdventureWorks2022_Data' TO 'C:\MySQLServer\testdb.mdf',
    MOVE 'AdventureWorks2022_Log' TO 'C:\MySQLServer\testdb.ldf';
GO

[Начало примеров]

F. Восстановление до точки во времени с помощью STOPAT

В следующем примере база данных восстанавливается в состояние на 12:00 AMApril 15, 2020 и демонстрируется операция восстановления, использующая несколько резервных копий журналов. На устройстве резервного копирования AdventureWorksBackups полная резервная копия базы данных, подлежащей восстановлению, — это третий резервный набор данных на устройстве (FILE = 3), резервная копия первого журнала — это четвертый резервный набор (FILE = 4), резервная копия второго журнала — это пятый резервный набор (FILE = 5).

RESTORE DATABASE AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 3, NORECOVERY;

RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 4, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';

RESTORE LOG AdventureWorks2022
    FROM AdventureWorksBackups
    WITH FILE = 5, NORECOVERY, STOPAT = 'Apr 15, 2020 12:00 AM';
RESTORE DATABASE AdventureWorks2022 WITH RECOVERY;

[Начало примеров]

G. Восстановление журнала транзакций на отметку

В следующем примере журнал транзакций восстанавливается до метки в помеченной транзакции с именем ListPriceUpdate.

USE AdventureWorks2022;
GO
BEGIN TRANSACTION ListPriceUpdate
    WITH MARK 'UPDATE Product list prices';
GO

UPDATE Production.Product
    SET ListPrice = ListPrice * 1.10
    WHERE ProductNumber LIKE 'BK-%';
GO

COMMIT TRANSACTION ListPriceUpdate;
GO

-- Time passes. Regular database
-- and log backups are taken.
-- An error occurs in the database.
USE master;
GO

RESTORE DATABASE AdventureWorks2022
FROM AdventureWorksBackups
WITH FILE = 3, NORECOVERY;
GO

RESTORE LOG AdventureWorks2022
  FROM AdventureWorksBackups
    WITH FILE = 4,
    RECOVERY,
    STOPATMARK = 'UPDATE Product list prices';

[Начало примеров]

H. Восстановление с помощью синтаксиса TAPE

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

RESTORE DATABASE AdventureWorks2022
    FROM TAPE = '\\.\tape0';

[Начало примеров]

I. Восстановление с помощью синтаксиса FILE и FILEGROUP

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

Резервная копия базы данных представляет собой девятый резервный набор данных в наборе носителей на логическом устройстве резервного копирования с именем MyDatabaseBackups. Затем производится восстановление трех резервных копий журнала из следующих трех резервных наборов данных (10, 11 и 12) на устройстве MyDatabaseBackups с помощью предложения WITH NORECOVERY. После восстановления NORECOVERYпоследней резервной копии журналов база данных восстанавливается.

Примечание.

Восстановление выполняется как отдельный шаг с целью снижения возможности преждевременного восстановления по журналу, до того как будут восстановлены все резервные копии журналов. Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).

Обратите внимание на два типа параметров RESTORE DATABASE в инструкции FILE. Параметры FILE, предшествующие имени устройства резервного копирования, указывают логические имена файлов базы данных, которые будут восстановлены из резервного набора данных, например FILE = 'MyDatabase_data_1'. Этот резервный набор данных не является первой резервной копией базы данных в наборе носителей, поэтому его позиция указывается параметром FILE в предложении WITH: FILE = 9.

RESTORE DATABASE MyDatabase
    FILE = 'MyDatabase_data_1',
    FILE = 'MyDatabase_data_2',
    FILEGROUP = 'new_customers'
    FROM MyDatabaseBackups
    WITH
      FILE = 9,
      NORECOVERY;
GO
-- Restore the log backups
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 10,
      NORECOVERY;
GO
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 11,
      NORECOVERY;
GO
RESTORE LOG MyDatabase
    FROM MyDatabaseBackups
    WITH FILE = 12,
      NORECOVERY;
GO
--Recover the database
RESTORE DATABASE MyDatabase WITH RECOVERY;
GO

[Начало примеров]

J. Восстановление базы данных из моментального снимка

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

Примечание.

Восстановление до моментального снимка удаляет все полнотекстовые каталоги.

USE master;
RESTORE DATABASE AdventureWorks2022 FROM DATABASE_SNAPSHOT = 'AdventureWorks_dbss1800';
GO

Дополнительные сведения см. в разделе Восстановление базы данных до состояния, сохраненного в моментальном снимке.

[Начало примеров]

K. Восстановление из хранилища BLOB-объектов Microsoft Azure

В следующих трех примерах используется служба хранилища Microsoft Azure. Имя учетной записи хранилища — mystorageaccount. Контейнер для файлов данных называется myfirstcontainer. Контейнер для файлов резервных копий называется mysecondcontainer. Хранимая политика доступа была создана с правами на чтение, запись, удаление и составление списков для каждого контейнера. Учетные данные SQL Server были созданы с использованием подписанных URL-адресов, которые связаны с хранимыми политиками доступа. Для получения сведений о резервном копировании и восстановлении SQL Server в хранилище BLOB-объектов Microsoft Azure см. Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

K1. Восстановление полной резервной копии базы данных из службы хранилища Microsoft Azure
Полная резервная копия базы данных в mysecondcontainer из Sales будет восстановлена в myfirstcontainer. Sales в настоящее время не существует на сервере.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

K2. Восстановление полной резервной копии базы данных из службы хранилища Microsoft Azure в локальное хранилище Полная резервная копия базы данных в mysecondcontainer из Sales будет восстановлена в локальное хранилище. Sales в настоящее время не существует на сервере.

RESTORE DATABASE Sales
  FROM URL = 'https://mystorageaccount.blob.core.windows.net/mysecondcontainer/Sales.bak'
  WITH MOVE 'Sales_Data1' to 'H:\DATA\Sales_Data1.mdf',
  MOVE 'Sales_log' to 'O:\LOG\Sales_log.ldf',
  STATS = 10;

K3. Восстановление полной резервной копии базы данных из локального хранилища в службу хранилища Microsoft Azure

RESTORE DATABASE Sales
  FROM DISK = 'E:\BAK\Sales.bak'
  WITH MOVE 'Sales_Data1' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_Data1.mdf',
  MOVE 'Sales_log' to 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_log.ldf',
  STATS = 10;

L. Восстановление из резервного копирования моментальных снимков

Впервые представлено в SQL Server 2022 (16.x). Дополнительные сведения см. в статье "Создание резервного копирования моментальных снимков Transact-SQL".

L1. Восстановление полной резервной копии

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY;

L2. Восстановление резервной копии и применение журнала транзакций

RESTORE DATABASE Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
  WITH METADATA_ONLY,
  NORECOVERY;

RESTORE LOG Sales
  FROM DISK = 'D:\MSSQL\Backup\SalesLog.trn'
  WITH RECOVERY;

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

RESTORE DATABASE Sales
FROM DISK = 'D:\MSSQL\Backup\SalesSnapshotFull.bkm'
WITH METADATA_ONLY,
    MOVE Sales_Data TO 'D:\MSSQL\Sales.mdf',
    MOVE Sales_Log TO 'D:\MSSQL\Sales_log.ldf';

[Начало примеров]

Следующие шаги

• Обзор процессов восстановления (SQL Server)
• Резервное копирование и восстановление баз данных SQL Server
• Резервное копирование и восстановление системных баз данных (SQL Server)
• Restore a Database Backup Using SSMS
• Создание резервных копий и восстановление полнотекстовых каталогов и индексов
• Создание резервных копий реплицируемых баз данных и восстановление из них
• BACKUP
• Наборы носителей, семейства носителей и резервные наборы данных
• RESTORE REWINDONLY
• RESTORE VERIFYONLY
• RESTORE FILELISTONLY (Transact-SQL)
• RESTORE HEADERONLY (Transact-SQL)
• Журнал и сведения о заголовке резервной копии (SQL Server)