BACKUP (Transact-SQL)

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

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

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

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

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

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

Примечание
Чтобы задать резервный набор данных для операции восстановления, используйте параметр FILE =<backup_set_file_number>. Дополнительные сведения об указании резервного набора данных см. в подразделе «Указание резервного набора данных» раздела Аргументы инструкции RESTORE (Transact-SQL).

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

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

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

    Важно!
    Если параметры DIFFERENTIAL и COPY_ONLY используются вместе, то параметр COPY_ONLY не учитывается и создается разностная резервная копия.

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

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

• { COMPRESSION | NO_COMPRESSION }
  Указывает, используется ли сжатие данной резервной копии. Сжатие резервных копий было впервые представлено в выпуске SQL Server 2008 Enterprise. Начиная с версии SQL Server 2008 R2, сжатие резервных копий поддерживается в выпуске SQL Server 2008 R2 Standard Edition и всех выпусках с более широкими возможностями.

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

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

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

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

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

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

• PASSWORD = { password | **@**password_variable }
  Устанавливает пароль на резервный набор данных. PASSWORD является символьной строкой.

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

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

  Примечание по безопасности

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

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

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

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

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

    • строковая константа (@date_var = дата);

    • переменная типа символьной строки (за исключением типов данных ntext или text);

    • smalldatetime;

    • Переменная типа datetime.

    Примеры.

    • 'Dec 31, 2020 11:59 PM'

    • '1/1/2021'

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

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

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

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

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

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

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

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

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

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

    • Срок действия какого-либо резервного набора данных еще не истек. Дополнительные сведения см. в описании параметров EXPIREDATE и RETAINDAYS.

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

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

    Примечание

    Если носитель резервных копий защищен паролем, то SQL Server не записывает на носитель до тех пор, пока не предоставлен пароль носителя. Эта проверка не отменяется параметром SKIP. На носителе, защищенном паролем, перезапись возможна только путем форматирования, которое стирает резервные копии на носителе. Дополнительные сведения о паролях носителя см. в описании параметра «MEDIAPASSWORD», приведенном выше в данном разделе. Дополнительные сведения о форматировании носителей см. в описании инструкции «FORMAT», приведенном выше в данном разделе.

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

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

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

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

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

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

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

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

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

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

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

• MEDIADESCRIPTION = { text | **@**text_variable }
  Указывает произвольное текстовое описание набора носителей, длина которого не должна превышать 255 символов.

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

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

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

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

  Примечание по безопасности

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

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

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

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

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

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

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

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

    Примечание

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

• { UNLOAD | NOUNLOAD }

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

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

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

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

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

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

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

• { 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 база данных должна находиться в режиме ONLINE. Если база данных находится в состоянии SUSPENDED, то будет возможно создать резервную копию, указав параметр NO_TRUNCATE. Но если база данных находится в состоянии OFFLINE или EMERGENCY, то инструкция BACKUP не разрешена даже с параметром NO_TRUNCATE. Дополнительные сведения о состояниях баз данных см. в разделе Состояния базы данных.

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

Примечание

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

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

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

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

• Операции управления файлами, такие как инструкция ALTER DATABASE либо с параметром ADD FILE, либо с параметром REMOVE FILE.

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

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

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

• указан параметр FORMAT;

• носитель пуст;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• backupfile (Transact-SQL)

• backupfilegroup (Transact-SQL)

• backupmediafamily (Transact-SQL)

• backupmediaset (Transact-SQL)

• backupset (Transact-SQL)

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

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

Инструкция BACKUP поддерживает параметр RESTART для предоставления обратной совместимости с более ранними версиями SQL Server. Но параметр RESTART не работает в SQL Server 2005 и более поздних версиях.

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

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

BACKUP DATABASE AdventureWorks2008R2
TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3.bak'
WITH FORMAT,
   MEDIANAME = 'AdventureWorks2008R2StripedSet0',
   MEDIADESCRIPTION = 'Striped media set for AdventureWorks2008R2 database;
GO

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

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

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

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

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

BACKUP DATABASE AdventureWorks2008R2
TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1a.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2a.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3a.bak'
MIRROR TO DISK='X:\SQLServerBackups\AdventureWorks2008R2_1b.bak', 
DISK='Y:\SQLServerBackups\AdventureWorks2008R2_2b.bak', 
DISK='Z:\SQLServerBackups\AdventureWorks2008R2_3b.bak';
GO

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

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

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

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

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

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

-- Back up the full AdventureWorks2008R2 database.
BACKUP DATABASE AdventureWorks2008R2 TO AdvWorksData;
GO
-- Back up the AdventureWorks2008R2 log.
BACKUP LOG AdventureWorks2008R2
   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

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

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

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

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

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

BACKUP LOG AdventureWorks2008R2
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH 
   NOINIT,
   MEDIANAME = 'AdventureWorks2008R2Set1'

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

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

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

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

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