Do you need a backup in the cloud?

If you are developing a new cloud application, and you’re still using infrastructure backup, it’s time to rethink your disaster recovery strategy.

Backup and Restore

Backups are commonly used to restore data after accidental deletion or corruption. Other uses of backup & restoration mechanisms include creating new copies of a resource for testing and troubleshooting.

Backup & Restore is a big part of your Business Continuity & Disaster Recovery (BC & DR) strategy. A complete backup solution designed for your application usually contains: 

• A backup service.
• Storage: usually placed in a different location to the production site (ideally, on a different cloud provider).
• Data backup policies (schedules, retentions, tiering).
• Procedures for protection deployment.
• Procedures for monitoring & alerting on backup jobs.
• Restoration procedures.
• Your application recovery plan.
• Regular recovery plan testing to confirm compliance with policies required by your business, such as: RPO, RTO or SLA.
• Regulatory compliance, such as the right to be forgotten and cross-border data transfer. An example of this would be GDPR where it is important that the user understands the data retention period for their backup..

This article will focus on scenarios where applications are fully hosted in the cloud and a team needs to prevent data loss.

Enhancing your backup strategy in the cloud

In my personal opinion, with cloud-native applications, infrastructure backup services are legacy, and your data protection risks could be mitigated in a better way.

If you have not found a SaaS product and you have decided to make a custom application; instead of maintaining and operating a complex data backup solution, make sure that you design your custom application with:

• Immutable storage: For most applications document versioning is enough, in the extreme though, you can use Blockchain. As a compromise, there are also Continuous data protection (CDP) solutions.

Note: Search indexes, cache, temporary storage do not require a backup or immutability. 

• Replication: You can configure replication to have a copy of your data stored with another cloud provider or you can choose data services with geo-replicated storage support.

Note: Replication is used to protect data from datacenter loss, however it is important to note that replication itself without immutability does not protect data from corruption. 

• Immutable infrastructure represented by Infrastructure as a Code: Recovery from catastrophic events will require not only a data restore but also infrastructure configuration state restoration. Applications with immutable infrastructure principles in design are easier to fully redeploy automatically. 

Note: However, be aware of your cloud resources’ deletion protection. Some resources may not be deleted immediately and to avoid waiting, each redeployment application’s resources will have new names and new IP addresses.

• Application data export and import mechanisms: Restoring an application with its own import is more resilient than bringing back infrastructure and hoping that the application will run on restored data.

• Security by design: Preventing data corruption is better than restoring data.

Those points do not free us from the need to have restoration procedures and test them regularly. They only simplify end-to-end automation, enable opportunity for self recovery, provide flexibility for capacity & better performance management.

Finally, Backup & Restore is just a part of BC & DR for your application. The final availability and fault tolerance will also depend on:

• Cloud Engineering Excellence: Right implementation of best practices for high availability of your target cloud provider. Understanding cloud services SLAs and leverage them in your application design.
• Operations Excellence: Level and efficiency of automation for your operations.

Any cloud topic cannot avoid cost questions. What is cheaper, more complex application architecture or more complex backup solution? You will need to evaluate:

• The costs of a complete backup solution (including costs for design and implementation, future running, maintenance and operations)
• The costs for restoration procedures in both cases
• The costs for your application development or modernisation
• The costs for human resources and IT resources needed in both cases
• The costs of your application data loss and downtime

Costs make us realistic. With the amount of money likely to be spent on such solutions, it’s probably not realistic to have a same level BC & DR solution for all applications but it can be leveraged with a good architecture design.