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

BACKUP (Transact-SQL)

  • Статья

Изменения: 12 декабря 2006 г.

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

Значок ссылки на разделСинтаксические обозначения в Transact-SQL

Синтаксис

Backing 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 ] } ]
[;]

Backing 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 ] } ]
[;]

Creating 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 ] } ]
[;]

Backing 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_optionspec> } [ ,...n ] ]
[;]

Truncating the Transaction Log (breaks the log chain) 
BACKUP LOG { database_name | @database_name_var } 
  WITH { NO_LOG | TRUNCATE_ONLY } 
[;]

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

<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 
  | DESCRIPTION = { 'text' | @text_variable } 
 | NAME = { backup_set_name | @backup_set_name_var } 
 | PASSWORD = { password | @password_variable } 
 | [ EXPIREDATE = { date | @date_var } 
        | RETAINDAYS = { days | @days_var } ] 
 | NO_LOG 

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

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

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

--Compatibility Options
   RESTART 

--Monitoring Options
   STATS [ = percentage ] 

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

--Log-specific Options
   { NORECOVERY | STANDBY = undo_file_name }
 | NO_TRUNCATE

Аргументы

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Для базы данных master может быть произведено только полное резервное копирование.

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    После обычной процедуры создания резервной копии журналов некоторые записи в журнале транзакций становятся неактивными, если не были указаны параметры WITH NO_TRUNCATE (создавать без усечения) или COPY_ONLY (только копировать). Журнал усекается после того, как все записи внутри одного или нескольких виртуальных файлов журнала становятся неактивными. Если журнал не усекается после совершения нескольких процедур резервного копирования журнала, это означает, что что-то может препятствовать его усечению. Дополнительные сведения см. в разделе Управление журналом транзакций.

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Невозможно создать резервную копию зеркальной базы данных при участии в зеркальном отображении базы данных.

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

    • FILE ={ logical_file_name| **@**logical_file_name_var }
      Логическое имя файла или переменная, значение которой равно логическому имени файла, который следует включить в резервную копию.

    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      Логическое имя файловой группы или переменная, значение которой равно логическому имени файловой группы, которую следует включить в резервную копию. В простой модели восстановления создание резервной копии файловой группы разрешено только для файловых групп, доступных только для чтения.

      ms186865.note(ru-ru,SQL.90).gifПримечание.
      Рекомендуется использовать резервные копии файлов в случае, если размер базы данных и требования по производительности делают полное резервное копирование базы данных нецелесообразным.
    • n
      Местозаполнитель, который показывает, что через запятую можно указать несколько файлов или файловых групп. Их число не ограничено.

    Дополнительные сведения см. в следующих разделах: Полное резервное копирование и Как создавать резервные копии файлов и файловых групп (язык Transact-SQL).

  • READ_WRITE_FILEGROUPS [ , FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var } [ ,...n ] ]
    Определяет частичную резервную копию. Частичная резервная копия включает в себя все файлы в базе данных, доступные для чтения и записи: первичную файловую группу и любые вторичные файловые группы, доступные для чтения и записи, а также любые указанные файлы или файловые группы, доступные только для чтения.

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

      ms186865.note(ru-ru,SQL.90).gifВажно!
      Явное перечисление файловых групп, доступных для чтения и записи, с применением FILEGROUP вместо READ_WRITE_FILEGROUPS создает резервную копию файлов.
    • FILEGROUP = { logical_filegroup_name| **@**logical_filegroup_name_var }
      Логическое имя файловой группы, доступной только для чтения, или переменная, значение которой равно логическому имени файловой группы, доступной только для чтения, которую следует включить в частичную резервную копию. Дополнительные сведения см. выше в подразделе «<файл_или_файловая_группа>».
    • n
      Местозаполнитель, который показывает, что через запятую можно указать несколько файловых групп, доступных только для чтения.

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

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

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

      • { logical_device_name | @logical_device_name_var }
        Логическое имя устройства резервного копирования (созданное процедурой sp_addumpdevice), на которое выполняется резервное копирование базы данных. Логическое имя должно соответствовать правилам для идентификаторов. Если аргумент задается в виде переменной (@logical_device_name_var), то ей можно присвоить как строковую константу (@logical_device_name_var        =         логическое_имя_устройства_резервного_копирования), так и другую переменную любого строкового типа данных, за исключением типов данных ntext и text.

      • { DISK | TAPE } = { 'physical_device_name' | **@**physical_device_name_var }
        Определяет файл диска или ленточное устройство. Указанное устройство не обязательно должно существовать до выполнения инструкции BACKUP. Если физического устройства не существует, а в инструкции BACKUP не указан параметр INIT, то резервная копия дозаписывается на устройство.

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

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

  • MIRROR TO <устройство_копирования> [ ,...n ]
    Указывает набор из одного или нескольких устройств резервного копирования, которые будут зеркалами для устройств резервного копирования, описанных в предложении TO. В предложении MIRROR TO должен быть указан тот же тип и то же количество устройств резервного копирования, что и в предложении TO. Максимальное число предложений MIRROR TO — три.

    Этот параметр доступен только в SQL Server 2005 Enterprise Edition и более поздних версиях.

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Для MIRROR TO = DISK BACKUP автоматически определяет подходящий размер блока для дисковых устройств. Дополнительные сведения о размере блока см. в разделе «BLOCKSIZE» ниже в этой таблице.
    • <устройство_резервного_копирования>
      См. подраздел «<устройство_резервного_копирования>» выше в этом разделе.
    • n
      Местозаполнитель, который показывает, что можно указать до 64 устройств резервного копирования через запятую. Количество устройств в предложении MIRROR TO должно быть равно количеству устройств в предложении TO.
  • [ next-mirror-to ]
    Местозаполнитель, показывающий, что в одной инструкции BACKUP в дополнение к одному предложению TO может содержаться до трех предложений MIRROR TO.

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

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

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    По умолчанию инструкция BACKUP DATABASE создает полную резервную копию.

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

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

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

