BACKUP (Transact-SQL)

Backs up a complete database, or one or more files or filegroups (BACKUP DATABASE). Also, under the full
recovery model or bulk-logged recovery model, backs up the transaction log (BACKUP LOG).

Note

For an introduction to backup in SQL Server, see Backup Overview (SQL Server).
Transact-SQL Syntax Conventions

 Syntax
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 ] ]
[;]

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

--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
 Arguments
DATABASE
Specifies a complete database backup. If a list of files and filegroups is specified, only those files and
filegroups are backed up. During a full or differential database backup, SQL Server backs up enough of the
transaction log to produce a consistent database when the backup is restored.
 When you restore a backup created by BACKUP DATABASE (a data backup), the entire backup is restored.
Only a log backup can be restored to a specific time or transaction within the backup.

Note

Only a full database backup can be performed on the master database.

LOG
Specifies a backup of the transaction log only. The log is backed up from the last successfully executed log
backup to the current end of the log. Before you can create the first log backup, you must create a full
backup.

You can restore a log backup to a specific time or transaction within the backup by specifying WITH
STOPAT, STOPATMARK, or STOPBEFOREMARK in your RESTORE LOG statement.

Note

After a typical log backup, some transaction log records become inactive, unless you specify WITH
NO_TRUNCATE or COPY_ONLY. The log is truncated after all the records within one or more virtual log files
become inactive. If the log is not being truncated after routine log backups, something might be delaying log
truncation. For more information, see Managing the Transaction Log.
{ database_name| @database_name_var }
Is the database from which the transaction log, partial database, or complete database is backed up. If
supplied as a variable (@database_name_var), this name can be specified either as a string constant
(@database_name_var = database name) or as a variable of character string data type, except for the ntext or
text data types.

Note

The mirror database in a database mirroring partnership cannot be backed up.

<file_or_filegroup> [ ,...n ]
Used only with BACKUP DATABASE, specifies a database file or filegroup to include in a file backup, or
specifies a read-only file or filegroup to include in a partial backup.

FILE = { logical_file_name| @logical_file_name_var }

Is the logical name of a file or a variable whose value equates to the logical name of a file that is to be
included in the backup.

FILEGROUP = { logical_filegroup_name| @logical_filegroup_name_var }

Is the logical name of a filegroup or a variable whose value equates to the logical name of a filegroup that
is to be included in the backup. Under the simple recovery model, a filegroup backup is allowed only for a
read-only filegroup.

Note

Consider using file backups when the database size and performance requirements make a database backup
impractical.
n
Is a placeholder that indicates that multiple files and filegroups can be specified in a comma-separated
list. The number is unlimited.

For more information, see: Full File Backups and How to: Back Up Files and Filegroups (Transact-SQL).

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

Specifies a partial backup. A partial backup includes all the read/write files in a database: the primary
filegroup and any read/write secondary filegroups, and also any specified read-only files or filegroups.

READ_WRITE_FILEGROUPS
Specifies that all read/write filegroups be backed up in the partial backup. If the database is read-only,
READ_WRITE_FILEGROUPS includes only the primary filegroup.
 Important

Explicitly listing the read/write filegroups by using FILEGROUP instead of READ_WRITE_FILEGROUPS creates
a file backup.
FILEGROUP = { logical_filegroup_name| @logical_filegroup_name_var }
Is the logical name of a read-only filegroup or a variable whose value equates to the logical name of a
read-only filegroup that is to be included in the partial backup. For more information, see
"<file_or_filegroup>," earlier in this topic.

n
Is a placeholder that indicates that multiple read-only filegroups can be specified in a comma-separated
list.

For more information about partial backups, see Partial Backups.

TO <backup_device> [ ,...n ]
Indicates that the accompanying set of backup devices is either an unmirrored media set or the first of the
mirrors within a mirrored media set (for which one or more MIRROR TO clauses are declared).

<backup_device>
Specifies a logical or physical backup device to use for the backup operation.

{ logical_device_name | @logical_device_name_var }
Is the logical name of the backup device to which the database is backed up. The logical name must follow
the rules for identifiers. If supplied as a variable (@logical_device_name_var), the backup device name can be
specified either as a string constant (@logical_device_name_var = logical backup device name) or as a
variable of any character string data type except for the ntext or text data types.
{ DISK | TAPE } = { 'physical_device_name' | @physical_device_name_var }
Specifies a disk file or a tape device.

A disk device does not have to exist before it is specified in a BACKUP statement. If the physical device
exists and the INIT option is not specified in the BACKUP statement, the backup is appended to the
device.

