Almost everyone knows why backups are important. More than ever in an age of heightened ransomware threats, it’s important to have a clean copy of data to restore in the event of an emergency.
However, you don’t have to wait until an emergency to find out if restoring from a backup works. In other words, you need backups you can trust – and the only way to be sure of that is to test.
In this article, we look at the key elements of backup testing, including what to test, when to test and how, and the management framework you need regarding backup testing.
Why backup testing?
Every organization has data it cannot afford to lose. How organizations differ and how data is managed within organizations varies according to the amount of data they can lose and the length of time it will be unavailable.
Those concepts are broken with the idea of RPO and RTO. RPO, or recovery point object, has to do with how much data you can lose as measured back to the last good copy. The RTO, or recovery time objective, is how long it will take to get that data back.
How strict that is for your organization – as measured by the impact on reputation, potential commercial loss, compliance and the threat of fines, etc. – can be a good measure of how important the backup test is.
That’s because backups are worthless unless you can restore your organization’s needs.
What to try
The short answer to this question is the ability to recover. But there are many different datasets with different levels of criticality in terms of RPO and RTO.
For example, the data held by an organization can range from long-term archives to transactional production data. One can sit there for years without being accessed, while the other is being used now and losing seconds of it can cost a lot of money.
What is needed before anything else is a backup audit, which begins with an audit of all the organization’s data and applications, their location (including all sites and cloud hosting), and their importance as measured by RPO and RTO terms.
In addition to this, the audit should include how these datasets are protected in terms of backups, but also other methods such as snapshots, which are a means of protecting data since the last backup.
Finally, the backup audit should be updated on a regular basis to take into account new application deployments, with backup requirements for applications built in the development process.
As can be seen, the “what” to back up question can be big and constantly changing, but it’s important to know to be sure you can restore the data when needed. Some suppliers – such as Veritas – are working on so-called autonomic backup, where this work is taken over by the backup software itself, but it is not yet widely produced.
How to test backups
The purpose of all testing is to ensure that you can recover the data. Those recoveries can be of individual files, volumes, particular datasets – related to an application, for example, or even an entire site, or more.
So, testing needs to happen at different levels of granularity to be effective. That means different file levels, volumes, sites, etc., as above. But it also means the workload and type of system, such as archive, database, application, virtual machine or discrete system.
At the same time, the backup landscape of an organization is subject to constant change, as new applications are brought online, and as the location of data changes. This is more the case than ever with the use of the cloud, because applications are developed in faster cycles, and through new deployment methods such as containers.
When to test backups
This means that testing should be as comprehensive as possible, while taking into account that testing at certain levels – for example, the entire organization – may not be practical on a regular basis.
So, it is likely that testing will occur at various levels of the organization on a schedule that balances practicality with necessity and importance. Meanwhile, that test must consider the ever-changing backup landscape.
As mentioned above, it can be explained that backup testing is built into the application development and deployment process. So while the applications are tested, the ability to recover their data is also tested.
Document the test backup plan
If all aspects of the need to test backups and the ways in which they should be done are considered, there is a need to record and plan them, so that your test backup plan should be documented.
It should be recorded:
- Regularly audit your key systems and applications and state their RPOs and RTOs.
- Backup systems are in place.
- A test schedule that applies to all levels of potential recovery, from the file level to the entire site.
- The ways in which these elements will be tested and the recovery targets to be achieved.
- When the test backup documentation will be updated and what will trigger the updates.