Understanding the impact/risk of turning off "verify backup integrity" on SQL backup Currently we use standard maintenance plans for backups on the SQL Server 2005/2008/2008R2/2012 servers in our environment, and the "Verify backup integrity" box has always been checked.

Some of the backups run very long, so I've recommended turning off that option, but management needs me to document the impact and risks of this change.

I understand the use and history of this option, it just seems unnecessary to me to double the time for the backup job when (in my opinion), any error that is likely to occur would occur during the backup step, not during the verify.

Am I wrong? Is it minimal risk to turn this off, if I am backing up to disk and not to streaming tape or something? (We back up over the network to an EMC DD-800 backup appliance, if that is relevant.)

Is there any official MS recommendations for when it is safe to turn this off? 

Do you run "verify" on every backup in your environment? Do you spot-check them?

EDIT: To clarify, when you check "verify backup integrity" in the maintenance plan, SQL will do a full RESTORE VERIFYONLY on each database immediately after each backup. This is just as data/IO intensive as the original backup, and (basically) doubles the overall time of the backup job. This is not the same as enabling the "checksum" option on backup (which can't be done in the wizard, as far as I know).
Am I wrong? Is it minimal risk to turn this off, if I am backing up to disk and not to streaming tape or something?

No, you are right :-)
RESTORE VERIFYONLY only will not ensure that you will be able to recover your database in the event of corruption. By nature, it will not perform any integrity checks.
A better way will be to periodically take your backups and do a valid restore on a different server and perform DBCC CHECKDB on it.
This is one reason, why I am not a big fan of maintenance plans since the GUI does not expose a lot of options like backup .. with CHECKSUM that can be achieved by T-SQL.
From Paul Randal's Myth blog

24p) using RESTORE … WITH VERIFYONLY validates the entire backup
No. Using VERIFYONLY only validates the backup header looks like a backup header. It's only when you take the backup using WITH CHECKSUM and do RESTORE … WITH VERIFYONLY  and using WITH CHECKSUM that the restore does more extensive checks, including the checksum over the entire backup.
Do you run &quot;verify&quot; on every backup in your environment? Do you spot-check them?

I dont run the VERIFYONLY. Instead I take backup with CHECKSUM and then have them restored + CHECKDB'ed on a different server. You can follow
Statistical Sampling for Verifying Database Backups approach if you want to be creative.

This is not the same as enabling the &quot;checksum&quot; option on backup (which can't be done in the wizard, as far as I know).

You can enable Trace Flag 3023 so that the CHECKSUM option is automatically enabled for the BACKUP command. As always, test the behavior of any trace flags in your environment !
The bottom line is - ditch maintenance plans and use a more sensible backup solution (hint: Ola's backup solution) that will allow you to customize it based on your needs.

(We back up over the network to an EMC DD-800 backup appliance, if that is relevant.)

Backup up locally to the disk and then have a PowerShell transfer job that will copy the backup locally from the server to a network share (backup server). That will be more faster than to directly copy to a network share.
Also, enable instant file initialization, that will help with auto-growths on data files as well as will help cutdown the restore time (incase if you have to restore your databases). Its always good to have options handy.
A good read will be : Backups: Planning a Recovery Strategy