Depending on the time available – I will normally commit a RESTORE VERIFY ONLY  on a backup.

 With the statement :

 RESTORE VERIFYONLY FROM  DISK = ‘E:\backuppath\mydb.bak’

 I’m not advocating that RESTORE VERIFYONLY – will 100% guarantee that your database has full data integrity. For a start , you would have to at least BACKUP with CHECKSUM , which would then allow you to RESTORE VERIFYONLY with CHECKSUM check.

 Even with CHECKSUM used this can allow a successful verification – despite corruption in MTF

 For data integrity – I run a regular  CHECKDB (after the database is restored) after a RESTORE VERIFYONLY

In the range of checks available , I consider the RESTORE VERIFYONLY a relatively high level verification. To derive a  more granular check – use other checks

 The RESTORE VERIFYONLY will check for :

 1)backup set is present   and header fields of pages

2)Are volumes readable?

3)checksum (if enabled , BACKUP by default does not use CHECKSUM)

4)destination drive – space check.

 The process can take awhile – particularly if it’s a large database. This must be weighed up against the cost in a restore failure  - for example , if you can verify the space on a destination drive , or some header field corruption , this could save you time .

 For example on a 95 GB database , which I’m currently working on , the   RESTORE VERIFY ONLY will take about 10 minutes,  which in itself is not to bad – given the repercussions of a failed restore – or at least a higher probability that you may be able to detect a failure earlier in the process

Source:Jack Vamvas (http://www.sqlserver-dba.com)