A robust backup plan is an essential part of your organization's business strategy. After all, following a failure or defect, you want to get back to work as quickly as possible without losing business-critical data, ensuring your organization's continuity. Yet, backup errors occur regularly, often because it is unclear which aspects of a backup plan require extra attention.
WHAT IS IMPORTANT WHEN CREATING A GOOD BACKUP?
We can be brief about this. When it comes to backups, it is vital that you are aware of the following three points:
- Test your backup regularly;
- Ensure your backup technology is independent of the production site, meaning it should be in a different data center at least 50 kilometers away and not on the same network;
- Perform backups regularly and always keep in mind the acceptable restore time (Recovery Time Objective – RTO) and the acceptable data loss (Recovery Point Objective – RPO) for your backup strategy.
Explanation of the RPO and RTO definitions
RPO stands for the amount of data lost. Suppose you have an RPO of four hours; this means that in the worst-case scenario, only the data from the last four hours is lost.
RTO means that if you have an RTO of two hours, your application will be unavailable for at most two hours in the worst-case scenario.
WHERE DOES IT GO WRONG?
Unfortunately, not everyone considers the importance of the points above, leading to errors when configuring backups. For instance, we sometimes hear that a restore takes too long, causing an organization to be down for a while. We also frequently hear that a restored backup does not contain the correct data because not enough backup points were created or the data is simply too old (resulting in an RPO that is too high). This is incredibly frustrating, of course, but also easy to solve.
Do you want to be sure that your backup strategy is rock-solid? Then ask yourself the following four questions:
1. Are you aware of the basic rules that apply to your Cloud environment?
Actually, the rule here is: the safer, the better. An important rule you can use is the 3-2-1 backup rule. This means you should make 3 copies of your data, store them on 2 different types of media, and keep them in 1 other location. Therefore, ensure your backup is always independent of the production site. This is where Fundaments comes in. By using innovative technology from Cohesity, we store your data in a different location and on a different platform. Cohesity uses the WORM principle: write once, read many. This ensures that information or data cannot be altered once it has been written and stored. Consequently, there is no impact on your backup if the production environment is hit by a ransomware attack. Read more about this here.
2. Does your restore actually work? Do you test this regularly?
Many organizations create backups but then forget the most important part: testing the restore of a backup. Therefore, check your backups regularly. Is all data being fully copied? And does everything work after a restore? Cohesity has developed a Test/Dev capability for this. This is for testing software with backup data, but it also serves as proof that the backup is working properly. Test/Dev performs a data restore in a separate environment, so there is no impact on the production environment.
3. How long does it take to complete a restore?
The speed of a restore is of great importance. The larger your environment, the longer a restore takes and the more time it costs to return to the same production performance levels. Make sure you are aware of this so that your organization experiences as little service disruption as possible and you safeguard your business continuity. The recovery time (and thus RTO) must be as low as possible.
4. Do you need a DR service in addition to a backup?
If it turns out that your backup cannot meet your RPO and RTO requirements, it is advisable to also consider a Disaster Recovery (DR) solution. Such a solution ensures that your production site can be started up quickly and easily at an alternative location. Your backup strategy can then be refocused on long-term data storage, while the DR service provides a rapid failover capability. See the comparison between backup and DR below:
RPO
Backup: hours to a day
DR: seconds to a few hours
RTO
Backup: hours to days
DR: minutes