For more information, see Backup Devices.

Note

The TAPE option will be removed in a future version of SQL Server. Avoid using this feature in new
development work, and plan to modify applications that currently use this feature.
n
Is a placeholder that indicates that up to 64 backup devices may be specified in a comma-separated list.

MIRROR TO <backup_device> [ ,...n ]

Specifies a set of up to three secondary backup devices, each of which will mirror the backups devices
specified in the TO clause. The MIRROR TO clause must be specify the same type and number of the
backup devices as the TO clause. The maximum number of MIRROR TO clauses is three.

This option is available only in SQL Server 2005 Enterprise Edition and later versions.

Note

For MIRROR TO = DISK, BACKUP automatically determines the appropriate block size for disk devices. For
more information about block size, see "BLOCKSIZE" later in this table.
<backup_device>
See "<backup_device>," earlier in this section.

n
Is a placeholder that indicates that up to 64 backup devices may be specified in a comma-separated list.
The number of devices in the MIRROR TO clause must equal the number of devices in the TO clause.
 For more information, see "Media Families in Mirrored Media Sets" in the "Remarks" section, later in this
topic.

[ next-mirror-to ]
Is a placeholder that indicates that a single BACKUP statement can contain up to three MIRROR TO
clauses, in addition to the single TO clause.

WITH Options
Specifies options to be used with a backup operation.

DIFFERENTIAL
Used only with BACKUP DATABASE, specifies that the database or file backup should consist only of the
portions of the database or file changed since the last full backup. A differential backup usually takes up
less space than a full backup. Use this option so that all individual log backups performed since the last
full backup do not have to be applied.

Note

By default, BACKUP DATABASE creates a full backup.

For more information, see Using Differential Backups.

Backup Set Options

These options operate on the backup set that is created by this backup operation.

Note

To specify a backup set for a restore operation, use the FILE = <backup_set_file_number> option. For more
information about how to specify a backup set, see "Specifying a Backup Set" in RESTORE Arguments
(Transact-SQL).
COPY_ONLY
Specifies that the backup is a copy-only backup, which does not affect the normal sequence of backups. A
copy-only backup is created independently of your regularly scheduled, conventional backups. A copy-only
backup does not affect your overall backup and restore procedures for the database.
Copy-only backups were introduced in SQL Server 2005 for use in situations in which a backup is taken for
a special purpose, such as backing up the log before an online file restore. Typically, a copy-only log
backup is used once and then deleted.

 When used with BACKUP DATABASE, the COPY_ONLY option creates a full backup that cannot
serve as a differential base. The differential bitmap is not updated, and differential backups
behave as if the copy-only backup does not exist. Subsequent differential backups use the most
recent conventional full backup as their base.

Important

If DIFFERENTIAL and COPY_ONLY are used together, COPY_ONLY is ignored, and a differential backup is
created.
 When used with BACKUP LOG, the COPY_ONLY option creates a copy-only log backup, which does
not truncate the transaction log. The copy-only log backup has no effect on the log chain, and
other log backups behave as if the copy-only backup does not exist.
For more information, see Copy-Only Backups.

{ COMPRESSION | NO_COMPRESSION }
Specifies whether backup compression is performed on this backup. Backup compression was introduced
in SQL Server 2008 Enterprise. Beginning in SQL Server 2008 R2, backup compression is supported by
SQL Server 2008 R2 Standard and all higher editions.

At installation, the default behavior is no backup compression. But this default can be changed by setting
the backup compression default server configuration option. For information about viewing the current
value of this option, see How to: View Server Properties (SQL Server Management Studio).
 COMPRESSION
Explicitly enables backup compression.

Note

By default, when a backup is compressed, checksums are performed to detect media corruptions.
NO_COMPRESSION
Explicitly disables backup compression.

DESCRIPTION = { 'text' | @text_variable }

Specifies the free-form text describing the backup set. The string can have a maximum of 255 characters.

NAME = { backup_set_name| @backup_set_var }

Specifies the name of the backup set. Names can have a maximum of 128 characters. If NAME is not
specified, it is blank.

PASSWORD = { password | @password_variable }

Sets the password for the backup set. PASSWORD is a character string.

Important

This feature will be removed in the next version of Microsoft SQL Server. Avoid using this feature in new
development work, and plan to modify applications that currently use this feature.
If a password is defined for the backup set, the password must be supplied to perform any SQL Server
restore operation from the backup set. A backup set password does not protect the backup file from being
overwritten, however. To prevent a backup file from being overwritten, use a media-set password instead
(see the MEDIAPASSWORD option later in this table). (For more information about using passwords, see
"Permissions," later in this topic.)

