Skip to content

Latest commit

 

History

History
130 lines (98 loc) · 6.75 KB

restore-statements-verifyonly-transact-sql.md

File metadata and controls

130 lines (98 loc) · 6.75 KB
title description author ms.author ms.date ms.service ms.subservice ms.topic f1_keywords helpviewer_keywords dev_langs monikerRange
RESTORE VERIFYONLY (Transact-SQL)
RESTORE Statements - VERIFYONLY (Transact-SQL)
MikeRayMSFT
mikeray
03/30/2018
sql
t-sql
reference
VERIFYONLY
RESTORE VERIFYONLY
VERIFYONLY_TSQL
RESTORE_VERIFYONLY_TSQL
RESTORE VERIFYONLY statement
backups [SQL Server], verifying
verifying backups
checking backups
TSQL
=azuresqldb-mi-current||>=sql-server-2016||>=sql-server-linux-2017

RESTORE Statements - VERIFYONLY (Transact-SQL)

[!INCLUDEsql-asdbmi]

Verifies the backup but does not restore it, and checks to see that the backup set is complete and the entire backup is readable. However, RESTORE VERIFYONLY does not attempt to verify the structure of the data contained in the backup volumes. In [!INCLUDEmsCoName] [!INCLUDEssNoVersion], RESTORE VERIFYONLY has been enhanced to do additional checking on the data to increase the probability of detecting errors. The goal is to be as close to an actual restore operation as practical. For more information, see the Remarks.

If the backup is valid, the [!INCLUDEssDEnoversion] returns a success message.

Note

For the descriptions of the arguments, see RESTORE Arguments (Transact-SQL).

:::image type="icon" source="../../includes/media/topic-link-icon.svg" border="false"::: Transact-SQL syntax conventions

Syntax

RESTORE VERIFYONLY  
FROM <backup_device> [ ,...n ]  
[ WITH    
 {  
   LOADHISTORY   
  
--Restore Operation Option  
 | MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'   
          [ ,...n ]   
  
--Backup Set Options  
 | FILE = { backup_set_file_number | @backup_set_file_number }   
 | PASSWORD = { password | @password_variable }   
  
--Media Set Options  
 | MEDIANAME = { media_name | @media_name_variable }   
 | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }  
  
--Error Management Options  
 | { CHECKSUM | NO_CHECKSUM }   
 | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }  
  
--Monitoring Options  
 | STATS [ = percentage ]   
  
--Tape Options  
 | { REWIND | NOREWIND }   
 | { UNLOAD | NOUNLOAD }    
 } [ ,...n ]  
]  
[;]  
  
<backup_device> ::=  
{   
   { logical_backup_device_name |  
      @logical_backup_device_name_var }  
   | { DISK | TAPE | URL } = { 'physical_backup_device_name' |  
       @physical_backup_device_name_var }   
}

Note

URL is the format used to specify the location and the file name for Microsoft Azure Blob Storage and is supported starting with [!INCLUDEssSQL11] SP1 CU2. Although Microsoft Azure storage is a service, the implementation is similar to disk and tape to allow for a consistent and seamless restore experience for all the three devices.

Arguments

For descriptions of the RESTORE VERIFYONLY arguments, see RESTORE Arguments (Transact-SQL).

General Remarks

The media set or the backup set must contain minimal correct information to enable it to be interpreted as Microsoft Tape Format. If not, RESTORE VERIFYONLY stops and indicates that the format of the backup is invalid.

Checks performed by RESTORE VERIFYONLY include:

  • That the backup set is complete and all volumes are readable.

  • Some header fields of database pages, such as the page ID (as if it were about to write the data).

  • Checksum (if present on the media).

  • Checking for sufficient space on destination devices.

Note

RESTORE VERIFYONLY does not work on a database snapshot. To verify a database snapshot before a revert operation, you can run DBCC CHECKDB.

Note

With snapshot backups, RESTORE VERIFYONLY confirms the existence of the snapshots in the locations specified in the backup file. Snapshot backups are a new feature in [!INCLUDEsssql16-md]. For more information about Snapshot Backups, see File-Snapshot Backups for Database Files in Azure.

Security

A backup operation may optionally specify passwords for a media set, a backup set, or both. When a password has been defined on a media set or backup set, you must specify the correct password or passwords in the RESTORE statement. These passwords prevent unauthorized restore operations and unauthorized appends of backup sets to media using [!INCLUDEssNoVersion] tools. However, a password does not prevent overwrite of media using the BACKUP statement's FORMAT option.

Important

The protection provided by this password is weak. It is intended to prevent an incorrect restore using [!INCLUDEssNoVersion] 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. [!INCLUDEssNoteDepFutureAvoid]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.

Permissions

Beginning in [!INCLUDEsql2008-md], obtaining information about a backup set or backup device requires CREATE DATABASE permission. For more information, see GRANT Database Permissions (Transact-SQL).

Examples

The following example verifies the backup from disk.

RESTORE VERIFYONLY FROM DISK = 'D:\AdventureWorks.bak';
GO

See Also

BACKUP (Transact-SQL)
Media Sets, Media Families, and Backup Sets (SQL Server)
RESTORE REWINDONLY (Transact-SQL)
RESTORE (Transact-SQL)
Backup History and Header Information (SQL Server)