My DR procedure was to automatically restore the mail server, DB server and file server once a month with automated fail back to the live servers if they failed

My DR procedure was to automatically restore the mail server, DB server and file server once a month with automated fail back to the live servers if they failed. These would happen outside heavy operation hours, and if successful, the restored servers would become the live servers in most instances. These were done using scripted vmware instances, mostly restoring from StorageCraft Shadow Protect backups. File server was the most resource intensive and the most prone to complaints about downtime, but usually the trade off was fine. DB server was usually fine due to the out of hours restore, and the ability to master - slave - replicate - handover. Mail server was usually transparent as you could set up smtp transfer rules for incoming, and outgoing didn't really care. The trickier ones were things like IBM I Series servers that usually require periodic full system saves, restores and tests. These couldn't be done automatically without excessive licensing fees and much manual baby sitting. If you get to the point where you have automatic scheduled DR, you can be pretty confident your backups are working. It the automated DR fails, you roll back, learn whatever lesson the failure taught you, and change the system so it doesn't happen again. Summary: schedule DR, not backups.