Security Note

The protection provided by this password is weak. It is intended to prevent an incorrect restore using SQL
Server tools by authorized or unauthorized users. It does not prevent the reading of the backup data by other
means or the replacement of the password. The best practice for protecting backups is to store backup tapes
in a secure location or back up to disk files that are protected by adequate access control lists (ACLs). The
ACLs should be set on the directory root under which backups are created.
{ EXPIREDATE = 'date'| RETAINDAYS = days }
Specifies when the backup set for this backup can be overwritten. If these options are both used,
RETAINDAYS takes precedence over EXPIREDATE.

If neither option is specified, the expiration date is determined by the media retention configuration
setting. For more information, see Setting Server Configuration Options.

Important

These options only prevent SQL Server from overwriting a file. Tapes can be erased using other methods, and
disk files can be deleted through the operating system. For more information about expiration verification,
see SKIP and FORMAT in this topic.
EXPIREDATE = { 'date'| @date_var }
Specifies when the backup set expires and can be overwritten. If supplied as a variable (@ date_var), this
date must follow the configured system datetime format and be specified as one of the following:
 A string constant (@date_var = date)
 A variable of character string data type (except for the ntext or text data types)

 A smalldatetime

 A datetime variable

For example:
  'Dec 31, 2020 11:59 PM'

 '1/1/2021'

For information about how to specify datetime values, see Using Date and Time Data.

Note

To ignore the expiration date, use the SKIP option.

RETAINDAYS = { days| @days_var }
Specifies the number of days that must elapse before this backup media set can be overwritten. If
supplied as a variable (@days_var), it must be specified as an integer.
Media Set Options

These options operate on the media set as a whole.

{ NOINIT | INIT }
Controls whether the backup operation appends to or overwrites the existing backup sets on the backup
media. The default is to append to the most recent backup set on the media (NOINIT).

Note

For information about the interactions between { NOINIT | INIT } and { NOSKIP | SKIP }, see "Remarks,"
later in this topic.
NOINIT
Indicates that the backup set is appended to the specified media set, preserving existing backup sets. If a
media password is defined for the media set, the password must be supplied. NOINIT is the default.

For more information, see Appending to Existing Backup Sets.

INIT
Specifies that all backup sets should be overwritten, but preserves the media header. If INIT is specified,
any existing backup set on that device is overwritten, if conditions permit. By default, BACKUP checks for
the following conditions and does not overwrite the backup media if either condition exists:

 Any backup set has not yet expired. For more information, see the EXPIREDATE and RETAINDAYS
options.

 The backup set name given in the BACKUP statement, if provided, does not match the name on
the backup media. For more information, see the NAME option, earlier in this section.

To override these checks, use the SKIP option.

Note

If the backup media is password protected, SQL Server does not write to the media unless the media
password is supplied. This check is not overridden by the SKIP option. Password-protected media may be
overwritten only by reformatting the media, which deletes the backups on the media. For information on the
media password, see "MEDIAPASSWORD", earlier in this topic. For information about reformatting media, see
"FORMAT", earlier in this topic.
For more information, see Overwriting Backup Sets.

{ NOSKIP | SKIP }
Controls whether a backup operation checks the expiration date and time of the backup sets on the media
before overwriting them.

Note

For information about the interactions between { NOINIT | INIT } and { NOSKIP | SKIP }, see "Remarks,"
 later in this topic.
NOSKIP
Instructs the BACKUP statement to check the expiration date of all backup sets on the media before
allowing them to be overwritten. This is the default behavior.

SKIP
Disables the checking of backup set expiration and name that is usually performed by the BACKUP
statement to prevent overwrites of backup sets. For information about the interactions between { INIT |
NOINIT } and { NOSKIP | SKIP }, see "Remarks," later in this topic.

To view the expiration dates of backup sets, query the expiration_date column of the backupset history
table.

{ NOFORMAT | FORMAT }
Specifies whether the media header should be written on the volumes used for this backup operation,
overwriting any existing media header and backup sets.

NOFORMAT
Specifies that the backup operation preserves the existing media header and backup sets on the media
volumes used for this backup operation. This is the default behavior.

FORMAT
Specifies that a new media set be created. FORMAT causes the backup operation to write a new media
header on all media volumes used for the backup operation. The existing contents of the volume become
invalid, because any existing media header and backup sets are overwritten.

Important

