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


BACKUP (Transact-SQL)

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

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

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

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

* SQL Server *  

 

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 синонимом SNAPSHOT. Используется интерфейс SNAPSHOTвиртуального устройства (VDI). Дополнительные сведения о VDI см . в справочнике по интерфейсу виртуального устройства (VDI).

{ database_name | @database_name_var }

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

Примечание.

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

< > file_or_filegroup [ , ... n ]

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

FILE = { logical_file_name | @logical_file_name_var }

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

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

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

Примечание.

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

  • n

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

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

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

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

    Дополнительные сведения о частичных резервных копиях см. в разделе "Частичные резервные копии" (SQL Server).

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-адрес.

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

Вы можете создать резервную копию в хранилище BLOB-объектов Microsoft 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-адрес хранилища BLOB-объектов Azure и упрощение создания учетных данных SQL с помощью маркеров подписанного URL-адреса (SAS) в службе хранилища Azure с помощью PowerShell.

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

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

Дополнительные сведения см. в разделе "Устройства резервного копирования" (SQL Server).

Примечание.

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

  • n

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

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

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

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

Примечание.

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

<backup_device>

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

  • n

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

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

  • [ next-mirror-to ]

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

Параметры WITH

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

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

Применимо к: SQL Server.

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

Снимок файла

Область применения: 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 создает полную резервную копию.

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

ШИФРОВАНИЕ

Используется для указания шифрования для резервного копирования. Можно указать алгоритм шифрования, с помощью которого будет зашифрована резервная копия, или указать значение 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)
    

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

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

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

    Инструкция backup Результат
    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ DATABASE_NAME НА {ДИСК | ЛЕНТА | URL}WITH NO_COMPRESSION Резервное копирование без сжатия
    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ DATABASE_NAME НА {ДИСК | ЛЕНТА | URL} С СЖАТИЕМ Резервное копирование с сжатием с помощью алгоритма, заданного параметром backup compression algorithm сервера (по умолчанию MS_XPRESS)
    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ DATABASE_NAME НА {ДИСК | ЛЕНТА | URL} WITH COMPRESSION (ALGORITHM = MS_XPRESS) Резервное копирование с помощью MS_XPRESS алгоритма
    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ DATABASE_NAME НА {ДИСК | ЛЕНТА | URL} WITH COMPRESSION (ALGORITHM = ZSTD) Резервное копирование с помощью алгоритма ZSTD.
    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ DATABASE_NAME НА {ДИСК | ЛЕНТА | URL} WITH COMPRESSION (АЛГОРИТМ = ZSTD, LEVEL = HIGH) Резервное копирование с сжатием с помощью алгоритма ZSTD с уровнем HIGHсжатия.

DESCRIPTION = { "text" | @text_variable }

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

NAME = { backup_set_name | @backup_set_var }

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

{ EXPIREDATE = 'date' | RETAINDAYS = days }

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

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

Внимание

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

  • EXPIREDATE = { "date" | @date_var }

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

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

    Например:

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

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

    Примечание.

    Чтобы игнорировать дату истечения срока действия, используйте параметр 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 — значение по умолчанию.

    Дополнительные сведения см. в разделе "Наборы носителей", семейства носителей и резервные наборы данных (SQL Server).

  • INIT

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

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

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

    Дополнительные сведения см. в разделе "Наборы носителей", семейства носителей и резервные наборы данных (SQL Server).

{ NOSKIP | SKIP }

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

Примечание.

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

  • NOSKIP

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

  • СКИП

    Отключает проверку срока действия резервного набора данных и имени, которое обычно выполняется BACKUP инструкцией, чтобы предотвратить перезаписи резервных наборов. Сведения о взаимодействии между { INIT | NOINIT } и {NOSKIP | SKIP }, см. далее в этой статье.

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

{ NOFORMAT | FORMAT }

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

  • NOFORMAT

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

  • ФОРМАТ

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

    Внимание

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

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

MEDIADESCRIPTION = { text | @text_variable }

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

MEDIANAME = { media_name | @media_name_variable }

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

BLOCKSIZE = { 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 см. в блоге Неправильный параметр передачи данных BufferCount может привести к OOM.

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

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

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

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

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

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

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

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

  • NO_CHECKSUM

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

  • Контрольная сумма

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

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

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

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

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

  • STOP_ON_ERROR

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

  • CONTINUE_AFTER_ERROR

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

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

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

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

ПЕРЕЗАПУСК

Данный параметр не делает ничего. Этот параметр принимается версией для совместимости с SQL Server 2005 Analysis Services (SSAS).

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

STATS [ = процент ]

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

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

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

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

{ REWIND | NOREWIND }

  • ПЕРЕМАТЫВАТЬ

    Указывает, что SQL Server выпускает и перемотывает ленту. REWIND — значение по умолчанию.

  • NOREWIND

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

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

    Примечание.

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

{ ВЫГРУЗ | NOUNLOAD }

Примечание.

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

  • РАЗГРУЖАТЬ

    Указывает, что лента автоматически перематывается и выгружается по завершении операции резервного копирования. UNLOAD значение по умолчанию при запуске сеанса.

  • NOUNLOAD

    Указывает, что после BACKUP операции лента остается загруженной на ленточный диск.

Примечание.

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

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

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

Примечание.

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

{ NORECOVERY | STANDBY = undo_file_name }

  • NORECOVERY

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

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

  • STANDBY = 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 LOGCOPY_ONLY и CONTINUE_AFTER_ERROR.

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

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

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

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

Примечание.

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

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

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

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

    Область охвата резервной копии Типы резервного копирования
    Вся база данных Резервные копии базы данных охватывают всю базу данных.

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

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

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

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

    Примечание.

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

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

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

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

Примечание.

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

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

Резервный носитель форматируется оператором BACKUP , если и только если одно из следующих значений имеет значение true:

  • Указан параметр 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). Дополнительные сведения о наборах носителей и семействах носителей в целом см. в разделе "Наборы носителей", семейства носителей и резервные наборы резервных копий (SQL Server).

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

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

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

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

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

