Testing your backups – Things that you don’t know if you’re not.
Are your backups configured to the intended backup destination?
Imagine this; you’ve been running your backups nightly for over 18 months and following all the best practices. Everything is going well and confidence is sky high should disaster strike.
Suddenly; something happens to your most critical server (be it a crash, or ransomware hit) and you’re called upon to use these backups. When you go to load your backups from the destination; the latest backup is over 15 months old.
This couldn’t be right; but unfortunately all the log files from your backup software aren’t available because they were on the system you’re trying to recover.
As it turns out; all your backups were being written somewhere and you’ve had no idea all this time.
Testing your backups regularly would’ve identified this issue before it became a major problem.
Do your backups contain all the data that should be backed up?
It’s one thing to be performing backups, although there is the chance that the data included in the dataset isn’t always the most critical.
By testing your backups; you’re able to check that everything you’re expecting to be there is included in full.
What methods of restore and recovery are available to you?
Different backup type’s means different restore and recovery options are available.
By testing your backups regularly; you can assure you’re able to recover the way you’re expecting.
We’ve recently worked with a company who needed to perform a bare metal recovery – however they had only been performing file based backups which means that bare metal wasn’t an option. This not only caused additional stress (a notice of ‘no backups found’ will do that) – but once back on track; the recovery method contained more steps than first expected meaning the downtime doubled.
Backup verification says it’s successful.
Backup verification is a nice feature offered by all good backup solutions. It’ll run a test of your freshly created backup to make sure some (or all) the data when the backup is finished.
However this was three months ago; a lot has happened since then. The drive was in a back pack being taken offsite and dropped down a flight of stairs; then stored in a bowl on top of the fridge (magnets and hard drives don’t mix).
It’s too late to find out if the backup is good in a real life recovery situation.
Testing your backups regularly would’ve found that the drive was no good long before you ‘really’ needed it.
How robust your backup strategy is.
You’ve performed all the planning and come up with all the scenarios you know could happen that means you need to recover from your backup. The real determining factor is by physically throwing your backups at these scenarios and seeing how they stand up. If you’re not testing your backups; it means that you’re going based on theory and logic that you’re covered – two things that typically don’t always work out in IT.
More reading as to why it’s important to test your backups can be found in our blog at https://testmybackups.com/2017/10/21/backup-disaster-recovery-testing.
A great third party article on worst disaster recovery practices is available from https://www.techrepublic.com/article/disaster-recovery-worst-practices-dont-test-your-backups
Help testing your backups?
Unsure where to start, or don’t have the resourcing or time? Don’t have your ‘Crying Jordan’ moment!
Let us know and we’ll help you out – just reach out on https://testmybackups.com/contact/.