Share via


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 Microsoft SQL Server, 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 SQL Server Database Engine returns a success message. 


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

Topic link icon Transact-SQL Syntax Conventions


FROM <backup_device> [ ,...n ]
[ WITH  

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

--Monitoring Options
 | STATS [ = percentage ] 

--Tape Options
 } [ ,...n ]

<backup_device> ::=
   { logical_backup_device_name |
      @logical_backup_device_name_var }
   | { DISK | TAPE } = { 'physical_backup_device_name' |
       @physical_backup_device_name_var } 


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.


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


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 SQL Server tools. However, a password does not prevent overwrite of media using the BACKUP statement's FORMAT option.

Security noteSecurity 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. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. 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.


Beginning in SQL Server 2008, obtaining information about a backup set or backup device requires CREATE DATABASE permission. For more information, see GRANT Database Permissions (Transact-SQL).

See Also


BACKUP (Transact-SQL)


RESTORE (Transact-SQL)


Media Sets, Media Families, and Backup Sets (SQL Server)

Backup History and Header Information (SQL Server)