BACKUP (Transact-SQL)

2025-05-19

Создание резервной копии базы данных SQL.

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

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

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

* SQL Server *

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

Платформа аналитики
Система (PDW)

SQL Server

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

Синтаксис

--Back up a whole database
BACKUP DATABASE { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up specific files or filegroups
BACKUP DATABASE { database_name | @database_name_var }
 <file_or_filegroup> [ ,...n ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Create a partial backup
BACKUP DATABASE { database_name | @database_name_var }
 READ_WRITE_FILEGROUPS [ , <read_only_filegroup> [ ,...n ] ]
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { DIFFERENTIAL | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up the transaction log (full and bulk-logged recovery models)
BACKUP LOG
  { database_name | @database_name_var }
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { <general_WITH_options> | <log_specific_options> } [ ,...n ] ]
[;]

--Back up all the databases on an instance of SQL Server (a server)

ALTER SERVER CONFIGURATION
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
[;]

BACKUP SERVER
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

--Back up a group of databases
ALTER DATABASE <database>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON

ALTER DATABASE <...>
SET SUSPEND_FOR_SNAPSHOT_BACKUP ON
...

BACKUP GROUP {<database> [,... ]}
  TO <backup_device> [ ,...n ]
  [ <MIRROR TO clause> ] [ next-mirror-to ]
  [ WITH { METADATA_ONLY
           | <general_WITH_options> [ ,...n ] } ]
[;]

<backup_device>::=
 {
  { logical_device_name | @logical_device_name_var }
 | {   DISK
     | TAPE
     | URL } =
     { 'physical_device_name' | @physical_device_name_var | 'NUL' }
 }

<MIRROR TO clause>::=
 MIRROR TO <backup_device> [ ,...n ]

<file_or_filegroup>::=
 {
   FILE = { logical_file_name | @logical_file_name_var }
 | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
 }

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

<general_WITH_options> [ ,...n ]::=
--Backup Set Options
   COPY_ONLY
 | [ COMPRESSION [ ( ALGORITHM = { MS_XPRESS | ZSTD | accelerator_algorithm } [, LEVEL = { LOW | MEDIUM | HIGH } ] ) ] | NO_COMPRESSION ]
 | DESCRIPTION = { 'text' | @text_variable }
 | NAME = { backup_set_name | @backup_set_name_var }
 | CREDENTIAL
 | ENCRYPTION
 | FILE_SNAPSHOT
 | { EXPIREDATE = { 'date' | @date_var }
        | RETAINDAYS = { days | @days_var } }
 | { METADATA_ONLY | SNAPSHOT }

--Media Set Options
   { NOINIT | INIT }
 | { NOSKIP | SKIP }
 | { NOFORMAT | FORMAT }
 | MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

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

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

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

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

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

<log_specific_options> [ ,...n ]::=
--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

Аргументы

База данных

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

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

Примечание.

В базе данных можно выполнить master только полную резервную копию базы данных.

ЖУРНАЛ

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

Резервную копию журналов можно восстановить на определенный момент времени или к определенной транзакции, указав предложение WITH STOPAT, STOPATMARK или STOPBEFOREMARK в инструкции RESTORE LOG.

Примечание.

После обычной процедуры создания резервной копии журналов некоторые записи в журнале транзакций становятся неактивными, если не были указаны параметры WITH NO_TRUNCATE или COPY_ONLY. Журнал усекается после того, как все записи внутри одного или нескольких виртуальных файлов журнала становятся неактивными. Если журнал не усечен после обычных резервных копий журналов, то может отложить усечение журнала. Дополнительные сведения см. в разделе Факторы, которые могут вызвать задержку усечения журнала.

GROUP (<база данных>,... n)

Впервые представлено в SQL Server 2022 (16.x).

Резервное копирование группы баз данных. Использует резервное копирование моментальных снимков. Требуется WITH METADATA_ONLY. См. статью "Создание резервного копирования моментальных снимков Transact-SQL".

СЕРВЕР

Впервые представлено в SQL Server 2022 (16.x).

Резервное копирование всех баз данных на экземпляре SQL Server. Использует резервное копирование моментальных снимков. Требуется WITH METADATA_ONLY. См. статью "Создание резервного копирования моментальных снимков Transact-SQL".

METADATA_ONLY

Впервые представлено в SQL Server 2022 (16.x).

Требуется для резервного копирования моментальных снимков. BACKUP SERVERили BACKUP GROUP... см. статью "Создание резервного копирования моментальных снимков Transact-SQL".

METADATA_ONLY синонимом МОМЕНТАЛЬНОГО СНИМКА. Интерфейс виртуального устройства (VDI) использует МОМЕНТАЛЬНЫЙ СНИМОК. Дополнительные сведения о VDI см . в справочнике по интерфейсу виртуального устройства (VDI).

{ database_name | @database_name_var }

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

Примечание.

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

< > file_or_filegroup [ ,...n ]

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

FILE = { logical_file_name | @logical_file_name_var }

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

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

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

Примечание.

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

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

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

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

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

READ_WRITE_FILEGROUPS

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

Внимание

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

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Логическое имя файловой группы, доступной только для чтения, или переменная со значением, равным логическому имени доступной только для чтения файловой группы, которую следует включить в частичную резервную копию. Дополнительные сведения см. в разделе <file_or_filegroup> выше.

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

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

TO <backup_device [ ,...>n ]

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

<backup_device>
Указывает логическое или физическое устройство резервного копирования, используемое для создания резервной копии.

{ logical_device_name | @logical_device_name_var }

Применяется к: SQL Server
Логическое имя устройства резервного копирования, на котором создается резервная копия базы данных. Логическое имя должно соответствовать правилам для идентификаторов. Если аргумент задается в виде переменной (@logical_device_name_var), имя устройства резервного копирования можно указать как строковую константу (логическое имя устройства резервного копирования @logical_device_name_var=) или как переменную любого строкового типа данных, кроме ntext или text.

{ ДИСК | ЛЕНТА | URL} = { "physical_device_name" | @physical_device_name_var | 'NUL' }

Область применения: SQL Server (URL-адрес, начиная с SQL Server 2012 (11.x) с пакетом обновления 1 (SP1) CU2)

Определяет файл диска, ленточное устройство или URL-адрес.

Формат URL-адреса используется, чтобы была возможность создавать резервные копии для Хранилища BLOB-объектов Microsoft Azure или хранилища объектов, совместимого с S3. Дополнительные сведения и примеры см. в следующих примерах:

Резервное копирование и восстановление SQL Server с помощью хранилища BLOB-объектов Microsoft Azure и руководства. Резервное копирование и восстановление SQL Server в хранилище BLOB-объектов Microsoft Azure.
Резервное копирование и восстановление в хранилище, совместимое с S3, было введено в SQL Server 2022 (16.x), см . статью sql Server backup and restore with S3-совместимым хранилищем объектов. Также просмотрите параметр резервного копирования SQL Server по URL-адресу для хранилища объектов, совместимого с S3.

Вы можете создать резервную копию в хранилище BLOB-объектов Microsoft Azure с помощью управляемого удостоверения, начиная с следующего:

Предварительная версия SQL Server 2025 (17.x): резервное копирование на URL-адрес с помощью управляемого удостоверения с помощью предварительной версии SQL Server 2025
SQL Server 2022 (16.x) CU 17 для SQL Server на виртуальных машинах Azure: резервное копирование на URL-адрес с помощью управляемого удостоверения с SQL Server на виртуальных машинах Azure

Примечание.

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

Внимание

Начиная с SQL Server 2012 (11.x) с пакетом обновления 1 (SP1) до SQL Server 2014 (12.x), вы можете выполнять резервное копирование только на одно устройство при резервном копировании по URL-адресу для хранилища BLOB-объектов Azure. Чтобы создать резервную копию на нескольких устройствах при резервном копировании по URL-адресу, необходимо использовать SQL Server 2016 (13.x) и более поздних версий и использовать маркеры подписанного URL-адреса (SAS). Примеры создания подписанного URL-адреса см. в статье sql Server Backup to URL-адрес и упрощение создания учетных данных SQL с помощью маркеров ПОДПИСАННОГО URL-адреса (SAS) в службе хранилища Azure с помощью PowerShell.

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

Примечание.

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

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

Примечание.

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

n
Заполнитель, указывающий, что в списке с разделителями-запятыми может быть указано до 64 устройств резервного копирования.

ЗЕРКАЛЬНОЕ ОТОБРАЖЕНИЕ BACKUP_DEVICE <> [ ,...n ]

Задает набор из 1–3 дополнительных устройств резервного копирования, являющихся зеркальным отображением устройств, указанных в предложении TO. В предложении MIRROR TO должен быть указан тот же тип и то же количество устройств резервного копирования, что и в предложении TO. Максимальное число предложений MIRROR TO — три.

Этот параметр доступен только в выпуске Enterprise SQL Server.

Примечание.

Когда используется MIRROR TO = DISK, BACKUP автоматически определяет подходящий размер блока для дисковых устройств в зависимости от размера сектора на диске. Если диск MIRROR TO отформатирован с иным размером сектора, чем у диска — основного устройства резервного копирования, команда BACKUP не сработает. Для зеркального отображения резервных копий на устройствах с разными размерами сектора необходимо указать параметр BLOCKSIZE и установить максимальный размер сектора среди всех целевых устройств. Дополнительные сведения о размере блока см. в разделе "BLOCKIZE" далее в этой статье.

<backup_device>
См. подраздел "<устройство_резервного_копирования>" выше в этом разделе.

n
Заполнитель, указывающий, что в списке с разделителями-запятыми может быть указано до 64 устройств резервного копирования. Количество устройств в предложении MIRROR TO должно быть равно количеству устройств в предложении TO.

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

[ next-mirror-to ]
Заполнитель, показывающий, что в одной инструкции BACKUP в дополнение к одному предложению TO может содержаться до трех предложений MIRROR TO.

Параметры инструкции WITH

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

УЧЁТНЫЕ ДАННЫЕ

Область применения: SQL Server (начиная с SQL Server 2012 (11.x) с пакетом обновления 1 (SP1) CU2).

Используется только при создании резервной копии для Хранилище BLOB-объектов Azure.

Снимок файла

Область применения: SQL Server (начиная с SQL Server 2016 (13.x)).

Служит для создания снимка экрана Azure файлов базы данных, когда все файлы базы данных SQL Server остаются в памяти с помощью Хранилища BLOB-объектов Azure. Дополнительные сведения см. в разделе Файлы данных SQL Server в Microsoft Azure. Резервное копирование моментальных снимков SQL Server принимает моментальные снимки файлов базы данных (файлы данных и журналов) в согласованном состоянии. Согласованный набор моментальных снимков Azure составляет резервную копию, они копируются в файл резервной копии. Единственное различие между и BACKUP DATABASE TO URL WITH FILE_SNAPSHOT заключается в BACKUP LOG TO URL WITH FILE_SNAPSHOT том, что последний также усечен журнал транзакций, в то время как бывший не. При резервном копировании моментальных снимков SQL Server после первоначальной полной резервной копии, необходимой SQL Server для установления цепочки резервных копий резервных копий журнала транзакций, требуется только одна резервная копия журнала транзакций для восстановления базы данных до точки во времени резервного копирования журнала транзакций. Кроме того, для восстановления базы данных до точки времени между двумя операциями резервного копирования журнала транзакций требуется только две резервные копии журнала транзакций.

DIFFERENTIAL (разностная)

Используется только с инструкцией BACKUP DATABASE. Указывает, что резервная копия базы данных или файлов должна состоять только из тех частей базы данных или файлов, которые были изменены с момента создания последней полной резервной копии. Файл разностной резервной копии обычно занимает меньше места, чем полная резервная копия. Используйте этот параметр, чтобы все отдельные резервные копии журналов выполнялись с момента применения последней полной резервной копии.

Примечание.

По умолчанию BACKUP DATABASE создает полную резервную копию.

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

ШИФРОВАНИЕ

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

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

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

SERVER CERTIFICATE = Encryptor_Name
SERVER ASYMMETRIC KEY = Encryptor_Name

SERVER CERTIFICATE и SERVER ASYMMETRIC KEY — это сертификат и асимметричный ключ, созданные в базе данных master. Дополнительные сведения см. в разделах CREATE CERTIFICATE и CREATE ASYMMETRIC KEY соответственно.

Предупреждение

При использовании шифрования вместе с аргументом FILE_SNAPSHOT файл метаданных шифруется с использованием заданного алгоритма шифрования. Система проверяет, что для базы данных было выполнено прозрачное шифрование данных (TDE). Дополнительное шифрование самих данных не выполняется. Резервное копирование завершается ошибкой, если база данных не была зашифрована или если шифрование не было завершено до выдачи инструкции резервного копирования.

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

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

Примечание.

Чтобы указать резервный набор для операции восстановления, воспользуйтесь параметром FILE = <backup_set_file_number>. Дополнительные сведения о том, как задать резервный набор данных, см. в разделе "Указание резервного набора данных" статьи об аргументах RESTORE.

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

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

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

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

Внимание

Если DIFFERENTIAL и COPY_ONLY используются вместе, COPY_ONLY игнорируется и создается разностная резервная копия.
При использовании с BACKUP LOGCOPY_ONLY параметром создается резервная копия журнала только для копирования, которая не усечена журнала транзакций. Резервная копия журнала только для копирования не влияет на цепочку журналов, а другие резервные копии журналов ведут себя так, как если бы резервная копия только для копирования не существует.

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

[ СЖАТИЕ [ ( АЛГОРИТМ = { MS_XPRESS | ZSTD | accelerator_algorithm } [, LEVEL = { LOW | MEDIUM | HIGH } ] ] | NO_COMPRESSION ]

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

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

Сведения об использовании сжатия резервных копий в базах данных с включенным прозрачным шифрованием данных (TDE) см. в разделе Замечания.

Алгоритм сжатия ZSTD доступен начиная с предварительной версии SQL Server 2025 (17.x).

СЖАТИЕ

Явное включение сжатия резервных копий.

NO_COMPRESSION

Явное отключение сжатия резервной копии.

УРОВЕНЬ
Применяется к SQL Server 2022 (16.x) и более поздним версиям.

Это необязательный параметр, указывающий уровень сжатия. Влияет на предварительную ALGORITHM = MS_EXPRESSверсию ALGORITHM = ZSTDSQL Server 2025 (17.x).

Допустимые значения:

LOW (по умолчанию)
MEDIUM
HIGH

АЛГОРИТМ
Применяется к SQL Server 2022 (16.x) и более поздним версиям.

ZSTD и MS_EXPRESS — это алгоритмы уровня программного обеспечения. QAT_DEFLATE — это аппаратный алгоритм, требующий технологии Intel® QuickAssist (QAT) для SQL Server. Значение по умолчанию — MS_XPRESS.

Чтобы использовать алгоритм сжатия ZSTD, представленный в предварительной версии SQL Server 2025 (17.x):

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = MEDIUM)

Если вы настроили интегрированное ускорение и разгрузку, можно использовать ускоритель, предоставляемый решением. Например, если вы настроили технологию Intel® QuickAssist (QAT) для SQL Server, следующий пример завершает резервное копирование с помощью решения акселератора с библиотекой QATzip с использованием QZ_DEFLATE уровня сжатия 1.

BACKUP DATABASE <database_name> TO DISK WITH COMPRESSION (ALGORITHM = QAT_DEFLATE)

Примеры поведения:

ИНСТРУКЦИЯ BACKUP	РЕЗУЛЬТАТ
`BACKUP DATABASE <database_name> TO {DISK\\|TAPE\\|URL} WITH NO_COMPRESSION`	Резервное копирование без сжатия
`BACKUP DATABASE <database_name> TO {DISK\\|TAPE\\|URL} WITH COMPRESSION`	Резервное копирование с сжатием с помощью алгоритма, указанного параметром `backup compression algorithm` сервера (по умолчанию MS_XPRESS)
`BACKUP DATABASE <database_name> TO {DISK\\|TAPE\\|URL} WITH COMPRESSION (ALGORITHM = MS_XPRESS)`	Резервное копирование с сжатием с помощью алгоритма MS_XPRESS
`BACKUP DATABASE <database_name> TO {DISK\\|TAPE\\|URL} WITH COMPRESSION (ALGORITHM = ZSTD)`	Резервное копирование с помощью алгоритма ZSTD.
`BACKUP DATABASE <database_name> TO {DISK\\|TAPE\\|URL} WITH COMPRESSION (ALGORITHM = ZSTD, LEVEL = HIGH)`	Резервное копирование с сжатием с помощью алгоритма ZSTD с высоким уровнем сжатия.

DESCRIPTION = { "text" | @text_variable }

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

NAME = { backup_set_name | @backup_set_var }

Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если имя не указано, пусто.

{ EXPIREDATE ='date' | RETAINDAYS = days }

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

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

Внимание

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

= СРОК ДЕЙСТВИЯ { "date" | @date_var }
Указывает дату, по наступлении которой резервный набор данных считается устаревшим и может быть перезаписан. Если параметр задается с помощью переменной (@date_var), то содержащаяся в ней дата должна соответствовать настроенному системному формату для типа datetime и быть указана одним из следующих способов:

Строковая константа (@date_var= дата)
Переменная типа символьной строки (за исключением типов данных ntext и text)
smalldatetime
Переменная datetime

Например:

'Dec 31, 2020 11:59 PM'
'1/1/2021'

Сведения о том, как задать значения datetime, см. в разделе Типы даты и времени.

Примечание.

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

RETAINDAYS = { дней | @days_var }
Указывает количество дней, которое должно пройти, прежде чем этот набор носителей резервных копий может быть перезаписан. Если параметр задается с помощью переменной (@days_var), то он должен быть целым числом.

{ METADATA_ONLY | SNAPSHOT }

Область применения: SQL Server 2022 (16.x)

METADATA_ONLY и SNAPSHOT являются синонимами.

Параметры набора носителей

Эти параметры влияют на весь набор носителей.

{ NOINIT | INIT }

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

Примечание.

Сведения о взаимодействии между { NOINIT | INIT } и { NOSKIP | SKIP }, см. в разделе "Примечания " далее в этой статье.

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

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

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

Срок действия резервного набора данных еще не истек. Дополнительные сведения см. в разделах EXPIREDATE и RETAINDAYS.
Имя резервного набора данных, указанное в инструкции BACKUP, если указано, не соответствует имени на носителе резервного копирования. Дополнительные сведения см. в описании параметра NAME, приведенном выше в этом разделе.

Для переопределения этих проверок воспользуйтесь параметром SKIP.

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

{ NOSKIP | SKIP }

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

Примечание.

Сведения о взаимодействии между { NOINIT | INIT } и { NOSKIP | SKIP }, см. раздел "Примечания", далее в этой статье.

NOSKIP
Указывает инструкции BACKUP, что следует провести проверку сроков хранения всех резервных наборов данных на носителе перед тем, как разрешить их перезапись. Это поведение принимается по умолчанию.

СКИП
Отключает проверку сроков действия и имен резервных наборов данных, которая обычно проводится инструкцией BACKUP для предотвращения перезаписи. Дополнительные сведения о взаимодействии между параметрами { INIT | NOINIT } и { NOSKIP | SKIP } см. в разделе "Замечания" далее в этой статье. Чтобы узнать даты сроков хранения резервных наборов данных, запросите столбец expiration_date в таблице журнала backupset.

{ NOFORMAT | FORMAT }

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

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

ФОРМАТ
Указывает, что должен быть создан новый набор носителей. При использовании предложения FORMAT операция резервного копирования будет записывать новый заголовок носителя на всех томах носителей, используемых для операции резервного копирования. Существующее содержимое тома становится недействительным, поскольку все существующие заголовки носителей и резервные наборы данных при этом перезаписываются.

Внимание

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

Указание ФОРМАТА подразумеваетSKIPSKIP, что не требуется явно указывать.

MEDIADESCRIPTION = { текст | @text_variable }

Указывает произвольное текстовое описание набора носителей, длина которого не должна превышать 255 символов.

MEDIANAME = { media_name | @media_name_variable }

Указывает имя носителя для всего набора носителей резервных копий. Имя носителя должно быть не более 128 символов. Если MEDIANAME задано, оно должно соответствовать ранее указанному имени носителя, уже существующему на томах резервного копирования. Если он не указан или указан параметр SKIP, проверка имени носителя отсутствует.

BLOCKSIZE = { блокировать | @blocksize_variable }

Указывает размер физического блока в байтах. Поддерживаются размеры 512, 1024, 2048, 4096, 8192, 16 384, 32 768 и 65 536 байт (64 КБ). Значение по умолчанию равно 65 536 для ленточных устройств и 512 для других устройств. Обычно в этом параметре нет необходимости, так как инструкция BACKUP автоматически выбирает размер блока, соответствующий устройству. Явная установка размера блока переопределяет автоматический выбор размера блока.

Если вы собираетесь скопировать и восстановить резервную копию из КОМПАКТ-ДИСКА, укажите BLOCKSIZE=2048.

Примечание.

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

Параметры передачи данных

BUFFERCOUNT = { buffercount | @buffercount_variable }

Указывает общее число буферов ввода-вывода, которые будут использоваться для операции резервного копирования. Можно указать любое целое положительное значение, однако большое число буферов может вызвать ошибку нехватки памяти из-за чрезмерного виртуального адресного пространства в процессе Sqlservr.exe.

Общий объем пространства, используемого буферами, определяется по следующей формуле: BUFFERCOUNT * MAXTRANSFERSIZE.

Примечание.

Важные сведения об использовании параметра BUFFERCOUNT см. в блоге Неправильный параметр передачи данных BufferCount может привести к OOM.

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Указывает наибольший объем пакета данных в байтах для обмена данными между SQL Server и носителем резервных копий. Возможные значения — это несколько 65536 байт (64 КБ) размером до 4 194 304 байтов (4 МБ). В определенном случае резервного копирования в хранилище объектов, совместимого с S3, MAXTRANSFERSIZE составляет 10 МБ. Дополнительные сведения см. в примечаниях.

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

Для баз данных с включенным прозрачным шифрованием данных (TDE) и одним файлом данных MAXTRANSFERSIZE по умолчанию — 65 536 (64 КБ). Для зашифрованных баз данных, отличных от TDE, значение по умолчанию MAXTRANSFERSIZE 1048576 (1 МБ) при использовании резервного копирования на ДИСК и 65536 (64 КБ) при использовании VDI или TAPE. Дополнительные сведения об использовании сжатия резервных копий в работе с базами данных с включенным шифрованием TDE см. в разделе Замечания.

Параметры управления ошибками

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

{ NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА }

Определяет, разрешены ли контрольные суммы.

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

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

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

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

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

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

STOP_ON_ERROR
Указывает BACKUP завершить ошибку, если контрольная сумма страницы не проверяется. Это поведение принимается по умолчанию.

CONTINUE_AFTER_ERROR
Определяет, что инструкция BACKUP должна продолжить выполнение, несмотря на возникновение таких ошибок, как неверные контрольные суммы или разрывы страницы.

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

Параметры совместимости

ПЕРЕЗАПУСК

Начиная с SQL Server 2008 (10.0.x), не действует. Он оставлен в этой версии для совместимости с предыдущими версиями SQL Server.

Параметры мониторинга

STATS [ = процент ]

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

Параметр STATS сообщает о готовности в процентах по отношению к порогу сообщения о следующем интервале. Показатель готовности в процентах имеет неточное значение; например при значении STATS=10, если процент готовности равен 40, то параметр может отображать 43 процента. Для больших наборов резервных копий это не проблема, так как процент завершения выполняется очень медленно между завершенных вызовов ввода-вывода.

Параметры ленты

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

{ REWIND | NOREWIND }

ПЕРЕМАТЫВАТЬ
Указывает, что SQL Server выпускает и перемотывает ленту. REWIND — значение по умолчанию.

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

Параметр NOREWIND включает в себя параметр NOUNLOAD, поэтому эти параметры несовместимы в одной инструкции BACKUP.

Примечание.

Если используется NOREWIND, экземпляр SQL Server сохраняет владение ленточным диском до тех пор, пока инструкция BACKUP или RESTORE, запущенная в том же процессе, использует REWINDUNLOAD либо параметр, либо экземпляр сервера завершает работу. Поскольку лента остается открытой, другие процессы не могут получить доступа к ленте. Дополнительные сведения об отображении списка открытых лент и закрытии открытой ленты см. в статье об устройствах резервного копирования.

{ ВЫГРУЗ | NOUNLOAD }

Примечание.

UNLOAD и NOUNLOAD являются параметрами сеанса, которые сохраняются в течение срока действия сеанса или пока он не будет сброшен, указав альтернативу.

РАЗГРУЖАТЬ
Указывает, что лента автоматически перематывается и выгружается по завершении операции резервного копирования. Параметр UNLOAD применяется в начале сеанса по умолчанию.

NOUNLOAD
Указывает, что после завершения операции BACKUP лента остается в ленточном накопителе.

Примечание.

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

Параметры, относящиеся к журналам

Эти параметры применяются только с инструкцией BACKUP LOG.

Примечание.

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

{ NORECOVERY | STANDBY = undo_file_name }

NORECOVERY
Создает резервную копию остатка журнала и оставляет базу данных в состоянии RESTORING. Параметр NORECOVERY полезен при возникновении ошибки в базе данных-получателе или при сохранении остатка журнала после операции RESTORE.

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

РЕЗЕРВНАЯ =STANDBY_FILE_NAME
Создает резервную копию остатка журнала и оставляет базу данных в режиме только для чтения и состоянии STANDBY. Предложение STANDBY записывает резервные данные (выполняя откат, но с параметром дальнейшего восстановления). Применения параметра STANDBY эквивалентно параметру BACKUP LOG WITH NORECOVERY, за которым следует RESTORE WITH STANDBY.

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

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

NO_TRUNCATE

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

Параметр NO_TRUNCATE процедуры BACKUP LOG эквивалентен одновременному указанию COPY_ONLY и CONTINUE_AFTER_ERROR.

Без параметра NO_TRUNCATE база данных должна находиться в режиме ONLINE. Если база данных находится в состоянии SUSPENDED, то будет возможно создать резервную копию, указав параметр NO_TRUNCATE. Но если база данных находится в автономном или аварийном состоянии, резервное копирование даже не NO_TRUNCATEдопускается. Дополнительные сведения о состояниях базы данных см. в разделе Состояния базы данных.

Работа с резервными копиями SQL Server

В этом разделе вводятся следующие основные понятия, связанные с резервным копированием:

Типы резервного копирования Усечение журнала транзакций Форматирование носителей резервных копий Работа с устройствами резервного копирования и наборами носителей Восстановление резервных копий SQL Server

Примечание.

Общие сведения о резервном копировании в SQL Server см. в разделе "Обзор резервного копирования".

Типы резервного копирования

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

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

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

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

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

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

Примечание.

До создания первой резервной копии журнала необходимо создать полную резервную копию базы данных.
Резервная копия только для копирования — это полная резервная копия или резервная копия журналов, созданная с особой целью. Такая копия не зависит от нормальной последовательности создания обычных резервных копий. Для создания резервной копии только для копирования используется параметр COPY_ONLY инструкции BACKUP. Дополнительные сведения см. в статье о резервных копиях только для копирования.

Усечение журнала транзакций

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

Примечание.

Параметры BACKUP LOG WITH NO_LOG и WITH TRUNCATE_ONLY больше не поддерживаются. Если вы используете полное или массовое восстановление модели восстановления и необходимо удалить цепочку резервного копирования журналов из базы данных, переключитесь на простую модель восстановления. Дополнительные сведения см. в статье о просмотре и изменении модели восстановления базы данных.

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

Носитель резервной копии форматируется инструкцией BACKUP только при выполнении любого из следующих условий:

Указан параметр FORMAT.
носитель пуст;
операция производит запись дополнительной ленты.

Работа с устройствами резервного копирования и наборами носителей

Устройства резервного копирования в чередующемся наборе носителей (чередующийся набор)

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

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

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1.bak',
DISK = 'Y:\SQLServerBackups\AdventureWorks2.bak',
DISK = 'Z:\SQLServerBackups\AdventureWorks3.bak'
WITH FORMAT,
  MEDIANAME = 'AdventureWorksStripedSet0',
  MEDIADESCRIPTION = 'Striped media set for AdventureWorks2022 database';
GO

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

Если при записи заголовка носителя не был указан ни параметр MEDIANAME, ни параметр MEDIADESCRIPTION, то поле заголовка носителя, соответствующее отсутствующему параметру, будет пустым.

Работа с зеркальным набором носителей

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

Для создания резервной копии на зеркальном наборе носителей должны присутствовать все зеркала. Чтобы создать резервную копию на зеркальном наборе носителей, используйте предложение TO для описания первой зеркальной копии и предложения MIRROR TO для описания каждой дополнительной зеркальной копии.

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

BACKUP DATABASE AdventureWorks2022
TO DISK = 'X:\SQLServerBackups\AdventureWorks1a.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2a.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks1b.bak',
  DISK = 'Y:\SQLServerBackups\AdventureWorks2b.bak',
  DISK = 'Z:\SQLServerBackups\AdventureWorks3b.bak';
GO

Внимание

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

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

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

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

Зеркальное отображение	Семейство носителей 1	Семейство носителей 2	Семейство носителей 3
0	`Z:\AdventureWorks1a.bak`	`Z:\AdventureWorks2a.bak`	`Z:\AdventureWorks3a.bak`
1	`Z:\AdventureWorks1b.bak`	`Z:\AdventureWorks2b.bak`	`Z:\AdventureWorks3b.bak`

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

Дополнительные сведения о зеркальных наборах носителей см. в разделе "Зеркальные резервные наборы носителей". Дополнительные сведения о наборах носителей и семействах носителей в целом см. в разделе "Наборы носителей", семейства носителей и резервные наборы резервных копий.

Восстановление резервных копий SQL Server

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

Дополнительные рекомендации по параметрам РЕЗЕРВНОГО КОПИРОВАНИЯ

Взаимодействие SKIP, NOSKIP, INIT и NOINIT

Эта таблица описывает взаимодействие между параметрами { NOINIT | INIT } и { NOSKIP | SKIP }.

Примечание.

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

Параметр skip	NOINIT	INIT
NOSKIP	Если в томе содержится правильный заголовок носителя, то выполняется проверка совпадения имени носителя с указанным параметром `MEDIANAME` (если он задан). Если установлено совпадение, резервный набор данных дозаписывается с сохранением всех существующих резервных наборов данных. Если том не содержит допустимый заголовок носителя, возникает ошибка.	Если том содержит заголовок носителя, проводятся следующие проверки. Если указан параметр `MEDIANAME`, то проверяется, совпадает ли заданное имя носителя с именем носителя заголовка носителя.¹ Проверяется, есть ли на носителе резервные наборы данных с неистекшим сроком действия. Если есть, то процесс резервного копирования прекращается. Если все эти проверки пройдены, то происходит перезапись всех резервных наборов данных на носителе. Сохраняется только заголовок носителя. Если том не содержит допустимый заголовок носителя, создает его с указанным `MEDIANAME` и `MEDIADESCRIPTION`, если таковой имеется.
СКИП	Если том содержит верный заголовок носителя, то резервный набор данных дозаписывается с сохранением всех существующих резервных наборов данных.	Если в томе содержится правильный заголовок носителя², то выполняется перезапись всех резервных наборов данных на носителе, при этом сохраняется только заголовок носителя. Если носитель пуст, то создается заголовок носителя, исходя из заданных параметров `MEDIANAME` и `MEDIADESCRIPTION` (если они указаны).

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

² В допустимость входит номер версии MTF и другие сведения заголовка. Если указанная версия не поддерживается или имеет непредвиденное значение, то возникает ошибка.

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

Внимание

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

BACKUP RESTART поддерживает возможность обеспечения обратной совместимости с более ранними версиями SQL Server. Но параметр RESTART не имеет влияния.

Замечания

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

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

Вы не можете создать резервную копию базы данных в следующих состояниях:

Восстановление из копии
Режим ожидания
Только чтение

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

Начиная с SQL Server 2016 (13.x), установка MAXTRANSFERSIZEразмером более 65536 (64 КБ) обеспечивает оптимизированный алгоритм сжатия для зашифрованных баз данных прозрачное шифрование данных (TDE), которые сначала расшифровывают страницу, сжимает его, а затем шифрует его снова. Если MAXTRANSFERSIZE не указано или MAXTRANSFERSIZE = 65536 используется (64 КБ), сжатие резервных копий с зашифрованными базами данных TDE напрямую сжимает зашифрованные страницы и может не обеспечить хорошие коэффициенты сжатия. Дополнительные сведения см. в разделе Сжатие резервных копий для баз данных с включенным шифрованием TDE.

Начиная с SQL Server 2019 (15.x) CU5, параметр MAXTRANSFERSIZE больше не требуется для включения этого оптимизированного алгоритма сжатия с TDE. Если указана команда резервного копирования WITH COMPRESSION или конфигурация сервера для сжатия резервных копий по умолчанию имеет значение 1, MAXTRANSFERSIZE автоматически увеличится до 128 КБ для включения оптимизированного алгоритма. Если MAXTRANSFERSIZE задано в команде резервного копирования со значением > 64 K, то указанное значение учитывается. Другими словами, SQL Server никогда не уменьшает значение автоматически, только увеличивает его. Если необходимо создать резервную копию зашифрованной базы данных TDE с MAXTRANSFERSIZE = 65536, необходимо указать WITH NO_COMPRESSION или убедиться, что в конфигурации сервера по умолчанию для сжатия резервных копий сервера задано значение 0.

Примечание.

Иногда значение MAXTRANSFERSIZE по умолчанию больше 64 КБ:

Если в базе данных создано множество файлов данных, используется MAXTRANSFERSIZE> 64 КБ.
При резервном копировании на URL-адрес в Хранилище BLOB-объектов Azure значение по умолчанию — MAXTRANSFERSIZE = 1048576 (1 МБ).
При выполнении резервного копирования для URL-адреса хранилища объектов, совместимого с S3, по умолчанию MAXTRANSFERSIZE = 10485760 (10 МБ).

Даже если применяется одно из этих условий, необходимо явно задать MAXTRANSFERSIZE более 64K в команде резервного копирования, чтобы получить оптимизированный алгоритм сжатия резервных копий, если только вы не находитесь в накопительном пакете обновления 5 (15.x) SQL Server 2019 (15.x) или более поздней версии.

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

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

SQL Server использует процесс оперативного резервного копирования, чтобы разрешить резервное копирование базы данных во время использования базы данных. Во время резервного копирования можно производить большинство операций. Например, во время создания резервной копии разрешены инструкции INSERT, UPDATE и DELETE.

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

Операции управления файлами, такие как инструкция ALTER DATABASE с параметрами ADD FILE или REMOVE FILE.
Операции сжатия базы данных или файла. К ним относятся операции автосхромки.

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

Метаданные

SQL Server включает следующие таблицы журнала резервных копий, отслеживающие действие резервного копирования:

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

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

Начиная с SQL Server 2012 (11.x), PASSWORD параметры и MEDIAPASSWORD параметры будут прекращены для создания резервных копий. Восстановление резервных копий, созданных с помощью паролей, по-прежнему возможно.

Разрешения

Разрешения BACKUP DATABASE и BACKUP LOG по умолчанию назначаются участникам предопределенной роли сервера sysadmin и предопределенным ролям базы данных db_owner и db_backupoperator.

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

Примеры

Этот раздел содержит следующие примеры.

А. Резервное копирование полной базы данных
В. Резервное копирование базы данных и журнала
В. Создание полной резервной копии файловых групп-получателей
Д. Создание разностной резервной копии файловых групп-получателей
Е. Создание и резервное копирование в односемейный зеркальный набор носителей
F. Создание и резервное копирование в многоэтапный зеркальный набор носителей
G. Резервное копирование в существующий зеркальный набор носителей
H. Создание сжатой резервной копии в новом наборе носителей
И. Резервное копирование до Хранилище BLOB-объектов Azure
J. [Резервное копирование в хранилище объектов, совместимое с S3]((#j-backing-up-to-s3-compatible-object-storage)
K. Отслеживание выполнения инструкции резервного копирования

Примечание.

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

А. Резервное копирование полной базы данных

Следующий пример производит резервное копирование базы данных AdventureWorks2022 в файл на диске.

BACKUP DATABASE AdventureWorks2022
 TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
    WITH FORMAT;
GO

В. Резервное копирование базы данных и журнала

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

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

Затем производится полное резервное копирование базы данных на устройство AdvWorksData и, после периода обновления, резервное копирование журнала на устройство AdvWorksLog.

-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USE master;
GO
ALTER DATABASE AdventureWorks2022
    SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData',
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog',
'X:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks2022 database.
BACKUP DATABASE AdventureWorks2022 TO AdvWorksData;
GO
-- Back up the AdventureWorks2022 log.
BACKUP LOG AdventureWorks2022
    TO AdvWorksLog;
GO

Примечание.

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

В. Создание полной резервной копии вторичных файловых групп

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

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck';
GO

Д. Создание разностной резервной копии файлов вторичных файловых групп

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

--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
    FILEGROUP = 'SalesGroup1',
    FILEGROUP = 'SalesGroup2'
    TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
    WITH
      DIFFERENTIAL;
GO

Е. Создание и резервное копирование в односемейный зеркальный набор носителей

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

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet0';

F. Создание и резервное копирование в многоэтапный зеркальный набор носителей

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

BACKUP DATABASE AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    FORMAT,
    MEDIANAME = 'AdventureWorksSet1';

G. Резервное копирование в существующий зеркальный набор носителей

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

BACKUP LOG AdventureWorks2022
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
    NOINIT,
    MEDIANAME = 'AdventureWorksSet1';

Примечание.

Параметр NOINIT, установленный по умолчанию, приведен здесь для ясности.

H. Создание сжатой резервной копии в новом наборе носителей

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

BACKUP DATABASE AdventureWorks2022 TO DISK='Z:\SQLServerBackups\AdvWorksData.bak'
WITH
    FORMAT,
    COMPRESSION;

И. Резервное копирование в Microsoft Хранилище BLOB-объектов Azure

В этом примере выполняется полная резервная копия Sales базы данных для Хранилище BLOB-объектов Azure. Имя учетной записи хранилища — mystorageaccount. Контейнер называется myfirstcontainer. Хранимая политика доступа уже создана с правами на чтение, запись, удаление и список. Учетные данные SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, были созданы с использованием подписанного URL-адреса, который связан с хранимой политикой доступа. Сведения о резервном копировании SQL Server для Хранилище BLOB-объектов Azure см. в статье SQL Server Backup and Restore with Хранилище BLOB-объектов Azure and SQL Server Backup to URL-адрес.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales.bak'
WITH STATS = 5;

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

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

J. Резервное копирование в хранилище объектов, совместимое с S3

Область применения: SQL Server 2022 (16.x)

В этом примере выполняется полная резервная копия базы данных для Sales платформы хранилища объектов, совместимой с S3. Имя учетных данных не требуется в инструкции или соответствует точному URL-пути, но будет выполнять поиск соответствующих учетных данных по указанному URL-адресу. Дополнительные сведения см. в статье о резервном копировании и восстановлении SQL Server с хранилищем объектов, совместимым с S3.

BACKUP DATABASE Sales
TO      URL = 's3://10.10.10.10:8787/sqls3backups/sales_01.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_02.bak'
,       URL = 's3://10.10.10.10:8787/sqls3backups/sales_03.bak'
WITH    FORMAT
,       STATS               = 10
,       COMPRESSION;

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

Следующий запрос возвращает информацию о выполняемых в данный момент инструкциях резервного копирования:

SELECT query = a.text, start_time, percent_complete,
    eta = dateadd(second,estimated_completion_time/1000, getdate())
FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command LIKE 'BACKUP%';

SQL Server

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

Платформа аналитики
Система (PDW)

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

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

Также применяется к Управляемый экземпляр SQL, включенным Azure Arc.

Синтаксис

BACKUP DATABASE { database_name | @database_name_var }
  TO URL = { 'physical_device_name' | @physical_device_name_var }[ ,...n ]
  WITH COPY_ONLY [, { <general_WITH_options> } ]
[;]

<general_WITH_options> [ ,...n ]::=

--Media Set Options
   MEDIADESCRIPTION = { 'text' | @text_variable }
 | MEDIANAME = { media_name | @media_name_variable }
 | BLOCKSIZE = { blocksize | @blocksize_variable }

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

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

--Compatibility Options
   RESTART

--Monitoring Options
   STATS [ = percentage ]

--Encryption Options
 ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } , encryptor_options ) <encryptor_options> ::=
   SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name

Аргументы

База данных

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

Внимание

Резервная копия базы данных, созданная на управляемом экземпляре, может быть восстановлена только в другом Управляемый экземпляр SQL Azure или только в экземпляре SQL Server 2022. Это связано с тем, что Управляемый экземпляр SQL имеет более высокую внутреннюю версию базы данных по сравнению с другими версиями SQL Server. Дополнительные сведения см. в статье "Восстановление резервной копии базы данных Управляемый экземпляр SQL в SQL Server 2022".

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

{ database_name | @database_name_var }

Это база данных, из которой создается полная резервная копия. Если это имя предоставляется в качестве переменной (@переменная_с_именем_базы_данных), оно может быть указано в виде строковой константы (@переменная_с_именем_базы_данных=имя_базы_данных) или переменной с типом данных символьной строки, за исключением типов данных ntext и text.

URL-адрес

Указывает URL-адрес, используемый для операции резервного копирования. Формат URL-адреса используется для создания резервных копий в службе хранилища Microsoft Azure.

Внимание

Чтобы создать резервную копию на нескольких устройствах при резервном копировании по URL-адресу, необходимо использовать маркеры подписанного URL-адреса (SAS). Примеры создания подписанного URL-адреса см. в статье sql Server Backup to URL-адрес и упрощение создания учетных данных SQL с помощью маркеров ПОДПИСАННОГО URL-адреса (SAS) в службе хранилища Azure с помощью PowerShell.

Параметры WITH

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

ШИФРОВАНИЕ

AES_128
AES_192
AES_256
TRIPLE_DES_3KEY
NO_ENCRYPTION

Если вы решили зашифровать, вам также придется указать шифратор с помощью параметров шифрования:

SERVER CERTIFICATE = <Encryptor_Name>
SERVER ASYMMETRIC KEY = <Encryptor_Name>

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

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

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

{ СЖАТИЕ | NO_COMPRESSION }

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

Компрессия
Явное включение сжатия резервных копий.

NO_COMPRESSION
Явное отключение сжатия резервной копии.

DESCRIPTION = { "text" | @text_variable }

NAME = { backup_set_name | @_backup| set_var }

Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если имя не указано, оно остается пустым.

MEDIADESCRIPTION = { текст | @text_variable }

Указывает произвольное текстовое описание набора носителей, длина которого не должна превышать 255 символов.

MEDIANAME = { media_name | @media_name_variable }

Указывает имя носителя для всего набора носителей резервных копий. Длина имени носителя не должна превышать 128 символов. Если указан аргумент MEDIANAME, то он должен совпадать с заранее заданным именем носителя, уже существующим в томах резервных копий. Если он не указан или указан параметр SKIP, проверка имени носителя отсутствует.

BLOCKSIZE = { блокировать | @blocksize_variable }

Параметры передачи данных

BUFFERCOUNT = { buffercount | @buffercount_variable }

Общий объем пространства, используемого буферами, определяется по следующей формуле: BUFFERCOUNT * MAXTRANSFERSIZE.

Примечание.

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

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Для баз данных с включенным прозрачным шифрованием данных (TDE) и одним файлом данных MAXTRANSFERSIZE по умолчанию — 65 536 (64 КБ). Для баз данных без включенного шифрования TDE MAXTRANSFERSIZE по умолчанию — 1 048 576 (1 МБ) при сохранении резервных копий на диск и 65 536 (64 КБ) при использовании VDI или ленточных носителей.

Примечание.

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

Параметры управления ошибками

{ NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА }

Определяет, разрешены ли контрольные суммы.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Параметры совместимости

ПЕРЕЗАПУСК

Данный параметр не делает ничего. Он оставлен в этой версии для совместимости с предыдущими версиями SQL Server.

Параметры мониторинга

STATS [ = процент ]

Ограничения для Управляемого экземпляра SQL

Максимальный размер чередующегося набора резервной копии составляет 195 ГБ (максимальный размер большого двоичного объекта). Чтобы уменьшить размер отдельного чередующегося набора и соблюсти это ограничение, можно увеличить число чередующихся наборов в команде резервного копирования.

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

Разрешения

Разрешения BACKUP DATABASE по умолчанию назначаются членам с предопределенной ролью сервера sysadmin и предопределенными ролями базы данных db_owner и db_backupoperator.

Проблемы с владением и разрешениями для URL-адреса могут помешать операции резервного копирования. SQL Server должен иметь возможность чтения и записи на устройство; учетная запись, в которой выполняется служба SQL Server, должна иметь разрешения на запись.

Примеры

В этом примере выполняется COPY_ONLY резервное копирование Sales в Microsoft Хранилище BLOB-объектов Azure. Имя учетной записи хранилища — mystorageaccount. Контейнер называется myfirstcontainer. Хранимая политика доступа была создана с правами на чтение, запись, удаление и составление списков. Учетные данные SQL Server, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, были созданы с использованием подписанного URL-адреса, который связан с хранимой политикой доступа. Сведения о резервном копировании SQL Server для Хранилище BLOB-объектов Azure см. в статье SQL Server Backup and Restore with Microsoft Хранилище BLOB-объектов Azure and SQL Server Backup to URL-адрес.

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_20160726.bak'
WITH STATS = 5, COPY_ONLY;

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

BACKUP DATABASE Sales
TO URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-01.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-02.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-03.bak',
URL = 'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales-04.bak'
WITH COPY_ONLY;

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

SQL Server

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

*Аналитика
Платформа (PDW) *

Система платформы аналитики

Создает резервную копию базы данных системы платформы аналитики (PDW) и сохраняет резервную копию устройства в указанном пользователем сетевом расположении. Используйте эту инструкцию вместе с RESTORE DATABASE (Analytics Platform System) для аварийного восстановления или копирования базы данных с одного устройства на другое.

Перед началом работы изучите статью "Получение и настройка сервера резервного копирования" в документации по Системе платформы аналитики (DPW).

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

Дополнительные сведения о резервном копировании баз данных Analytics Platform System (PDW) см. в разделе "Резервное копирование и восстановление" в документации по Системе платформы аналитики (PDW).

Синтаксис

--Create a full backup of a user database or the master database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    [ WITH [ ( ]<with_options> [ ,...n ][ ) ] ]
[;]

--Create a differential backup of a user database.
BACKUP DATABASE database_name
    TO DISK = '\\UNC_path\backup_directory'
    WITH [ ( ] DIFFERENTIAL
    [ , <with_options> [ ,...n ] [ ) ]
[;]

<with_options> ::=
    DESCRIPTION = 'text'
    | NAME = 'backup_name'

Аргументы

database_name

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

TO DISK = '\\UNC_path backup_directory\'

Сетевой путь и каталог, в который будет записываться система платформы Аналитики (PDW). Например, \\\xxx.xxx.xxx.xxx\backups\2012\Monthly\08.2012.Mybackup.

Путь к имени каталога резервного копирования должен уже существовать; его необходимо указать как полный путь UNC.
Каталог резервного копирования, backup_directory, не должен существовать до запуска команды резервного копирования. Система платформ аналитики (PDW) создаст каталог резервного копирования.
Путь к каталогу резервного копирования не может быть локальным путем, и он не может быть расположением на любом узле устройства платформы Аналитики (PDW).
Максимальная длина пути UNC и имени каталога резервного копирования равна 200 символов.
Для сервера или узла необходимо указать IP-адрес. Его нельзя указать в качестве имени узла или сервера.

DESCRIPTION = "text"

Задает текстовое описание резервной копии. Максимальная длина текста составляет 255 символов.

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

NAME = "backup _name"

Задает имя резервной копии. Имя резервной копии может отличаться от имени базы данных.

Длина имени не может превышать 128 символов.
Не удается включить путь.
Должно начинаться с буквы, цифры или подчеркивания (_). Разрешенные специальные символы: подчеркивание (_), дефис (-) или пробел ( ). Имена резервных копий не могут заканчиваться символом пробела.
Выполнение инструкции завершится ошибкой, если backup_name уже существует в заданном расположении.

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

DIFFERENTIAL (разностная)

Указывает, что необходимо создать разностную резервную копию пользовательской базы данных. Если не задать этот параметр, по умолчанию выполняется полное резервное копирование базы данных. Имя разностной резервной копии не обязательно совпадает с именем полной резервной копии. Для отслеживания разностной резервной копии и соответствующей ей полной резервной копии рекомендуется использовать одно и то же имя с добавлением diff или full соответственно.

Например:

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerFull';

BACKUP DATABASE Customer TO DISK = '\\xxx.xxx.xxx.xxx\backups\CustomerDiff' WITH DIFFERENTIAL;

Разрешения

BACKUP DATABASE Требуется разрешение или членство в предопределенных ролевой базе данных db_backupoperator. База master данных не может создавать резервную копию, но обычным пользователем, добавленным в роль db_backupoperator предопределенной базы данных. Создать резервную копию базы данных master может только роль sa, администратор структуры или участники предопределенная роль сервера sysadmin.

Требуется учетная запись Windows с разрешениями на доступ к каталогу резервного копирования, создание такого каталога и запись в него. Кроме того, необходимо сохранить имя учетной записи Windows и пароль в системе платформы Аналитики (PDW). Чтобы добавить эти сетевые учетные данные в систему платформы Аналитики (PDW), используйте хранимую процедуру sp_pdw_add_network_credentials — Azure Synapse Analytics .

Дополнительные сведения об управлении учетными данными в системе платформы Аналитики (PDW) см. в разделе "Безопасность ".

Обработка ошибок

Ошибки BACKUP DATABASE возникают в следующих ситуациях:

Разрешения пользователей недостаточно для резервного копирования.
У системы платформы аналитики (PDW) нет правильных разрешений на сетевое расположение, в котором будет храниться резервная копия.
База данных не существует.
Целевой каталог уже существует в общей сетевой папке.
Целевая сетевая папка недоступна.
У целевой сетевой папки недостаточно места для резервного копирования. Команда BACKUP DATABASE не подтверждает, что достаточно места на диске существует до начала резервной копии, что позволяет создать ошибку вне места на диске при запуске BACKUP DATABASE. При нехватке места на диске система платформы Аналитики (PDW) откатывает команду BACKUP DATABASE. Чтобы уменьшить размер базы данных, запустите DBCC SHRINKLOG (система платформы аналитики (PDW))
Попытка запустить резервное копирование в рамках транзакции.

Замечания

Перед выполнением резервного копирования базы данных используйте DBCC SHRINKLOG (система платформы аналитики (PDW)), чтобы уменьшить размер базы данных.

Резервная копия системы платформы аналитики (PDW) хранится в виде набора нескольких файлов в одном каталоге.

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

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

Полные резервные копии и разностные резервные копии хранятся в разных каталогах. Соглашения об именовании не применяются для указания того, что полная резервная копия и разностная резервная копия принадлежат вместе. Для отслеживания этого можно использовать собственные соглашения об именовании. Кроме того, это можно отследить, воспользовавшись инструкцией WITH DESCRIPTION для добавления описания, а затем воспользовавшись инструкцией RESTORE HEADERONLY для извлечения описания.

Ограничения

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

Резервные копии журналов транзакций системной master базы данных не поддерживаются.

Файлы резервной копии хранятся в формате, подходящем только для восстановления резервного копирования на устройство системы платформы аналитики (PDW) с помощью инструкции RESTORE DATABASE — Analytics Platform System .

Резервная копия с инструкцией BACKUP DATABASE не может использоваться для передачи данных или сведений пользователя в базы данных SMP SQL Server. Для этого можно воспользоваться функцией копирования удаленной таблицы. Дополнительные сведения см. в разделе "Копирование удаленной таблицы" в документации по Системе платформы аналитики (DPW).

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

На устройстве не может одновременно выполняться несколько операций резервного копирования или восстановления базы данных. Система платформ аналитики (PDW) будет выполнять резервное копирование или восстановление команд до завершения текущей команды резервного копирования или восстановления.

Целевое устройство для восстановления резервной копии должно иметь не меньше вычислительных узлов, чем исходное. Целевой объект может иметь больше вычислительных узлов, чем исходное устройство, но не может иметь меньше вычислительных узлов.

Система платформы аналитики (PDW) не отслеживает расположение и имена резервных копий, так как резервные копии хранятся вне устройства.

Система платформ аналитики (PDW) отслеживает успешность или сбой резервного копирования базы данных.

Разностную резервную копию можно создать только в том случае, если успешно выполнено последнее полное резервное копирование. Например, предположим, что в понедельник вы создаете полную резервную копию базы данных, а резервная копия Sales завершается успешно. Затем во вторник вы создаете полную резервную копию Sales базы данных и завершается сбоем. После этого сбоя вы не сможете создать разностную резервную копию на основе полной резервной копии понедельника. Перед созданием разностной резервной копии необходимо успешно создать полную резервную копию.

Метаданные

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

Производительность

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

Блокировка

Осуществляет блокировку ExclusiveUpdate объекта DATABASE.

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

Резервные копии системы платформ аналитики (PDW) не хранятся на устройстве. Следовательно, ИТ-специалисты отвечают за управление всеми аспектами безопасности резервных копий. Например, это включает управление безопасностью данных резервного копирования, безопасность сервера, используемого для хранения резервных копий, и безопасность сетевой инфраструктуры, которая подключает сервер резервного копирования к устройству системы платформы аналитики (PDW).

Управление сетевыми учетными данными

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

Внимание

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

Необходимо сохранить имя пользователя и пароль в системе платформы Аналитики (PDW), выполнив хранимую процедуру sp_pdw_add_network_credentials — Azure Synapse Analytics . Система платформы аналитики (PDW) использует Диспетчер учетных данных Windows для хранения и шифрования имен пользователей и паролей на узле управления и вычислительных узлах. Учетные данные не резервируются с помощью команды BACKUP DATABASE.

Сведения об удалении учетных данных сети из системы платформы Аналитики (PDW) см. в sp_pdw_remove_network_credentials — Azure Synapse Analytics.

Чтобы получить список всех сетевых учетных данных, хранящихся в системе платформы аналитики (PDW), используйте динамическое представление управления sys.dm_pdw_network_credentials .

Примеры

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

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

Внимание

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

EXEC sp_pdw_add_network_credentials 'xxx.xxx.xxx.xxx', 'domain1\backupuser', '*****';

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

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

EXEC sp_pdw_remove_network_credentials 'xxx.xxx.xxx.xxx';

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

В следующем примере создается полная резервная копия пользовательской базы данных "Счета". Система платформы аналитики (PDW) создаст каталог Invoices2013 и сохранит в нем резервные копии файлов\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full.

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Full';

Д. Создание разностной резервной копии пользовательской базы данных

В следующем примере создается разностная резервная копия, которая содержит все изменения, внесенные с момента последнего полного резервного копирования базы данных Invoices. Система платформы Аналитики (PDW) создаст \\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff каталог для хранения файлов. Описание Invoices 2013 differential backup будет сохранено вместе с информацией о заголовке резервной копии.

Разностная резервная копия будет создана успешно только в том случае, если успешно выполнено предыдущее полное резервное копирование базы данных "Счета".

BACKUP DATABASE Invoices TO DISK = '\\xxx.xxx.xxx.xxx\backups\yearly\Invoices2013Diff'
    WITH DIFFERENTIAL,
    DESCRIPTION = 'Invoices 2013 differential backup';

Е. Создание полной резервной копии базы данных master

В следующем примере создается полная резервная копия базы данных master, которая сохраняется в каталоге \\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master, где IP — это сетевой IP-адрес.

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master';

Данные для входа в устройство хранятся в базе данных master. Чтобы создать резервную копию данных для входа устройства, необходимо создать резервную master копию базы данных.

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

BACKUP DATABASE master TO DISK = '\\xxx.xxx.xxx.xxx\backups\2013\daily\20130722\master'
WITH (
    DESCRIPTION = 'Master Backup 20130722',
    NAME = 'login-backup'
)
;

RESTORE DATABASE — Parallel Data Warehouse

Поделиться через

BACKUP (Transact-SQL)

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

SQL Server

Синтаксис

Аргументы

База данных

ЖУРНАЛ

GROUP (<база данных>,... n)

СЕРВЕР

METADATA_ONLY

{ database_name | @database_name_var }

< > file_or_filegroup [ ,...n ]

FILE = { logical_file_name | @logical_file_name_var }

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var } [ ,...n ] ]

READ_WRITE_FILEGROUPS

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

TO <backup_device [ ,...>n ]

{ logical_device_name | @logical_device_name_var }

{ ДИСК | ЛЕНТА | URL} = { "physical_device_name" | @physical_device_name_var | 'NUL' }

ЗЕРКАЛЬНОЕ ОТОБРАЖЕНИЕ BACKUP_DEVICE <> [ ,...n ]

Параметры инструкции WITH

УЧЁТНЫЕ ДАННЫЕ

Снимок файла

DIFFERENTIAL (разностная)

ШИФРОВАНИЕ

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

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

[ СЖАТИЕ [ ( АЛГОРИТМ = { MS_XPRESS | ZSTD | accelerator_algorithm } [, LEVEL = { LOW | MEDIUM | HIGH } ] ] | NO_COMPRESSION ]

DESCRIPTION = { "text" | @text_variable }

NAME = { backup_set_name | @backup_set_var }

{ EXPIREDATE ='date' | RETAINDAYS = days }

{ METADATA_ONLY | SNAPSHOT }

Параметры набора носителей

{ NOINIT | INIT }

{ NOSKIP | SKIP }

{ NOFORMAT | FORMAT }

MEDIADESCRIPTION = { текст | @text_variable }

MEDIANAME = { media_name | @media_name_variable }

BLOCKSIZE = { блокировать | @blocksize_variable }

Параметры передачи данных

BUFFERCOUNT = { buffercount | @buffercount_variable }

MAXTRANSFERSIZE = { maxtransfersize | @ maxtransfersize_variable }

Параметры управления ошибками

{ NO_CHECKSUM | КОНТРОЛЬНАЯ СУММА }

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

Параметры совместимости

ПЕРЕЗАПУСК

Параметры мониторинга

STATS [ = процент ]

Параметры ленты

{ REWIND | NOREWIND }

{ ВЫГРУЗ | NOUNLOAD }

Параметры, относящиеся к журналам

{ NORECOVERY | STANDBY = undo_file_name }

NO_TRUNCATE

Работа с резервными копиями SQL Server

Типы резервного копирования

Усечение журнала транзакций

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

Работа с устройствами резервного копирования и наборами носителей

Устройства резервного копирования в чередующемся наборе носителей (чередующийся набор)

Работа с зеркальным набором носителей

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

Восстановление резервных копий SQL Server

Дополнительные рекомендации по параметрам РЕЗЕРВНОГО КОПИРОВАНИЯ

Взаимодействие SKIP, NOSKIP, INIT и NOINIT

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

Замечания

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

Метаданные

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

Разрешения

Примеры

А. Резервное копирование полной базы данных

В. Резервное копирование базы данных и журнала

В. Создание полной резервной копии вторичных файловых групп

Д. Создание разностной резервной копии файлов вторичных файловых групп

Е. Создание и резервное копирование в односемейный зеркальный набор носителей