ms186865.note(ru-ru,SQL.90).gifПримечание.
Чтобы задать резервный набор данных для операции восстановления, используйте параметр FILE =<номер_файла_резервного_набора>. Дополнительные сведения о том, как задать резервный набор данных, см. в разделе Аргументы инструкции RESTORE (Transact-SQL).

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

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

    • Если инструкция BACKUP DATABASE используется с параметром COPY_ONLY, то создается полная резервная копия, которая не может быть использована в качестве базовой разностной копии. Битовая карта разностного резервного копирования не обновляется, а разностные резервные копии ведут себя так, словно резервной копии только для копирования не существует. Последующие разностные резервные копии используют в качестве своей основы самую свежую из обычных полных резервных копий.
      ms186865.note(ru-ru,SQL.90).gifВажно!
      Если параметры DIFFERENTIAL и COPY_ONLY используются вместе, то параметр COPY_ONLY не учитывается, и создается разностная резервная копия.
    • При использовании с инструкцией BACKUP LOG, параметр COPY_ONLY создает резервную копию журнала только для копирования, при этом журнал транзакций не усекается. Резервная копия журнала, предназначенная только для копирования, не влияет на цепочку журналов. Другие резервные копии журналов ведут себя так, словно ее не существует.

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

  • DESCRIPTION = { 'text' | **@**text_variable }
    Указывает произвольное текстовое описание резервного набора данных. В этой строке может содержаться до 255 символов.
  • NAME = { backup_set_name| **@**backup_set_var }
    Указывает имя резервного набора данных. Длина имени не может превышать 128 символов. Если параметр NAME не указан, то имя является пустым.

  • PASSWORD = { password | **@**password_variable }
    Устанавливает пароль на резервный набор данных. PASSWORD является строкой типа character. Если для резервного набора данных определен пароль, то он должен указываться при проведении любой операции восстановления SQL Server из резервного набора данных. Однако пароль резервного набора данных не защищает файл резервной копии от перезаписи. Для предотвращения перезаписи файла резервной копии используйте пароль набора носителей (обратитесь к параметру MEDIAPASSWORD, находящемуся ниже в этой таблице). (Дополнительные сведения о паролях см. в подразделе «Разрешения» ниже.)

    ms186865.security(ru-ru,SQL.90).gifПримечание безопасности.
    Данный пароль не обеспечивает надежную защиту. Он предназначен для предотвращения неправильного восстановления с использованием средств SQL Server 2005 авторизованными или неавторизованными пользователями. При этом остается возможным чтение резервных данных с использованием других средств или замена пароля. Оптимальным способом защиты резервных копий является хранение лент с резервными копиями в безопасном месте или создание резервных копий на диск в виде файлов, защищенных соответствующими списками управления доступом. Списки управления доступом необходимо задавать на корневой каталог, в котором созданы резервные копии.
    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Параметр PASSWORD будет удален в следующей версии SQL Server.

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

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

    ms186865.note(ru-ru,SQL.90).gifВажно!
    Данные параметры защищают SQL Server только от перезаписи файла. Ленточные носители могут быть стерты при помощи других методов, а файлы на диске могут быть удалены через операционную систему. Дополнительные сведения о проверке истечения срока действия см. в подразделах «SKIP» и «FORMAT» в этом разделе.

    • EXPIREDATE = { date | **@**date_var }
      Указывает дату, по наступлении которой резервный набор данных считается устаревшим и может быть перезаписан. Если параметр задается с помощью переменной (@date_var), то содержащаяся в ней дата должна соответствовать настроенному системному формату для типа datetime и должна быть указана одним из следующих способов:

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

      Например:

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

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

      ms186865.note(ru-ru,SQL.90).gifПримечание.
      Чтобы не учитывать дату истечения срока, используйте параметр SKIP.
    • RETAINDAYS = { days| **@days_var }
      Указывает количество дней, которое должно пройти, прежде чем этот набор носителей резервных копий может быть перезаписан. Если параметр задается с помощью аргумента (      @**days_var), то он должен быть целым числом.

  • NO_LOG
    При использовании в контексте инструкции BACKUP DATABASE указывает, что в резервной копии не будут содержаться журналы. Именно так резервные копии файлов создавались до появления SQL Server 2005. Резервная копия базы данных, созданная с параметром NO_LOG, тождественна полному набору резервных копий файлов, в которых не содержатся записи журналов.

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

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

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

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Дополнительные сведения о взаимодействии между параметрами { NOINIT | INIT } и { NOSKIP | SKIP } см. в подразделе «Примечания» ниже в этом разделе.

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

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

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

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

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

      ms186865.note(ru-ru,SQL.90).gifПримечание.
      Если носитель резервных копий защищен паролем, то SQL Server не записывает на носитель до тех пор, пока не предоставлен пароль носителя. Эта проверка не отменяется параметром SKIP. На носителе, защищенном паролем, перезапись возможна только путем форматирования, которое стирает резервные копии на носителе. Дополнительные сведения о паролях носителя см. в описании параметра «MEDIAPASSWORD», приведенном выше в данном разделе. Дополнительные сведения о форматировании носителей см. в описании инструкции «FORMAT», приведенном выше в данном разделе.

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

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Дополнительные сведения о взаимодействии между параметрами { NOINIT | INIT } и { NOSKIP | SKIP } см. в подразделе «Примечания» ниже в этом разделе.
    • NOSKIP
      Указывает инструкции BACKUP, что следует провести проверку сроков действия всех резервных наборов данных на носителе перед тем, как разрешить их перезапись. Такое поведение определено по умолчанию.

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

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

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

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

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

      ms186865.note(ru-ru,SQL.90).gifВажно!
      Используйте FORMAT аккуратно. Форматирование любого тома из набора носителей делает весь набор непригодным для использования. Например, если инициализируется одиночная лента, принадлежащая существующему чередующемуся набору носителей, то становится невозможно использовать весь набор носителей.

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

  • MEDIADESCRIPTION = { text | **@**text_variable }
    Указывает произвольное текстовое описание набора носителей, длина которого не должна превышать 255 символов.
  • MEDIANAME = { media_name | **@**media_name_variable }
    Указывает имя носителя для всего набора носителей резервных копий. Длина имени носителя не должна превышать 128 символов. Если указан параметр MEDIANAME, то он должен совпадать с заранее заданным именем носителя, уже существующим в томах резервных копий. Если этот параметр не указан или если указан параметр SKIP, то проверки имени носителя не происходит.

  • MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
    Устанавливает пароль на набор носителей. MEDIAPASSWORD является строкой типа character.

    Если для набора носителей задан пароль, то перед созданием резервного набора данных на этом наборе носителей необходимо указать пароль. Кроме того, этот пароль также должен быть указан для выполнения любой операции восстановления из набора носителей. Защищенный паролем носитель может быть перезаписан только при помощи переформатирования. Дополнительные сведения см. в описании параметра FORMAT. (Дополнительные сведения о паролях см. в подразделе «Разрешения» далее.)

    ms186865.security(ru-ru,SQL.90).gifПримечание безопасности.
    Данный пароль не обеспечивает надежную защиту. Он предназначен для предотвращения неправильного восстановления при использовании средств SQL Server 2005 авторизованными или неавторизованными пользователями. При этом остается возможным чтение резервных данных с использованием других средств или замена пароля. Оптимальным способом защиты резервных копий является хранение лент с резервными копиями в безопасном месте или создание резервных копий на диск в виде файлов, защищенных соответствующими списками управления доступом (ACL). Списки ACL необходимо задавать на корневой каталог, в котором созданы резервные копии.
    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Параметр MEDIAPASSWORD будет удален в следующей версии SQL Server.

  • BLOCKSIZE = { blocksize | **@**blocksize_variable }
    Указывает размер физического блока в байтах. Поддерживаются размеры 512, 1 024, 2 048, 4 096, 8 192, 16 384, 32 768 и 65 536 байт (64 КБ). Значение по умолчанию равно 65536 для ленточных устройств и 512 для других устройств. Обычно в этом параметре нет необходимости, так как инструкция BACKUP автоматически выбирает размер блока, соответствующий устройству. Явная установка размера блока отменяет автоматический выбор размера блока.

    Если создается резервная копия, которую планируется копировать на компакт-диск и восстанавливать с него, укажите BLOCKSIZE=2048.

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Этот параметр обычно влияет на производительность только при записи на ленточные устройства.

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

  • BUFFERCOUNT = { buffercount | **@**buffercount_variable }
    Указывает общее число буферов ввода-вывода, которые будут использоваться для операции резервного копирования. Можно указать любое целое положительное значение, однако большое число буферов может вызвать ошибку нехватки памяти из-за чрезмерного виртуального адресного пространства в процессе Sqlservr.exe.

    Общее используемое буферами пространство определяется по следующей формуле: buffercount*****maxtransfersize.

  • MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
    Указывает наибольший объем пакета данных в байтах для обмена между SQL Server и носителем резервного набора. Поддерживаются значения, кратные 65 536 байтам (64 КБ), вплоть до 4 194 304 байт (4 МБ).

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

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

  • { NO_CHECKSUM | CHECKSUM }
    Определяет, разрешены ли контрольные суммы.

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

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

      1. Перед записью страницы на носитель резервных копий инструкция BACKUP проверяет страницу (контрольную сумму страницы или обрыв страницы) в том случае, если эти сведения присутствуют на странице.
      2. Независимо от того, присутствует ли контрольная сумма страницы или нет, инструкция BACKUP создает отдельные контрольные суммы резервных копий для потока резервных файлов. Дополнительно операции восстановления могут использовать контрольные суммы резервных копий для проверки наличия повреждений в резервных файлах. Контрольная сумма резервной копии хранится на носителе резервных файлов, а не на страницах базы данных. Дополнительно контрольную сумму резервной копии можно использовать во время восстановления.

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

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

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

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

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

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

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

