--Backing Up a Whole Database

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

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

BACKUPDATABASE { 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)

BACKUPLOG
{ 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
| URL } =
{ 'physical_device_name' | @physical_device_name_var | 'NUL' }
}

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

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

<read_only_filegroup>::=
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
<general_WITH_options> [ ,...n ]::=
--Backup Set Options
COPY_ONLY
| { COMPRESSION | NO_COMPRESSION }
| DESCRIPTION = { 'text' | @text_variable }
| NAME = { backup_set_name | @backup_set_name_var }
| CREDENTIAL
| ENCRYPTION
| FILE_SNAPSHOT
| { EXPIREDATE = { 'date' | @date_var }
| RETAINDAYS = { days | @days_var } }

--Media Set Options

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

--Data Transfer Options

BUFFERCOUNT = { buffercount | @buffercount_variable }
| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options

{ NO_CHECKSUM | CHECKSUM }
| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }

--Compatibility Options
RESTART

--Monitoring Options
STATS [ = percentage ]

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

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

--Encryption Options
ENCRYPTION (ALGORITHM = { AES_128 | AES_192 | AES_256 | TRIPLE_DES_3KEY } ,
encryptor_options ) <encryptor_options> ::=
SERVER CERTIFICATE = Encryptor_Name | SERVER ASYMMETRIC KEY = Encryptor_Name
BACKUP (Transact-SQL)
Backs up a complete SQL Server database to create a database backup, or one or more
files or filegroups of the database to create a file backup (BACKUP DATABASE). Also,
under the full recovery model or bulk-logged recovery model, backs up the transaction
log of the database to create a log backup (BACKUP LOG).
Syntax
SQLCopy
--Backing Up a Whole Database
BACKUPDATABASE { 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

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

BACKUPDATABASE { 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)

BACKUPLOG
{ 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
| URL } =
{ 'physical_device_name' | @physical_device_name_var | 'NUL' }
}

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

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

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

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

--Backup Set Options
COPY_ONLY
| { COMPRESSION | NO_COMPRESSION }
| DESCRIPTION = { 'text' | @text_variable }
| NAME = { backup_set_name | @backup_set_name_var }
| CREDENTIAL
| ENCRYPTION
| FILE_SNAPSHOT
| { EXPIREDATE = { 'date' | @date_var }
| RETAINDAYS = { days | @days_var } }

--Media Set Options

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

--Data Transfer Options

BUFFERCOUNT = { buffercount | @buffercount_variable }
| MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }

--Error Management Options

{ NO_CHECKSUM | CHECKSUM }
| { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
--Compatibility Options
RESTART

--Monitoring Options
STATS [ = percentage ]

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

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

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

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 Factors that can delay log truncation.

{ 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. The NUL device can be used to test the
performance of backups, but should not be used in production environments.

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 Back Up Files and Filegroups.
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 } Applies to: SQL Server 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 | URL} = { 'physical_device_name' | @physical_device_name_var |

'NUL' } Applies to: DISK, TAPE, and URL apply to SQL Server. Specifies a disk file or tape
device, or a Microsoft Azure Blob storage service. The URL format is used for creating
backups to the Microsoft Azure storage service. For more information and examples,
see SQL Server Backup and Restore with Microsoft Azure Blob Storage Service. For a
tutorial, see Tutorial: SQL Server Backup and Restore to Microsoft Azure Blob Storage
Service.
Note

The NUL disk device will discard all information sent to it and should only be used for
testing. This is not for production use.
Important

Starting with SQL Server 2012 (11.x) SP1 CU2 through SQL Server 2014 (12.x), you can
only backup to a single device when backing up to URL. In order to backup to multiple
devices when backing up to URL, you must use SQL Server 2016 (13.x) through SQL
Server 2017 and you must use Shared Access Signature (SAS) tokens. For examples
creating a Shared Access Signature, see SQL Server Backup to URL and Simplifying
creation of SQL Credentials with Shared Access Signature (SAS) tokens on Azure
Storage with Powershell.

URL applies to: SQL Server ( SQL Server 2012 (11.x) SP1 CU2 through SQL Server 2017).

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

The NUL device will discard all input sent to this file, however the backup will still mark
all pages as backed up.

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 mirrors the backups devices specified in the TO clause. The
MIRROR TO clause must 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 the Enterprise edition of SQL Server.

Note

For MIRROR TO = DISK, BACKUP automatically determines the appropriate block size
for disk devices based on the sector size of the disk. If the MIRROR TO disk is formatted
with a different sector size than the disk specified as the primary backup device, the
backup command will fail. In order to mirror backups to devices that have different
sector sizes, the BLOCKSIZE parameter must be specified, and should be set to the
highest sector size amongst all the target devices. For more information about block
size, see "BLOCKSIZE" later in this topic.

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

