Best practice for testing database disaster recovery This is regarding database disaster recovery testing. The production server has 20+ databases. I'm developing procedures for regular testing of disaster recovery and am wondering what is the best practice, testing ALL databases or is one sufficient?
If one database successfully restored, it certainly does not mean that the next database has no problems. (E.g. I once, many years ago now, had some disk array problems that resulted in about 20% of the databases on a server manifesting corruption.)

I run a weekly process that RESTOREs and runs DBCC CHECKDB on all databases from over 70 servers. This is done one database at a time and for me takes most of a week. For fully logged databases we also test the latest full backup by restoring all the logs as well. 

I have a dedicated machine for doing this, so that there is no conflict with anything happening on the standard landscape of servers. 

The truth is that most everything works fine, but occasionally there is a corruption and that is followed as quickly as possible with a resolution.

Statistically you can test fewer databases and feel pretty safe, but checking them all gives you a quicker heads up.