Параметры наблюдения

  • STATS [ **=**percentage ]
    Выводит сообщение каждый раз при выполнении указанного процентного интервала, используется для шкалы прогресса. Если параметр percentage не задан, то SQL Server выдает сообщение после каждых выполненных 10 процентов.

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

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

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

  • { REWIND | NOREWIND }

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

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

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

      ms186865.note(ru-ru,SQL.90).gifПримечание.
      При использовании параметра NOREWIND экземпляр SQL Server продолжает владеть накопителем на магнитной ленте до тех пор, пока инструкция BACKUP или RESTORE, работающая в этом же процессе, не использует параметр REWIND или UNLOAD, или пока не закончит работу экземпляр сервера. Поскольку лента остается открытой, другие процессы не могут получить доступа к ленте. Дополнительные сведения об отображении списка открытых лент и закрытии открытой ленты см. в разделе Устройства резервного копирования.

  • { UNLOAD | NOUNLOAD }

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Параметр UNLOAD/NOUNLOAD является настройкой сеанса, он сохраняется в течение работы сеанса или пока не будет сброшен при указании другого значения.
    • UNLOAD
      Указывает, что лента автоматически перематывается и выгружается по завершению операции резервного копирования. Параметр UNLOAD применяется в начале сеанса по умолчанию.
    • NOUNLOAD
      Указывает, что после завершения операции BACKUP лента останется в накопителе.