Use FORMAT carefully. Formatting any volume of a media set renders the entire media set unusable. For
example, if you initialize a single tape belonging to an existing striped media set, the entire media set is
rendered useless.
Specifying FORMAT implies SKIP; SKIP does not need to be explicitly stated.

MEDIADESCRIPTION = { text | @text_variable }

Specifies the free-form text description, maximum of 255 characters, of the media set.

MEDIANAME = { media_name | @media_name_variable }

Specifies the media name for the entire backup media set. The media name must be no longer than 128
characters, If MEDIANAME is specified, it must match the previously specified media name already
existing on the backup volumes. If it is not specified, or if the SKIP option is specified, there is no
verification check of the media name.

MEDIAPASSWORD = { mediapassword | @mediapassword_variable }

Sets the password for the media set. MEDIAPASSWORD is a character string.

Important

This feature will be removed in the next version of Microsoft SQL Server. Avoid using this feature in new
development work, and plan to modify applications that currently use this feature.
If a password is defined for the media set, the password must be supplied before you can create a backup
set on that media set. In addition, that media password also must be supplied to perform any restore
operation from the media set. Password-protected media may be overwritten only by reformatting. For
more information, see the FORMAT option. (For more information about using passwords, see the
Permissions section later in this topic.)

Security Note

The protection provided by this password is weak. It is intended to prevent an incorrect restore using SQL
Server tools by authorized or unauthorized users. It does not prevent the reading of the backup data by other
means or the replacement of the password. The best practice for protecting backups is to store backup tapes
in a secure location or back up to disk files that are protected by adequate access control lists (ACLs). The
ACLs should be set on the directory root under which backups are created.
BLOCKSIZE = { blocksize | @blocksize_variable }
Specifies the physical block size, in bytes. The supported sizes are 512, 1024, 2048, 4096, 8192, 16384,
32768, and 65536 (64 KB) bytes. The default is 65536 for tape devices and 512 otherwise. Typically, this
option is unnecessary because BACKUP automatically selects a block size that is appropriate to the device.
Explicitly stating a block size overrides the automatic selection of block size.

If you are taking a backup that you plan to copy onto and restore from a CD-ROM, specify
BLOCKSIZE=2048.

Note

This option typically affects performance only when writing to tape devices.
Data Transfer Options

BUFFERCOUNT = { buffercount | @buffercount_variable }

Specifies the total number of I/O buffers to be used for the backup operation. You can specify any positive
integer; however, large numbers of buffers might cause "out of memory" errors because of inadequate
virtual address space in the Sqlservr.exe process.

The total space used by the buffers is determined by: buffercount * maxtransfersize.
MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
Specifies the largest unit of transfer in bytes to be used between SQL Server and the backup media. The
possible values are multiples of 65536 bytes (64 KB) ranging up to 4194304 bytes (4 MB).

Error Management Options

These options allow you to determine whether backup checksums are enabled for the backup operation and
whether the operation will stop on encountering an error.

{ NO_CHECKSUM | CHECKSUM }
Controls whether backup checksums are enabled.

NO_CHECKSUM
Explicitly disables the generation of backup checksums (and the validation of page checksums). This is the
default behavior, except for a compressed backup.

CHECKSUM
Enables backup checksums, so that BACKUP can do the following:

1. Prior to writing a page to the backup media, BACKUP verifies the page (page checksum or torn
page), if this information is present on the page.

2. Regardless of whether page checksums are present, BACKUP generates a separate backup
checksum for the backup streams. Restore operations can optionally use the backup checksum to
validate that the backup is not corrupted. The backup checksum is stored on the backup media,
not on the database pages. The backup checksum can optionally be used at restore time,

Using backup checksums may affect workload and backup throughput.

This is the default behavior for a compressed backup.

{ STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
Controls whether a backup operation stops or continues after encountering a page checksum error.

STOP_ON_ERROR
Instructs BACKUP to fail if a page checksum does not verify. This is the default behavior.

CONTINUE_AFTER_ERROR
Instructs BACKUP to continue despite encountering errors such as invalid checksums or torn pages.

If you are unable to back up the tail of the log using the NO_TRUNCATE option when the database is
damaged, you can attempt a tail-log log backup by specifying CONTINUE_AFTER_ERROR instead of
NO_TRUNCATE.

Compatibility Options
RESTART
Has no effect. This option is accepted by the version for compatibility with previous versions of SQL
Server.

Monitoring Options

STATS [ =percentage ]
Displays a message each time another percentage completes, and is used to gauge progress. If percentage is
omitted, SQL Server displays a message after each 10 percent is completed.
The STATS option reports the percentage complete as of the threshold for reporting the next interval. This
is at approximately the specified percentage; for example, with STATS=10, if the amount completed is 40
percent, the option might display 43 percent. For large backup sets, this is not a problem, because the
percentage complete moves very slowly between completed I/O calls.

Tape Options

These options are used only for TAPE devices. If a nontape device is being used, these options are ignored.

{ REWIND | NOREWIND }
REWIND
Specifies that SQL Server will release and rewind the tape. REWIND is the default.

NOREWIND
Specifies that SQL Server will keep the tape open after the backup operation. You can use this option to
help improve performance when performing multiple backup operations to a tape.

NOREWIND implies NOUNLOAD, and these options are incompatible within a single BACKUP statement.

Note

If you use NOREWIND, the instance of SQL Server retains ownership of the tape drive until a BACKUP or
RESTORE statement that is running in the same process uses either the REWIND or UNLOAD option, or the
server instance is shut down. Keeping the tape open prevents other processes from accessing the tape. For
information about how to display a list of open tapes and to close an open tape, see Backup Devices.
{ UNLOAD | NOUNLOAD }

Note

UNLOAD/NOUNLOAD is a session setting that persists for the life of the session or until it is reset by
specifying the alternative.
UNLOAD
Specifies that the tape is automatically rewound and unloaded when the backup is finished. UNLOAD is the
default when a session begins.

NOUNLOAD
Specifies that after the BACKUP operation the tape will remain loaded on the tape drive.

Note

For a backup to a tape backup device, the BLOCKSIZE option to affect the performance of the backup
operation. This option typically affects performance only when writing to tape devices.
Log-specific Options

These options are only used with BACKUP LOG.

Note

If you do not want to take log backups, use the simple recovery model. For more information, see Backup
Under the Simple Recovery Model.
{ NORECOVERY | STANDBY =undo_file_name }
NORECOVERY
 Backs up the tail of the log and leaves the database in the RESTORING state. NORECOVERY is useful when
failing over to a secondary database or when saving the tail of the log before a RESTORE operation.

To perform a best-effort log backup that skips log truncation and then take the database into the
RESTORING state atomically, use the NO_TRUNCATE and NORECOVERY options together.

STANDBY =standby_file_name
Backs up the tail of the log and leaves the database in a read-only and STANDBY state. The STANDBY
clause writes standby data (performing rollback, but with the option of further restores). Using the
STANDBY option is equivalent to BACKUP LOG WITH NORECOVERY followed by a RESTORE WITH
STANDBY.

Using standby mode requires a standby file, specified by standby_file_name, whose location is stored in the
log of the database. If the specified file already exists, the Database Engine overwrites it; if the file does
not exist, the Database Engine creates it. The standby file becomes part of the database.
This file holds the rolled back changes, which must be reversed if RESTORE LOG operations are to be
subsequently applied. There must be enough disk space for the standby file to grow so that it can contain
all the distinct pages from the database that were modified by rolling back uncommitted transactions.

NO_TRUNCATE
Specifies that the log not be truncated and causes the Database Engine to attempt the backup regardless
of the state of the database. Consequently, a backup taken with NO_TRUNCATE might have incomplete
metadata. This option allows backing up the log in situations where the database is damaged.

The NO_TRUNCATE option of BACKUP LOG is equivalent to specifying both COPY_ONLY and
CONTINUE_AFTER_ERROR.

Without the NO_TRUNCATE option, the database must be in the ONLINE state. If the database is in the
SUSPENDED state, you might be able to create a backup by specifying NO_TRUNCATE. But if the database
is in the OFFLINE or EMERGENCY state, BACKUP is not allowed even with NO_TRUNCATE. For information
about database states, see Database States.

 Remarks
Database or log backups can be appended to any disk or tape device, allowing a database and its transaction logs
to be kept within one physical location.

The BACKUP statement is not allowed in an explicit or implicit transaction.

Cross-platform backup operations, even between different processor types, can be performed as long as the
collation of the database is supported by the operating system.

For information on backup terminology, backup devices, and managing backups, see Working with Backup Media in
SQL Server.

Note

By default, every successful backup operation adds an entry in the SQL Server error log and in the system
event log. If back up the log very frequently, these success messages accumulate quickly, resulting in huge
error logs that can make finding other messages difficult. In such cases you can suppress these log entries by
using trace flag 3226 if none of your scripts depend on those entries. For more information, see Trace Flags
(Transact-SQL).
Transaction Log Truncation
To avoid filling up the transaction log of a database, routine backups are essential. Under the simple recovery
model, log truncation occurs automatically after you back up the database, and under the full recovery model, after
you back up the transaction log. However, sometimes the truncation process can be delayed. For information about
identifying and responding to delaying factors, see Factors That Can Delay Log Truncation.

Note

The BACKUP LOG WITH NO_LOG and WITH TRUNCATE_ONLY options have been discontinued. If you are
using the full or bulk-logged recovery model recovery and you must remove the log backup chain from a
database, switch to the simple recovery model. For more information, see Considerations for Switching from
the Full or Bulk-Logged Recovery Model.
For more information about log truncation in general, see Transaction Log Truncation.
Concurrency
SQL Server uses an online backup process to allow a database backup while the database is still in use. During a
backup, most operations are possible; for example, INSERT, UPDATE, or DELETE statements are allowed during a
backup operation.

Operations that cannot run during a database or transaction log backup include:

 File management operations such as the ALTER DATABASE statement with either the ADD FILE or
REMOVE FILE options.

 Shrink database or shrink file operations. This includes auto-shrink operations.

If a backup operation overlaps with a file-management or shrink operation, a conflict arises. Regardless of which of
the conflicting operation began first, the second operation waits for the lock set by the first operation to time out
(the time-out period is controlled by a session timeout setting). If the lock is released during the time-out period,
the second operation continues. If the lock times out, the second operation fails.

Formatting Backup Media

Backup media is formatted by a BACKUP statement if and only if any of the following is true:

 The FORMAT option is specified.

 The media is empty.

 The operation is writing a continuation tape.

For more information, see Creating a New Media Set.

Backup Types
The supported backup types depend on the recovery model of the database, as follows

 All recovery models support full and differential backups of data.

Scope of
backup Backup types

Whole Database backups cover the whole database.

database Optionally, each database backup can serve as the base of a series of one or more differential
database backups.

Partial Partial backups cover read/-write filegroups and, possibly, one or more read-only files or
database filegroups.
Optionally, each partial backup can serve as the base of a series of one or more differential
partial backups.

File or File backups cover one or more files or filegroups, and are relevant only for databases that
filegroup contain multiple filegroups. Under the simple recovery model, file backups are essentially
restricted to read-only secondary filegroups.
Optionally, each file backup can serve as the base of a series of one or more differential file
backups.
 Under the full recovery model or bulk-logged recovery model, conventional backups also include
sequential transaction log backups (or log backups), which are required. Each log backup covers the portion of
the transaction log that was active when the backup was created, and it includes all log records not
backed up in a previous log backup.
To minimize work-loss exposure, at the cost of administrative overhead, you should schedule frequent log
backups. Scheduling differential backups between full backups can reduce restore time by reducing the
number of log backups you have to restore after restoring the data.

We recommend that you put log backups on a separate volume than the database backups.

Note
 Before you can create the first log backup, you must create a full backup.
For more information, see Working with Transaction Log Backups.

 A copy-only backup is a special-purpose full backup or log backup that is independent of the normal
sequence of conventional backups. To create a copy-only backup, specify the COPY_ONLY option in your
BACKUP statement. For more information, see Copy-Only Backups.
Interaction of SKIP, NOSKIP, INIT, and NOINIT
This table describes interactions between the { NOINIT | INIT } and { NOSKIP | SKIP } options.

Note

If the tape media is empty or the disk backup file does not exist, all these interactions write a media header
and proceed. If the media is not empty and lacks a valid media header, these operations give feedback
stating that this is not valid MTF media, and they terminate the backup operation.

  NOINIT INIT

NOSKIP If the volume contains a valid media header, If the volume contains a valid media header,
verifies the media password and verifies that the performs the following checks:
media name matches the given MEDIANAME, if  Verifies the media password.2
any. If it matches, appends the backup set,  If MEDIANAME was specified,
preserving all existing backup sets.
If the volume does not contain a valid media verifies that the given media name
header, an error occurs. matches the media header's media
name.
 Verifies that there are no
unexpired backup sets already on the
media.
If there are, terminates the backup.
If these checks pass, overwrites any backup
sets on the media, preserving only the media
header.
If the volume does not contain a valid media
header, generates one with using specified
MEDIANAME, MEDIAPASSWORD, and
MEDIADESCRIPTION, if any.

SKIP If the volume contains a valid media header, If the volume contains a valid1 media header,
verifies the media password and appends the verifies the media password and overwrites
backup set, preserving all existing backup sets. any backup sets on the media, preserving
only the media header.
If the media is empty, generates a media
header using the specified MEDIANAME,
MEDIAPASSWORD, and MEDIADESCRIPTION,
if any.
1
Validity includes the MTF version number and other header information. If the version specified is unsupported or
an unexpected value, an error occurs.
2
The user must belong to the appropriate fixed database or server roles and provide the correct media password
to perform a backup operation.

Backup History Tables

SQL Server includes the following backup history tables that track backup activity:

 backupfile (Transact-SQL)

 backupfilegroup (Transact-SQL)

 backupmediafamily (Transact-SQL)
  backupmediaset (Transact-SQL)

 backupset (Transact-SQL)

When a restore is performed, if the backup set was not already recorded in the msdb database, the backup history
tables might be modified.

Compatibility Support

Caution

Backups that are created by more recent version of SQL Server cannot be restored in earlier versions of SQL
Server.
BACKUP supports the RESTART option to provide backward compatibility with earlier versions of SQL Server. But
RESTART has no effect in SQL Server 2005 and later versions.

Backup Devices in a Striped Media Set (a Stripe Set)

A stripe set is a set of disk files on which data is divided into blocks and distributed in a fixed order. The number of
backup devices used in a stripe set must stay the same (unless the media is reinitialized with FORMAT).
The following example writes a backup of the AdventureWorks2008R2 database to a new striped media set that
uses three disk files.

Copy Code
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
After a backup device is defined as part of a stripe set, it cannot be used for a single-device backup unless FORMAT
is specified. Similarly, a backup device that contains nonstriped backups cannot be used in a stripe set unless
FORMAT is specified. To split a striped backup set, use FORMAT.

If neither MEDIANAME nor MEDIADESCRIPTION is specified when a media header is written, the media header field
corresponding to the blank item is empty.

Working with a Mirrored Media Set

Typically, backups are unmirrored, and BACKUP statements simply include a TO clause. However, a total of four
mirrors is possible per media set. For a mirrored media set, the backup operation writes to multiple groups of
backup devices. Each group of backup devices comprises a single mirror within the mirrored media set. Every
mirror must use the same quantity and type of physical backup devices, which must all have the same properties.

To back up to a mirrored media set, all of the mirrors must be present. To back up to a mirrored media set, specify
the TO clause to specify the first mirror, and specify a MIRROR TO clause for each additional mirror.

For a mirrored media set, each MIRROR TO clause must list the same number and type of devices as the TO
clause. The following example writes to a mirrored media set that contains two mirrors and uses three devices per
mirror:

Copy Code
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
 Important

This example is designed to allow you to test it on your local system. In practice, backing up to multiple
devices on the same drive would hurt performance and would eliminate the redundancy for which mirrored
media sets are designed.
Media Families in Mirrored Media Sets
Each backup device specified in the TO clause of a BACKUP statement corresponds to a media family. For example,
if the TO clauses lists three devices, BACKUP writes data to three media families. In a mirrored media set, every
mirror must contain a copy of every media family. This is why the number of devices must be identical in every
mirror.

When multiple devices are listed for each mirror, the order of the devices determines which media family is written
to a particular device. For example, in each of the device lists, the second device corresponds to the second media
family. For the devices in the above example, the correspondence between devices and media families is shown in
the following table.

Mirro
r Media family 1 Media family 2 Media family 3

0 Z:\AdventureWorks2008R2_1 Z:\AdventureWorks2008R2_2 Z:\AdventureWorks2008R2_3

a.bak a.bak a.bak

1 Z:\AdventureWorks2008R2_1 Z:\AdventureWorks2008R2_2 Z:\AdventureWorks2008R2_3

b.bak b.bak b.bak
A media family must always be backed up onto the same device within a specific mirror. Therefore, each time you
use an existing media set, list the devices of each mirror in the same order as they were specified when the media
set was created.

For more information about mirrored media sets, see Using Mirrored Backup Media Sets. For more information
about media sets and media families in general, see Media Sets, Media Families, and Backup Sets.

 Permissions
BACKUP DATABASE and BACKUP LOG permissions default to members of the sysadmin fixed server role and the
db_owner and db_backupoperator fixed database roles.

In addition, the user may specify passwords for a media set, a backup set, or both. When a password is defined on
a media set, the user also must supply the media password to perform these operations. Similarly, restore is not
allowed unless the correct media password and backup set password are specified in the restore command.

Defining passwords for backup sets and media sets is an optional feature in the BACKUP statement. The protection
provided by this password is weak. It is intended to prevent an incorrect restore using SQL Server tools by
authorized or unauthorized users. It does not prevent the reading of the backup data by other means or the
replacement of the password. Also, passwords do not prevent overwrite of media with the FORMAT option. We
recommend using strong passwords. For information about strong passwords, see Strong Passwords.

Therefore, although the use of passwords can help protect the contents of media from unauthorized access using
SQL Server tools, passwords do not protect contents from being destroyed. Passwords do not fully prevent
unauthorized access to the contents of the media because the data in the backup sets is not encrypted and could
theoretically be examined by programs specifically created for this purpose. For situations where security is crucial,
it is important to prevent physical access to the media by unauthorized individuals.

It is an error to specify a password for objects that were not created with associated passwords.

BACKUP creates the backup set with the backup set password supplied through the PASSWORD option. In addition,
BACKUP will normally verify the media password given by the MEDIAPASSWORD option before writing to the
media. The only time that BACKUP will not verify the media password is when it formats the media, which
overwrites the media header. If BACKUP writes the media header, BACKUP will assign the media set password to
the value specified in the MEDIAPASSWORD option.

For information about the impact of passwords on SKIP, NOSKIP, INIT, and NOINIT options, see "Remarks," later
in this topic.

Ownership and permission problems on the backup device's physical file can interfere with a backup operation. SQL
Server must be able to read and write to the device; the account under which the SQL Server service runs must
have write permissions. However, sp_addumpdevice, which adds an entry for a backup device in the system tables,
does not check file access permissions. Such problems on the backup device's physical file may not appear until the
physical resource is accessed when the backup or restore is attempted.

 Examples

Note

The AdventureWorks2008R2 database is shown for illustration. AdventureWorks2008R2 is one of the sample
databases in SQL Server 2005. Adventure Works Cycles is a fictional manufacturing company used to
demonstrate database concepts and scenarios. For more information about this database, see
AdventureWorks2008R2 Sample Databases.
This section contains the following examples:

 A. Backing up a complete database

 B. Backing up the database and log

 C. Creating a full file backup of the secondary filegroups

 D. Creating a differential file backup of the secondary filegroups

 E. Creating and backing up to a single-family mirrored media set

 F. Creating and backing up to a multifamily mirrored media set

 G. Backing up to an existing mirrored media set

 H. Creating a compressed backup in a new media set

Note

The backup how-to topics contain additional examples. For more information, see Backing Up and Restoring
How-to Topics (Transact-SQL).
A. Backing up a complete database
The following example backs up the AdventureWorks2008R2 database to a disk file.

Copy Code
BACKUP DATABASE AdventureWorks2008R2
TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
WITH FORMAT;
GO
B. Backing up the database and log
The following example backups up the AdventureWorks2008R2 sample database, which uses the simple recovery
model by default. To support log backups, the AdventureWorks2008R2 database is modified to use the full
recovery model.

Next, the example uses sp_addumpdevice to create a logical backup device for backing up data, AdvWorksData,
and creates another logical backup device for backing up the log, AdvWorksLog.

The example then creates a full database backup to AdvWorksData, and after a period of update activity, backs up
the log to AdvWorksLog.

Copy Code
-- 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
Note

For a production database, back up the log regularly. Log backups should be frequent enough to provide
sufficient protection against data loss.
C. Creating a full file backup of the secondary filegroups
The following example creates a full file backup of every file in both of the secondary filegroups.

Copy Code
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
GO
D. Creating a differential file backup of the secondary filegroups
The following example creates a differential file backup of every file in both of the secondary filegroups.

Copy Code
--Back up the files in SalesGroup1:
BACKUP DATABASE Sales
FILEGROUP = 'SalesGroup1',
FILEGROUP = 'SalesGroup2'
TO DISK = 'Z:\SQLServerBackups\SalesFiles.bck'
WITH
DIFFERENTIAL
GO
E. Creating and backing up to a single-family mirrored media set
The following example creates a mirrored media set containing a single media family and four mirrors and backs up
the AdventureWorks2008R2 database to them.

Copy Code
BACKUP DATABASE AdventureWorks2008R2
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorks2008R2Set0'
F. Creating and backing up to a multifamily mirrored media set
The following example creates a mirrored media set in which each mirror consists of two media families. The
example then backs up the AdventureWorks2008R2 database to both mirrors.

Copy Code
BACKUP DATABASE AdventureWorks2008R2
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorks2008R2Set1'
G. Backing up to an existing mirrored media set
The following example appends a backup set to the media set created in the preceding example.

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

NOINIT, which is the default, is shown here for clarity.

[Top of examples]

H. Creating a compressed backup in a new media set

The following example formats the media, creating a new media set, and perform a compressed full backup of the
AdventureWorks2008R2 database.

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