Most people know the importance of backups, and probably do them religiously in their businesses. But these same people normally get bitten after the disaster has struck, because they cannot restore that backup.
There could be various reasons.
The point here is that once you’ve made a backup of your critical data, how sure are you that you can actually restore the data?
It is pretty pointless to have your data on a tape or external drive, but there’s no way to restore it. So without ever testing a restore, your backup solution is only 50% done.
Your question now is probably, how do I test a restore without negatively impacting my business operations. You can’t exactly just go restore the last backup on your live application server, can you?
There are a number of solutions here. What I’ve found works best for me is to setup a virtual server that matches my live server in configuration, but not in specification. Server hardware is pricey and you don’t always need the same spec server to test a restore. You will need one if your primary server does fail though.
But to test the restore, a virtual server with enough resources will do. Once you have this up and running, try to restore your databases, websites, emails, system state, and whatever else you are backing up on a regular basis. If the restores fails, try with a new backup, until you get it right. Or you could make the call that some things just aren’t worth the effort to try and restore, and implement manual procedures for these.
A system state is a very finicky thing to try and restore, especially if your new hardware does not match the original. So if you have less than 30 users, you could go the route of manually recreating your system state, and just restoring data as and when required.
The bottom line: An untested backup is only half the solution.