ms186865.note(ru-ru,SQL.90).gifПримечание.
При резервном копировании на ленточное устройство параметр BLOCKSIZE влияет на производительность операции резервного копирования. Этот параметр обычно влияет на производительность только при записи на ленточные устройства.

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

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

ms186865.note(ru-ru,SQL.90).gifПримечание.
Если создание резервных копий журналов не требуется, применяйте простую модель восстановления. Дополнительные сведения см. в разделе Резервное копирование при простой модели восстановления.

  • { 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, местоположение которого хранится в журнале базы данных. Если указанный файл уже существует, компонент Database Engine перезаписывает его; если файл не существует, компонент Database Engine его создает. Резервный файл становится частью базы данных.

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

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

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

    Без параметра NO_TRUNCATE база данных должна находиться в оперативном режиме.

    Если база данных находится в состоянии OFFLINE или EMERGENCY, то инструкция BACKUP не разрешена даже с параметром NO_TRUNCATE.

  • [ NO_LOG | TRUNCATE_ONLY ]

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    Данный параметр будет удален в следующих версиях SQL Server. Избегайте использования данного параметра в новых разработках и запланируйте модификацию приложений, которые сейчас его используют.

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

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

    ms186865.Caution(ru-ru,SQL.90).gifВнимание!
    Не рекомендуется применение параметров NO_LOG или TRUNCATE_ONLY для ручного усечения журнала транзакций, так как это нарушает цепочку журналов. До создания следующей полной или разностной резервной копии база данных не будет защищена от ошибок носителя. Используйте ручное усечение журнала только в исключительных обстоятельствах, немедленно создавая при этом резервные копии данных.

Замечания

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

Инструкция BACKUP не разрешена в явных и неявных транзакциях.

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

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

Параллелизм

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

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

  • операции управления файлами, такие как инструкция ALTER DATABASE либо с параметром ADD FILE, либо с параметром REMOVE FILE;
  • операции сжатия базы данных или файла. Сюда же включены операции автоматического сжатия.

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

Форматирование носителей резервных копий

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

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

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

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

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

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

    Область охвата резервной копии Типы резервного копирования

    Вся база данных

    Резервные копии базы данных охватывают всю базу данных.

    Частичная копия базы данных

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

    Файл или файловая группа

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

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

    ms186865.note(ru-ru,SQL.90).gifПримечание.
    До создания первой резервной копии журнала необходимо создать полную резервную копию базы данных.

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

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

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

Во время полного резервного копирования в SQL Server 2005 резервные копии полнотекстовых данных создаются вместе с остальными данными базы данных. Операция резервного копирования обрабатывает полнотекстовые каталоги так же, как обычные файлы. Например, резервные копии каталогов можно создать отдельно, используя предложение FILE= для выбора каталогов (логическое имя файла для каждого полнотекстового каталога в виде sysft_<имя каталога>).

Во время процедуры резервного копирования каталог переводится в режим «только для чтения», и процесс «сканирования» (процесс создания и управления полнотекстовым индексом) приостанавливается до окончания процедуры.

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

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

ms186865.note(ru-ru,SQL.90).gifПримечание.
Если носитель на магнитной ленте пуст или файла резервной копии диска не существует, то все эти взаимодействия записывают заголовок носителя и продолжают работу. Если носитель не пустой или у него отсутствует допустимый заголовок, то эти операции с помощью обратной связи сообщают о том, что отсутствует допустимый носитель MTF, и прекращают операцию резервного копирования.
NOINIT INIT

NOSKIP

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

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

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

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

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

Если в томе не содержится правильного заголовка носителя, то он создается исходя из заданных параметров MEDIANAME, MEDIAPASSWORD и MEDIADESCRIPTION, если таковые имеются.

SKIP

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

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

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

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

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

Таблицы журнала резервного копирования

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

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

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

ms186865.Caution(ru-ru,SQL.90).gifВнимание!
Резервные копии, созданные более поздними версиями SQL Server, не могут быть восстановлены в более ранних версиях SQL Server.

Инструкция BACKUP поддерживает следующие ключевые слова для предоставления обратной совместимости с более ранними версиями SQL Server.

  • Параметр RESTART поддерживается в целях совместимости, но не выполняет никаких действий в SQL Server 2005.
  • В целях поддержки обратной совместимости в инструкциях BACKUP допускается использование ключевого слова DUMP вместо ключевого слова BACKUP. Также возможно использование ключевого слова TRANSACTION вместо ключевого слова LOG. Компонент SQL Server Database Engine интерпретирует ключевые слова DUMP DATABASE или DUMP TRANSACTION таким же образом, как и BACKUP DATABASE или BACKUP LOG, соответственно.
    ms186865.note(ru-ru,SQL.90).gifВажно!
    Инструкция DUMP включена для обратной совместимости. В будущей версии Microsoft SQL Server эта возможность будет удалена. Избегайте использования этой возможности в новых разработках и запланируйте изменение существующих приложений, в которых она применяется. Вместо нее следует использовать инструкцию BACKUP.

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

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

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

BACKUP DATABASE AdventureWorks
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 AdventureWorks database;
GO

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

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

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

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

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

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

BACKUP DATABASE AdventureWorks
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
ms186865.note(ru-ru,SQL.90).gifВажно!
Этот пример создан для того, чтобы была возможность протестировать его на локальной системе. На практике резервное копирование на несколько устройств, находящихся на одном диске, приводит к ухудшению производительности и сводит на нет пользу от избыточности, ради которой и были разработаны зеркальные наборы носителей.

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

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

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

Зеркальная копия Семейство носителей 1 Семейство носителей 2 Семейство носителей 3

0

C:\AdventureWorks1a.bak

C:\AdventureWorks2a.bak

C:\AdventureWorks3a.bak

1

C:\AdventureWorks1b.bak

C:\AdventureWorks2b.bak

C:\AdventureWorks3b.bak

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

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

Разрешения

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

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

Задание паролей для резервных наборов данных и наборов носителей является дополнительной возможностью инструкции BACKUP. Данный пароль не обеспечивает надежную защиту. Он предназначен для предотвращения неправильного восстановления с использованием средств SQL Server 2005> авторизованными или неавторизованными пользователями. При этом остается возможным чтение резервных данных с использованием других средств или замена пароля. Также пароли не предотвращают перезапись носителей посредством параметра FORMAT. Рекомендуется использовать надежные пароли. Дополнительные сведения о надежных паролях см. в разделе Надежные пароли.

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

Задание паролей на объекты, которые не были созданы с соответствующими паролями, является ошибкой.

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

Дополнительные сведения о воздействии паролей на параметры SKIP, NOSKIP, INIT и NOINIT см. в подразделе «Примечания» ниже в этом разделе.

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

Примеры

ms186865.note(ru-ru,SQL.90).gifПримечание.
База данных AdventureWorks показана для примера. AdventureWorks — это один из образцов баз данных, включенных в состав SQL Server 2005. Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения об этой базе данных см. в разделе Примеры и образцы баз данных.

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

  • А. Создание резервной копии всей базы данных
  • Б. Создание резервной копии базы данных и журнала
  • В. Создание полной резервной копии файлов вторичных файловых групп
  • Г. Создание разностной резервной копии файлов вторичных файловых групп
  • Д. Создание зеркального набора носителей с одним семейством и резервное копирование на него
  • Е. Создание зеркального набора носителей с несколькими семействами и резервное копирование на него
  • Ж. Создание резервной копии на существующем зеркальном наборе носителей
ms186865.note(ru-ru,SQL.90).gifПримечание.
В разделах руководства по резервному копированию содержатся дополнительные примеры. Дополнительные сведения см. в разделе Разделы руководства по созданию резервных копий и восстановлению из них (Transact-SQL).

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

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

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

Б. Создание резервной копии базы данных и журнала

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

Далее используется процедура 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 AdventureWorks
   SET RECOVERY FULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices. 
USE master
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksData', 
'Z:\SQLServerBackups\AdvWorksData.bak';
GO
EXEC sp_addumpdevice 'disk', 'AdvWorksLog', 
'Z:\SQLServerBackups\AdvWorksLog.bak';
GO

-- Back up the full AdventureWorks database.
BACKUP DATABASE AdventureWorks TO AdvWorksData;
GO
-- Back up the AdventureWorks log.
BACKUP LOG AdventureWorks
   TO AdvWorksLog;
GO
ms186865.note(ru-ru,SQL.90).gifПримечание.
Следует регулярно создавать резервные копии журнала производственной базы данных. Такие резервные копии следует создавать достаточно часто, чтобы избежать потери данных.

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

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

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

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

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

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

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

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

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

Ж. Создание резервной копии на существующем зеркальном наборе носителей

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

BACKUP LOG AdventureWorks
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorksSet1'
ms186865.note(ru-ru,SQL.90).gifПримечание.
Параметр NOINIT, установленный по умолчанию, приведен здесь для ясности.

[В начало списка примеров]

См. также

Справочник

ALTER DATABASE (Transact-SQL)
DBCC SQLPERF (Transact-SQL)
RESTORE (Transact-SQL)
RESTORE FILELISTONLY (Transact-SQL)
Инструкция RESTORE HEADERONLY (Transact-SQL)
RESTORE LABELONLY (Transact-SQL)
RESTORE VERIFYONLY (Transact-SQL)
sp_addumpdevice (Transact-SQL)
Хранимая процедура sp_configure (Transact-SQL)
sp_helpfile (Transact-SQL)
sp_helpfilegroup (Transact-SQL)

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

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

Справка и поддержка

Получение помощи по SQL Server 2005

Журнал изменений

Версия Журнал

17 июля 2006 г.
Измененное содержимое
  • Реорганизованы разделы «Синтаксис» и «Аргументы». Связанные параметры были сгруппированы.
  • Расширено описание параметра MIRROR TO.
  • Внесены изменения в раздел «Виды резервных копий».
  • Добавлен раздел «Поддержка совместимости».
  • Внесены изменения в раздел «Работа с зеркальным набором носителей».
  • Добавлены примеры создания полной и разностной резервной копии файлов.

14 апреля 2006 г.
Добавления
  • В разделы «Синтаксис» и «Аргументы» добавлены параметры BUFFERCOUNT и MAXTRANSFERSIZE.
Измененное содержимое
  • Перечислены поддерживаемые размеры блоков и обновлено примечание о производительности в описании параметра BLOCKSIZE.
  • Обновлено описание параметров {REWIND | NOREWIND} и {UNLOAD | NOUNLOAD}.

5 декабря 2005 г.
Измененное содержимое
  • Уточнено описание параметров NO_LOG и TRUNCATE_ONLY.