You’re only as good as your last backup.
Ask anyone and they’ll tell you “backups are essential” and they’re absolutely right. What is often forgotten is that backups can become corrupt in just as many ways and reasons as the reason that has caused you the need to restore from one. Hardware fails, software has bugs, people make mistakes – it’s going to happen. What doesn’t have to happen is finding out your backups are corrupt the moment you need them.
Backup testing has historically been a clumsy, time-consuming, and expensive task as it required an entirely separate physical hardware setup to be maintained. This could mean one server or racks of hardware that mostly sat idle. With virtualization now the standard and dedicated hardware often used only for specific tasks that require it, regular backup testing has become feasible without breaking the bank.
Today, a backup can be restored to a new virtual machine, validated, and that server destroyed with a single click. With a little extra work, this could be a single server test or restoration of an entire platform – scale is no longer the barrier it once was.
Backup testing should be done as often as sensible and each organization’s needs are different so there is no one-size-fits-all solution for backups. The fundamentals are still the same: understand your data, it’s varying importance and volatility, and your recovery objectives. Once you understand the nature of your data, designing and implementing a testing schedule is a breeze…
Author: Joe H