This is why it is not enough to backup and routinely test the backup. It must be tested as a restore. Obviously, it is not good to do on a production server. There are three good methods to do this.
1. Use a backup solution that can run the backup in a sandbox.
2. Use a backup solution where you can restore online.
3. Have a replication backup to a second server (expensive, but this allows you to weekly check the backup server). Plus if you are down, you simply switch over. With failover, it happens automatically, but I think that is a bit much.
I think restoring immediately would be something that even Google would not want to do. I wouldn't. I would rather have really good UPS on the server and a computer with printing abilities so I could quickly print the rest of the schedule. The paper notes can be put into AC later. Trying to restore quickly in the middle of the day would result in disaster. I would rather get coffee, chill out, figure out when everything happened and restore from there. Then add the notes.
But, here is the thing. Are we talking about a complete crash of the server? Or it is down for some reason. Personally, I would rather try to figure out what happened. Like the Power Supply went down and the redundant one didn't kick in. Or, a cable fried.
You can use VMs (which is the way to go) as you can simply copy and paste them to another server or even computer with Hyper-V. Or you can "restore" what would be backups of a VM to Amazon S3 or Azure, etc. and now you can work from there. I believe the best way to go is to use Acronis and do backups. A little pricey, but you can back up incrementals to Acronis' own cloud servers. These can be accessed and run from.
I think even Sandeep would not want to restore immediately. Plus, you would have to have readily available drives to throw in or slide in if you are using RAID. But, these are all plans you want to have in advance.