CREDENTIAL Applies to: SQL Server ( SQL Server 2012 (11.x) SP1 CU2 through SQL
Server 2017). Used only when creating a backup to the Microsoft Azure Blob storage
service.

FILE_SNAPSHOT Applies to: SQL Server ( SQL Server 2016 (13.x) through SQL Server
2017).

Used to create an Azure snapshot of the database files when all of the SQL Server
database files are stored using the Azure Blob storage service. For more information,
see SQL Server Data Files in Microsoft Azure. SQL Server Snapshot Backup takes Azure
snapshots of the database files (data and log files) at a consistent state. A consistent set
of Azure snapshots make up a backup and are recorded in the backup file. The only
difference between BACKUP DATABASE TO URL WITH FILE_SNAPSHOT and BACKUP LOG TO
URL WITH FILE_SNAPSHOT is that the latter also truncates the transaction log while the
former does not. With SQL Server Snapshot Backup, after the initial full backup that is
required by SQL Server to establish the backup chain, only a single transaction log
backup is required to restore a database to the point in time of the transaction log
backup. Furthermore, only two transaction log backups are required to restore a
database to a point in time between the time of the two transaction log backups.

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 Differential Backups.

ENCRYPTION Used to specify encryption for a backup. You can specify an encryption
algorithm to encrypt the backup with or specify NO_ENCRYPTION to not have the backup
encrypted. Encryption is recommended practice to help secure backup files. The list of
algorithms you can specify are:

 AES_128
 AES_192
 AES_256
 TRIPLE_DES_3KEY
 NO_ENCRYPTION

If you choose to encrypt you will also have to specify the encryptor using the encryptor
options:

 SERVER CERTIFICATE = Encryptor_Name

 SERVER ASYMMETRIC KEY = Encryptor_Name

Warning

When encryption is used in conjunction with the FILE_SNAPSHOT argument, the metadata
file itself is encrypted using the specified encryption algorithm and the system verifies
that Transparent Data Encryption (TDE) was completed for the database. No
additional encryption happens for the data itself. The backup fails if the database was
not encrypted or if the encryption was not completed before the backup statement was
issued.

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.

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 should be used 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 } In SQL Server 2008 Enterprise and later versions
only, specifies whether backup compression is performed on this backup, overriding the
server-level default.

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 View or Change Server
Properties.

For information about using backup compression with Transparent Data Encryption
(TDE) enabled databases, see the Remarks section.

COMPRESSION Explicitly enables backup compression.

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.

{ 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 mediaretention configuration setting. For more information, see 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 Date and Time Types.
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 Media Sets, Media Families, and 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.

For more information, see Media Sets, Media Families, and 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.

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.

Note

For important information about using the BUFFERCOUNT option, see the Incorrect
BufferCount data transfer option can lead to OOM condition blog.

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).
Note
When creating backups by using the SQL Writer Service, if the database has
configured FILESTREAM, or includes memory optimized filegroups, then
the MAXTRANSFERSIZE at the time of a restore should be greater than or equal to
the MAXTRANSFERSIZE that was used when the backup was created.
Note

For Transparent Data Encryption (TDE) enabled databases with a single data file, the
default MAXTRANSFERSIZE is 65536 (64 KB). For non-TDE encrypted databases the
default MAXTRANSFERSIZE is 1048576 (1 MB) when using backup to DISK, and 65536 (64
KB) when using VDI or TAPE. For more information about using backup compression
with TDE encrypted databases, see the Remarks section.

Error Management Options

These options allow you to determine whether backup checksums are enabled for the
backup operation and whether the operation stops 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.

CHECKSUM Specifies that the backup operation verifies each page for checksum and
torn page, if enabled and available, and generate a checksum for the entire backup.

Using backup checksums may affect workload and backup throughput.

For more information, see Possible Media Errors During Backup and Restore.