Примечание.

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

Параметр skip NOINIT INIT
NOSKIP Если в томе содержится правильный заголовок носителя, то выполняется проверка совпадения имени носителя с указанным параметром MEDIANAME (если он задан). Если установлено совпадение, резервный набор данных дозаписывается с сохранением всех существующих резервных наборов данных.
Если том не содержит допустимый заголовок носителя, возникает ошибка.
Если том содержит заголовок носителя, проводятся следующие проверки.
  • Если MEDIANAME задано, проверяет, совпадает ли указанное имя носителя с именем носителя заголовка носителя. 1
  • Проверяется, есть ли на носителе резервные наборы данных с неистекшим сроком действия. Если есть, то процесс резервного копирования прекращается.

Если все эти проверки пройдены, то происходит перезапись всех резервных наборов данных на носителе. Сохраняется только заголовок носителя.
Если том не содержит допустимый заголовок носителя, создает его с указанным MEDIANAME и MEDIADESCRIPTION, если таковой имеется.
SKIP Если том содержит верный заголовок носителя, то резервный набор данных дозаписывается с сохранением всех существующих резервных наборов данных. Если том содержит допустимый заголовок мультимедиа 2 , перезаписывает все резервные наборы на носителе, сохраняя только заголовок носителя.
Если носитель пуст, то создается заголовок носителя, исходя из заданных параметров MEDIANAME и MEDIADESCRIPTION (если они указаны).

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

2 В допустимость входит номер версии 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, автоматически увеличивается до 128 K, MAXTRANSFERSIZE чтобы включить оптимизированный алгоритм. Если 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 в команде резервного копирования, чтобы получить оптимизированный алгоритм сжатия резервных копий, если только вы не используете накопительный пакет обновления (15.x) SQL Server 2019 (15.x) или более поздней версии.

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

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

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

Примеры

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

Примечание.

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

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

Следующий пример производит резервное копирование базы данных 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

EXECUTE sp_addumpdevice 'disk', 'AdvWorksData', 'Z:\SQLServerBackups\AdvWorksData.bak';
GO

EXECUTE 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 Azure Blob Storage and SQL Server backup to URL-адрес хранилища BLOB-объектов Azure.

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 a.text AS query,
       start_time,
       percent_complete,
       dateadd(second, estimated_completion_time / 1000, getdate()) AS eta
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS a
WHERE r.command LIKE 'BACKUP%';

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

 

Управляемый экземпляр 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 }

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

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

URL-адрес

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

Внимание

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

  • n

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

Параметры WITH

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

ШИФРОВАНИЕ

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

  • 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 }

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

NAME = { backup_set_name | @_backup| set_var }

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

MEDIADESCRIPTION = { text | @text_variable }

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

MEDIANAME = { media_name | @media_name_variable }

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

BLOCKSIZE = { blocksize | @blocksize_variable }

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

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

BUFFERCOUNT = { buffercount | @buffercount_variable }

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

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

Примечание.

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

MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

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

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

Примечание.

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

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

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

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

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

  • NO_CHECKSUM

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

  • Контрольная сумма

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

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

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

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

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

  • STOP_ON_ERROR

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

  • CONTINUE_AFTER_ERROR

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

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

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

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

ПЕРЕЗАПУСК

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

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

STATS [ = процент ]

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

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

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

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

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

Разрешения

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

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

Примеры

В этом примере выполняется резервное COPY_ONLY копирование Sales в хранилище BLOB-объектов Microsoft 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;

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

 

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

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

Перед началом работы изучите статью "Получение и настройка сервера резервного копирования" в документации по Системе платформы аналитики (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 имя"

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

  • Длина имени не может превышать 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
  • Попытка запустить резервное копирование в рамках транзакции.

Замечания

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

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

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

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

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

Ограничения

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

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

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

Резервная копия с инструкцией 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) сохраняет эти учетные данные и использует их для операций резервного копирования и восстановления.

Внимание

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

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

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

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

EXECUTE 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 каталог для хранения файлов. Описание разностной резервной копии счетов 2013 хранится с данными заголовка для резервной копии.

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

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';

F. Создайте резервную копию данных для входа на устройство.

Данные для входа в устройство хранятся в базе данных 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'
)
;