{ 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.
For more information, see Possible Media Errors During Backup and Restore.

Compatibility Options

RESTART Beginning with SQL Server 2008, 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 releases and rewinds 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 and NOUNLOAD are session settings that persist 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 remains 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 Recovery Models.

{ 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 is log not 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.
About working with SQL Server backups
This section introduces the following essential backup concepts:

Backup Types Transaction Log Truncation Formatting Backup Media Working with
Backup Devices and Media Sets Restoring SQL Server Backups
Note

For an introduction to backup in SQL Server, see Backup Overview.

 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.
  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.
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
factors that can delay log truncation, see The Transaction Log.
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 View or Change the Recovery Model of a Database.
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.

Working with backup devices and media sets

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 AdventureWorks2012 database to a new

striped media set that uses three disk files.
SQLCopy
BACKUPDATABASE AdventureWorks2012
TO DISK='X:\SQLServerBackups\AdventureWorks1.bak',
DISK='Y:\SQLServerBackups\AdventureWorks2.bak',
DISK='Z:\SQLServerBackups\AdventureWorks3.bak'
WITHFORMAT,
 MEDIANAME = 'AdventureWorksStripedSet0',
MEDIADESCRIPTION = 'Striped media set for AdventureWorks2012 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 or 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:
SQLCopy
BACKUPDATABASE AdventureWorks2012
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
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.
Mirror Media family 1 Media family 2 Media family 3

0 Z:\AdventureWorks1a.bak Z:\AdventureWorks2a.bak Z:\AdventureWorks3a.bak

1 Z:\AdventureWorks1b.bak Z:\AdventureWorks2b.bak Z:\AdventureWorks3b.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 Mirrored Backup Media Sets. For
more information about media sets and media families in general, see Media Sets,
Media Families, and Backup Sets.
Restoring SQL Server backups

To restore a database and, optionally, recover it to bring it online, or to restore a file or

filegroup, use either the Transact-SQL RESTORE statement or the SQL Server
Management Studio Restore tasks. For more information see Restore and Recovery
Overview.
Additional considerations about BACKUP options
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
 NOINIT INIT

NOSKI If the volume contains a valid If the volume contains a valid media header,
P media header, verifies that the performs the following checks:
media name matches the
given MEDIANAME, if any. If it
matches, appends the backup  If MEDIANAME was specified, verifies that the
set, preserving all existing given media name matches the media header's
backup sets. media name. 1

If the volume does not contain a  Verifies that there are no unexpired backup sets
valid media header, an error already on the media. If there are, terminates
occurs. 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 and MEDIADESCRIPTION, if any.

SKIP If the volume contains a valid If the volume contains a valid media header,
2

media header, appends the overwrites any backup sets on the media, preserving
backup set, preserving all only the media header.
existing backup sets. If the media is empty, generates a media header using
the specified MEDIANAME and MEDIADESCRIPTION, if
any.

they terminate the backup operation.

1
The user must belong to the appropriate fixed database or server roles to perform a
backup operation.

2
Validity includes the MTF version number and other header information. If the version
specified is unsupported or an unexpected value, an error occurs.
Compatibility
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.
General 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.

When using backup compression with Transparent Data Encryption (TDE) enabled
databases with a single data file, it is recommended to use
a MAXTRANSFERSIZE setting larger than 65536 (64 KB). Starting with SQL Server 2016
(13.x), this enables an optimized compression algorithm for TDE encrypted databases
that first decrypts a page, compresses it and then encrypts it again. If
using MAXTRANSFERSIZE = 65536 (64 KB), backup compression with TDE encrypted
databases directly compresses the encrypted pages, and may not yield good
compression ratios. For more information, see Backup Compression for TDE-enabled
Databases.
Note

There are some cases where the default MAXTRANSFERSIZE is greater than 64K:

 When the database has multiple data files created, it uses MAXTRANSFERSIZE > 64K
 When performing backup to URL, the default MAXTRANSFERSIZE = 1048576 (1MB)

Even if one of these conditions applies, you must explicitly set MAXTRANSFERSIZE greater
than 64K in your backup command in order to get the new backup compression
algorithm.

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.
Interoperability
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.
Metadata
SQL Server includes the following backup history tables that track backup activity:

 backupfile
 backupfilegroup
 backupmediafamily
 backupmediaset
 backupset

When a restore is performed, if the backup set was not already recorded in
the msdb database, the backup history tables might be modified.
Security
Beginning with SQL Server 2012 (11.x), the PASSWORD and MEDIAPASSWORD options are
discontinued for creating backups. It is still possible to restore backups created with
passwords.
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.

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
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
 I. Backing up to the Microsoft Azure Blob storage service

Note

The backup how-to topics contain additional examples. For more information,
see Backup Overview.
A. Backing up a complete database

The following example backs up the AdventureWorks2012 database to a disk file.

SQLCopy
BACKUPDATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdvWorksData.bak'
WITHFORMAT;
GO
B. Backing up the database and log

The following example backups up the AdventureWorks2012 sample database, which

uses the simple recovery model by default. To support log backups,
the AdventureWorks2012 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.
SQLCopy
-- To permit log backups, before the full database backup, modify the database
-- to use the full recovery model.
USEmaster;
GO
ALTERDATABASE AdventureWorks2012
SETRECOVERYFULL;
GO
-- Create AdvWorksData and AdvWorksLog logical backup devices.
USEmaster
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 AdventureWorks2012 database.

BACKUPDATABASE AdventureWorks2012 TO AdvWorksData;
GO
-- Back up the AdventureWorks2012 log.
BACKUPLOG AdventureWorks2012
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.
SQLCopy
--Back up the files in SalesGroup1:
BACKUPDATABASE 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.
SQLCopy
--Back up the files in SalesGroup1:
BACKUPDATABASE 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 AdventureWorks2012 database to them.
SQLCopy
BACKUPDATABASE AdventureWorks2012
TO TAPE = '\\.\tape0'
MIRROR TO TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2'
MIRROR TO TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet0';
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 AdventureWorks2012 database to both
mirrors.
SQLCopy
BACKUPDATABASE AdventureWorks2012
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
FORMAT,
MEDIANAME = 'AdventureWorksSet1';
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.
SQLCopy
BACKUPLOG AdventureWorks2012
TO TAPE = '\\.\tape0', TAPE = '\\.\tape1'
MIRROR TO TAPE = '\\.\tape2', TAPE = '\\.\tape3'
WITH
NOINIT,
MEDIANAME = 'AdventureWorksSet1';
Note

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

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 AdventureWorks2012 database.
SQLCopy
BACKUPDATABASE AdventureWorks2012 TO DISK='Z:\SQLServerBackups\
AdvWorksData.bak'
WITH
FORMAT,
COMPRESSION;
I. Backing up to the Microsoft Azure Blob storage service

The example performs a full database backup of Sales to the Microsoft Azure Blob
storage service. The storage Account name is mystorageaccount. The container is
called myfirstcontainer. A stored access policy has been created with read, write,
delete, and list rights. The SQL Server
credential, https://mystorageaccount.blob.core.windows.net/myfirstcontainer, was
created using a Shared Access Signature that is associated with the Stored Access Policy.
For information on SQL Server backup to the Microsoft Azure Blob storage service,
see SQL Server Backup and Restore with Microsoft Azure Blob Storage Service and SQL
Server Backup to URL.
SQLCopy
BACKUPDATABASE Sales
TOURL =
'https://mystorageaccount.blob.core.windows.net/myfirstcontainer/Sales_2016072
6.bak'
WITH STATS = 5;

Backup Devices (SQL Server)

During a backup operation on a SQL Server database, the backed up data (the backup)
is written to a physical backup device. This physical backup device is initialized when the
first backup in a media set is written to it. Backups on a set of one or more backup
devices compose a single media set.
Terms and definitions
backup disk
A hard disk or other disk storage media that contains one or more backup files. A
backup file is a regular operating system file.

media set
An ordered collection of backup media, tapes or disk files, that uses a fixed type and
number of backup devices. For more information about media sets, see Media Sets,
Media Families, and Backup Sets (SQL Server).

physical backup device

Either a tape drive or a disk file that is provided by the operating system. A backup can
be written to from 1 to 64 backup devices. If a backup requires multiple backup devices,
the devices all must correspond to a single type of device (disk or tape).

SQL Server Backups can also be written to Windows Azure Blob storage service in
addition to disk or tape.
Using disk backup devices
If a disk file fills while a backup operation is appending a backup to the media set, the
backup operation fails. The maximum size of a backup file is determined by the free disk
space available on the disk device; therefore, the appropriate size for a backup disk
device depends on the size of your backups.

A disk backup device could be a simple disk device, such as an ATA drive. Alternatively,
you could use a hot-swappable disk drive that would let you transparently replace a full
disk on the drive with an empty disk. A backup disk can be a local disk on the server or a
remote disk that is a shared network resource. For information about how to use a
remote disk, see Backing Up to a File on a Network Share, later in this topic.

SQL Server management tools are very flexible at handling disk backup devices because
they automatically generate a time-stamped name on the disk file.
IMPORTANT! We recommend that a backup disk be a different disk than the database
data and log disks. This is necessary to make sure that you can access the backups if the
data or log disk fails.

If database files and backup files are on the same device and the device fails, the
database and backups will be unavailable. Also, putting the database and backup files
on the separate devices optimizes the I/O performance for both the production use of
the database and the writing of backups.
Specify a backup file using its physical name (Transact-
SQL)
The basic BACKUP syntax for specifying a backup file by using its physical device name
is:

BACKUP DATABASE database_name

TO DISK = { 'physical_backup_device_name' | @physical_backup_device_name_var }

For example:
SQLCopy

BACKUPDATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak';
GO

To specify a physical disk device in a RESTORE statement, the basic syntax is:

RESTORE { DATABASE | LOG } database_name

FROM DISK = { 'physical_backup_device_name' | @physical_backup_device_name_var }

For example,
SQLCopy

RESTOREDATABASE AdventureWorks2012
FROM DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak';

Specify the disk backup file path

When you are specifying a backup file, you should enter its full path and file name. If
you specify only the file name or a relative path when you are backing up to a file, the
backup file is put in the default backup directory. The default backup directory is C:\
Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Backup, where n is the number of
the server instance. Therefore, for the default server instance, the default backup
directory is: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\
Backup.

To avoid ambiguity, especially in scripts, we recommend that you explicitly specify the
path of the backup directory in every DISK clause. However, this is less important when
you are using Query Editor. In that case, if you are sure that the backup file resides in
the default backup directory, you can omit the path from a DISK clause. For example,
the following BACKUP statement backs up the AdventureWorks2012 database to the
default backup directory.
SQLCopy

BACKUPDATABASE AdventureWorks2012
TO DISK = 'AdventureWorks2012.bak';
GO

NOTE: The default location is stored in the BackupDirectory registry key

under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\
MSSQL.n\MSSQLServer.
Back up to a network share file

For SQL Server to access a remote disk file, the SQL Server service account must have
access to the network share. This includes having the permissions needed for backup
operations to write to the network share and for restore operations to read from it. The
availability of network drives and permissions depends on the context is which SQL
Server service is running:

 To back up to a network drive when SQL Server is running in a domain user

account, the shared drive must be mapped as a network drive in the session where
SQL Server is running. If you start Sqlservr.exe from command line, SQL Server sees
any network drives you have mapped in your login session.

 When you run Sqlservr.exe as a service, SQL Server runs in a separate session that
has no relation to your login session. The session in which a service runs can have
its own mapped drives, although it usually does not.

 You can connect with the network service account by using the computer account
instead of a domain user. To enable backups from specific computers to a shared
drive, grant access to the computer accounts. As long as the Sqlservr.exe process
that is writing the backup has access, it is irrelevant whether the user sending the
BACKUP command has access.
 IMPORTANT! Backing up data over a network can be subject to network errors;
therefore, we recommend that when you are using a remote disk you verify the
backup operation after it finishes. For more information, see RESTORE VERIFYONLY
(Transact-SQL).
Specify a Universal Naming Convention (UNC) name
To specify a network share in a backup or restore command, use the fully qualified
universal naming convention (UNC) name of the file for the backup device. A UNC name
has the form \\Systemname\ShareName\Path\FileName.

For example:
SQLCopy

BACKUPDATABASE AdventureWorks2012
TO DISK = '\\BackupSystem\BackupDisk1\AW_backups\AdventureWorksData.Bak';
GO

Using tape devices

NOTE: Support for tape backup devices 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.

Backing up SQL Server data to tape requires that the tape drive or drives be supported
by the Microsoft Windows operating system. Additionally, for the given tape drive, we
recommend that you use only tapes recommended by the drive manufacturer. For more
information about how to install a tape drive, see the documentation for the Windows
operating system.

When a tape drive is used, a backup operation may fill one tape and continue onto
another tape. Each tape contains a media header. The first media used is called
the initial tape. Each successive tape is known as a continuation tape and has a media
sequence number that is one higher than the previous tape. For example, a media set
associated with four tape devices contains at least four initial tapes (and, if the database
does not fit, four series of continuation tapes). When appending a backup set, you must
mount the last tape in the series. If the last tape is not mounted, the Database Engine
scans forward to the end of the mounted tape and then requires that you change the
tape. At that point, mount the last tape.

Tape backup devices are used like disk devices, with the following exceptions:
  The tape device must be connected physically to the computer that is running an
instance of SQL Server. Backing up to remote tape devices is not supported.

 If a tape backup device is filled during the backup operation, but more data still
must be written, SQL Server prompts for a new tape and continues the backup
operation after a new tape is loaded.
Specify a backup tape using its physical name
(Transact-SQL)
The basic BACKUP syntax for specifying a backup tape using the physical device name of
the tape drive is:

BACKUP { DATABASE | LOG } database_name

TO TAPE = { 'physical_backup_device_name' | @physical_backup_device_name_var }

For example:
SQLCopy

BACKUPLOG AdventureWorks2012
TO TAPE = '\\.\tape0';
GO

To specify a physical tape device in a RESTORE statement, the basic syntax is:

RESTORE { DATABASE | LOG } database_name

FROM TAPE = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Tape-Specific BACKUP and RESTORE options (Transact-SQL)

To facilitate tape management, the BACKUP statement provides the following tape-
specific options:

 { NOUNLOAD | UNLOAD }

You can control whether a backup tape is unloaded automatically from the tape
drive after a backup or restore operation. UNLOAD/NOUNLOAD is a session
setting that persists for the life of the session or until it is reset by specifying the
alternative.

 { REWIND | NOREWIND }
 You can control whether SQL Server keeps the tape remains open after the backup
or restore operation or releases and rewinds the tape after it fills. The default
behavior is to rewind the tape (REWIND).

NOTE: For more information about the BACKUP syntax and arguments, see BACKUP
(Transact-SQL). For more information about the RESTORE syntax and arguments,
see RESTORE (Transact-SQL) and RESTORE Arguments (Transact-SQL), respectively.
Managing open tapes

To view a list of open tape devices and the status of mount requests, query
the sys.dm_io_backup_tapes dynamic management view. This view shows all the open
tapes. These include in-use tapes that are temporarily idle while they wait for the next
BACKUP or RESTORE operation.

If a tape has been accidentally left open, the fastest way to release the tape is by using
the following command: RESTORE REWINDONLY FROM TAPE =backup_device_name.
For more information, see RESTORE REWINDONLY (Transact-SQL).
Using the Windows Azure Blob Storage service
SQL Server Backups can be written to the Windows Azure Blob Storage Service. For
more information on how to use the Windows Azure Blob storage service for your
backups, see SQL Server Backup and Restore with Microsoft Azure Blob Storage Service.
Use a logical backup device
A logical backup device is an optional, user-defined name that points to a specific
physical backup device (a disk file or tape drive). A logical backup device lets you use
indirection when referencing the corresponding physical backup device.

Defining a logical backup device involves assigning a logical name to a physical device.
For example, a logical device, AdventureWorksBackups, could be defined to point to the
Z:\SQLServerBackups\AdventureWorks2012.bak file or the \\.\tape0 tape drive. Backup
and restore commands can then specify AdventureWorksBackups as the backup device,
instead of DISK = 'Z:\SQLServerBackups\AdventureWorks2012.bak' or TAPE = '\\.\tape0'.

The logical device name must be unique among all the logical backup devices on the
server instance. To view the existing logical device names, query
the sys.backup_devices catalog view. This view displays the name of each logical backup
device and describes the type and physical file name or path of the corresponding
physical backup device.
After a logical backup device is defined, in a BACKUP or RESTORE command, you can
specify the logical backup device instead of the physical name of the device. For
example, the following statement backs up the AdventureWorks2012 database to
the AdventureWorksBackups logical backup device.
SQLCopy

BACKUPDATABASE AdventureWorks2012
TO AdventureWorksBackups;
GO

NOTE: In a given BACKUP or RESTORE statement, the logical backup device name and
the corresponding physical backup device name are interchangeable.

One advantage of using a logical backup device is that it is simpler to use than a long
path. Using a logical backup device can help if you plan to write a series of backups to
the same path or to a tape device. Logical backup devices are especially useful for
identifying tape backup devices.

A backup script can be written to use a particular logical backup device. This lets you
switch to a new physical backup devices without updating the script. Switching involves
the following process:

1. Dropping the original logical backup device.

2. Defining a new logical backup device that uses the original logical device name but
maps to a different physical backup device. Logical backup devices are especially
useful for identifying tape backup devices.
Mirrored backup media sets
Mirroring of backup media sets reduces the effect of backup-device malfunctions. These
malfunctions are especially serious because backups are the last line of defense against
data loss. As the sizes of databases grow, the probability increases that a failure of a
backup device or media will make a backup nonrestorable. Mirroring backup media
increases the reliability of backups by providing redundancy for the physical backup
device. For more information, see Mirrored Backup Media Sets (SQL Server).

NOTE: Mirrored backup media sets are supported only in SQL Server 2005 Enterprise
Edition and later versions.
Archive SQL Server backups
We recommend that you use a file system backup utility to archive the disk backups and
that you store the archives off-site. Using disk has the advantage that you use the
network to write the archived backups onto an off-site disk. The Windows Azure Blob
storage service can be used as off-site archival option. You can either upload your disk
backups, or directly write the backups to the Windows Azure Blob storage service.

Another common archiving approach is to write SQL Server backups onto a local backup disk,
archive them to tape, and then store the tapes off-site.

How to automate SQL Server

database backups
The question “How to automate SQL Server database backups” has several answers
and here we will review all of the best options. But first let’s define what SQL Server
database backup automation stands for. SQL Server backup automation is a process
that includes at least the following steps:
1.

1. Run SQL Server backup for selected databases on schedule

2. Compress & encrypt the backups

3. Upload the backup to a remote destination – network, NAS, FTP on one of the cloud
storages (Dropbox, AWS, OneDrive, SkyDrive, etc..)

4. Send email notification on backup success or failure

The most popular SQL Server backup automation options that we review here are:

SQLBackupAndFTP
Microsoft SQL Server Management Studio & SQL Server Agent
T-SQL
Ola Hallengren script
or you can just jump straight to the Conclusion

Notes to keep in mind before we begin

Note that if you do not have access to the file system of a remote SQL server like it
often happens in hosted SQL servers, you will need to use a different SQL backup
method described in our how to backup remote SQL database article. Here we will only
cover the most common options for SQL Servers running on local, networks, dedicated
or virtual servers.
SQL Server Express does not have a built-in way to schedule backups because the
SQL Server Agent is not included. SQL Server Agent has a horrible overblown interface
and we recommend using something else regardless of the SQL Server edition you are
using.

Do not overlook how difficult it is to restore. We’ve included short references on how to
do it for every tool below. For more details read How to restore SQL Server backup.
Note also, that you don’t have to backup the whole database, especially if it’s quite big.
You can backup only those changes that had place since the previous backup. For
more information read about Full vs Differential backups.

How to schedule SQL Server database

backups using SQLBackupAndFtp
SQLBackupAndFTP is the simplest tool to automate database backups. It is MS SQL
Server backup software that runs scheduled backups (full, differential or transaction log)
of SQL Server or SQL Server Express databases (any version), runs file/folder
backup, zips and encrypts the backups, stores them on a network, FTP server or in the
cloud (Amazon S3, Google Drive, Dropbox, OneDrive, Box, Amazon S3, Azure
Storage); removes old backups, and sends an e-mail confirmation on the job’s
success or failure.
There are few simple steps to set it up:

1. First download, install it, run and connect to your SQL Server. Then select the databases to
backup.

2. Then select where to store the backups.

In this case, we’ve selected a network folder. Press “Test” to check the connection, then
click “Save & Close”.

3. To create a backup schedule turn on “Schedule backups” and set the time to backup for
simple full daily backups. Or click the gear button to open “Advanced backup schedule” for
Differential and Transaction log backup and other options.
4. Compression is set by default and you can set encryption if you want to

5. Press “Run Now” to test the whole job. Then just the program – the job will run on schedule.

6. If you need to restore on the same computer – just select one of the backups from the
“History & restore” section, click on the 3-dot icon and click “Restore”:
To restore on a different computer, install SQLBackupAndFTP there, select “Restore” in
the menu and use the interface to select the backup to restore from.

Or you can just download the backup through SQLBackupAndFTP, a file manager or
the cloud destination client, unzip the file and use the standard RESTORE DATABASE
command.

How to schedule SQL Server database

backups using Microsoft SQL Server
Management Studio and SQL Server Agent
These are the following steps you need to take to create a .bak file (backup) using
SSMS:

1. Open your SQL server Management Studio

2. In Object Explorer, connect to an instance of the SQL Server Database Engine and then
expand that instance

3. Expand Databases and then right-click one of the databases you want to backup

4. Tasks -> Create backup

General Page
1. In the Database drop-down list, verify the database name.
2. The Recovery model text box is for reference only.
 3. In the Backup type drop-down list, select Full (after creating a full database backup,
you can create a differential database backup)
4. In the Destination section, use the Backup to drop-down list to select the backup
destination.
Backup Options Page
5. To view or select the backup options, click Backup Options in the Select a page pane.
6. In the Name text box either accept the default backup set name, or enter a different
name for the backup set.
7. Specify when the backup set will expire and can be overwritten without explicitly skipping
verification of the expiration date.

8. In the Compression section, use the Set backup compression drop-down list to select
the desired compression level.
9. In the Encryption section, use the Encrypt backup checkbox to decide whether to use
encryption for the backup.
5. Press OK and if everything is OK you will see a notification that a backup of selected
database is finished

To schedule backups using a SQL Server Agent job

To automate and schedule a backup with SQL Server Agent:

1. In the Object Explorer panel, under the SQL Server Agent node, right
click Jobs and select New job from the context menu
2. In the New Job dialog enter a job’s name
3. Under the Steps tab click on the New button and create a backup step by inserting a T-
SQL statement. In this case the CHECKSUM clause has to be included in T-SQL code.
4. Click ok to add a step, and click OK to create a job
5. To schedule a job, in the New Job dialog, under the Schedule tab click New.
6. In the Job Schedule select an occurring frequency, duration and a start date and click
OK:
7. To check a created job in the Object Explorer pane and under the SQL Server Agent ➜
Jobs node right click the job create above and select the Start job at step option:
You can find even more detailed explanations on backups with SSMS in this article.

How to schedule SQL Server database

backups using Transact-SQL
Transact-SQL (T-SQL) is Microsoft’s and Sybase’s proprietary extension to the SQL
(Structured Query Language) used to interact with relational databases. All applications
that communicate with an instance of SQL Server do so by sending Transact-SQL
statements to the server, regardless of the user interface of the application.
Generally, T-SQL command to generate a full backup may look like:
BACKUP DATABASE MyDatabase
TO backup_destination [ ,...n ]
[ WITH with_options [ ,...o ] ]
Where MyDatabase is a SQL Server database you wish to
backup. backup_destination is a place where you want to write a backup.
WITH with_options is a command you may use to apply different options to a backup
such as a compression or an encryption or a description and so on. To find more
information about backup options you may read an article.
As an example you may use next code to create a full backup to a disc device:

USE MyDatabase;
GO
BACKUP DATABASE MyDatabase
TO DISK = 'C:SQLServerBackupsMyDatabase.Bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of MyDatabase;
GO

To schedule the backups using Transact-SQL and Windows Task Scheduler follow
these steps (from original article):
1.

1. Use SQL Server Management Studio or Sqlcmd to create the following stored procedure
in your master database:

2. USE [master]

3. GO

4. SET ANSI_NULLS ON

5. GO

6. SET QUOTED_IDENTIFIER ON

7. GO

8. CREATE PROCEDURE [dbo].[sp_BackupDatabases]

9. @databaseName sysname = null,

10. @backupType CHAR(1),

11. @backupLocation nvarchar(200)

12. AS

13. SET NOCOUNT ON;

14. DECLARE @DBs TABLE (

15. ID int IDENTITY PRIMARY KEY,

16. DBNAME nvarchar(500)

17. )

18.

19. INSERT INTO @DBs (DBNAME)

20. SELECT Name FROM master.sys.databases WHERE state=0 AND

name=@DatabaseName OR @DatabaseName IS NULL ORDER BY Name

21.

22. -- Declare variables

23. DECLARE @BackupName varchar(100)

24. DECLARE @BackupFile varchar(100)

25. DECLARE @DBNAME varchar(300)

26. DECLARE @sqlCommand NVARCHAR(1000)

27. DECLARE @dateTime NVARCHAR(20)

28.

29. -- Database Names have to be in [dbname] format since some have - or _

in their name

30. SET @DBNAME = '[DBNAME]'

31.

32. -- Set the current date and time n yyyyhhmmss format

33. SET @dateTime = REPLACE(CONVERT(VARCHAR, GETDATE(),101),'/','') + '_'

+ REPLACE(CONVERT(VARCHAR, GETDATE(),108),':','')

34.
35. -- Create backup filename in pathfilename.extension format for
full,diff and log backups

36. SET @BackupFile = @backupLocation+REPLACE(REPLACE(@DBNAME,

'[',''),']','')+ '_FULL_'+ @dateTime+ '.BAK'

37.

38. -- Provide the backup a name for storing in the media

39. SET @BackupName = REPLACE(REPLACE(@DBNAME,'[',''),']','') +' full

backup for '+ @dateTime

40.

41. -- Generate the dynamic SQL command to be executed

42. SET @sqlCommand = 'BACKUP DATABASE ' +@DBNAME+ ' TO DISK =

'''+@BackupFile+ ''' WITH INIT, NAME= ''' +@BackupName+''', NOSKIP,
NOFORMAT'

43.

44. -- Execute the generated SQL command

EXEC(@sqlCommand)

45. In a text editor, create a batch file that is named Sqlbackup.bat, and then copy the text
from the following example into that file:

sqlcmd -S .SQLEXPRESS -E -Q "EXEC sp_BackupDatabases

@backupLocation='D:SQLBackups', @databaseName=’USERDB’,
@backupType='F'"

46. Schedule a job by using Windows Task Scheduler to execute the batch file that you
created in step 2. To do this, follow these steps:

1. On the computer that is running SQL Server Express, click Start, point to All
Programs, point to Accessories, point to System Tools, and then click Scheduled
Tasks.
2. Double-click Add Scheduled Task.
3. In the Scheduled Task Wizard, click Next.
4. Click Browse, click the batch file that you created in step B, and then click Open.
5. Type SQLBACKUP for the name of the task, click Daily, and then click Next.
6. Specify information for a schedule to run the task. (We recommend that you run this
task at least one time every day.) Then, click Next.
 7. In the Enter the user name field, type a user name, and then type a password in
the Enter the password field.
8. Click Next, and then click Finish.
9. Execute the scheduled task at least one time to make sure that the backup is created
successfully.

How to schedule SQL Server database

backups using Ola Hallengren script
If sometimes you need to create a backup without complex settings it’s enough to use
one of the options described above. But if you want regularly maintain your database
you need a maintenance plan. One of the most common ways that DBAs create
database maintenance plans is to use the Maintenance Plan Wizard from within SSMS.
While it is possible to create a decent database maintenance plan using the
Maintenance Plan Wizard, the tool is not very flexible. As your database environment
grows, the built-in tools in the SQL maintenance toolbox may prove insufficient.

Ola Hallengren has developed a series of stored procedures which together provide a
maintenance solution with the additional flexibility and features required to manage your
databases.

Getting started with the SQL Server Maintenance Solution is easy. Follow these steps.

1. Download MaintenanceSolution.sql.
2. Open that script in SQL Server Management Studio

3. In the script, find this line:

SET @BackupDirectory = N'C:Backup'

and replace C:Backup with the path to your backup directory.

4. In the script, find this line:

SET @CleanupTime = NULL

and replace NULL with your cleanup time. The cleanup time is the number of hours
after which the backup files are deleted.

5. Execute MaintenanceSolution.sql.
You could find more details on Ola’s site.
Conclusion
There are a number of ways to automate SQL Server backups.

SQLBackupAndFTP is by far the simplest and includes built-in encryption and a variety
of destinations, so that you can more easily integrate it with the services you currently
use. Additionally, its’ basic plan is free.
Traditional SSMS method is cumbersome, does not work in SQL Server Express and is
limited in destinations. T-SQL method is just bare bones, it is lacking compression,
encryption, notifications, and destinations. Ola’s script is just a more advanced version
of T-SQL method.

SQLBackupAndFTP is simply the best solution to create SQL Server backups on a

regular basis with flexibility and integration with the services you already use. It
performs complex tasks, but its’ UI and usability is extremely simple to use. You’ll be
scheduling SQL backups in less than 5 minutes.