Tips on Cloud-Native Backup and Restore

Tips on Cloud-Native Backup and Restore

Profile picture for user AndrewAbwoga
Andrew Abwoga
15 October 2020

Cloud-native infrastructure is aggressively shaping the global industry. It’s very evident how the influence of cloud-native technologies such as containers and container orchestration environments are shaping how systems and applications are provisioned and most importantly how data is accessed and stored. When it comes to disaster recovery practices for cloud-native infrastructure, the key things to consider are how you can backup Infrastructure as Code (IaC), configuration management artifacts and data that resides in such environments. This blog takes a pick on considerations for backup and restoration on cloud-native environments.

Tips on Cloud-Native Backup and Restore

Why Backup?

Even though your cloud-native environment is highly available and supports disaster recovery you may still need to backup for these purposes:

  • To mitigate data corruption risks. Through a code bug, a malicious user action, or an external failure, your data can be corrupted. It doesn’t matter if the data is being replicated to another availability zone because corruption can be propagated across your environment.
  • To redeploy a previous version of your infrastructure or application if the latest version has problems.
  • To restore environments to a specific state
  • To migrate to another cloud provider
  • To comply with regulatory requirements. You might need to archive your data and keep it for a specific period of time. For a cloud-native application, this requirement can be more prominent because the data might be spread through multiple databases in different engines, as is the case for many monolithic applications. 

What Needs to be Backed Up?

Infrastructure as Code (IaC)

IaC is basically the process of managing and provisioning infrastructure using machine-readable definition files instead of using the typical physical hardware configuration or other interactive tools. Modern IaC tools such as Chef, Otter, Puppet, Terraform, Ansible Tower are increasingly being used in the automation of infrastructure using definition files. With such tools, it may be easier to think of ways to orchestrate the restoration of infrastructure during a disaster. The most common way to store definition files for such tools is using a version control system such as Git, since you are able to continuously track changes to your infrastructure according to your business needs. It is not uncommon to see such tools being used to provision infrastructure for cloud-native environments since most cloud-native environments reside on Infrastructure as a Service (IaaS) computing environments. You may need to consider using backup and restoration tools to store and retrieve the IaC definition files and other artifacts if you determine the risk of downtime or corruption of your version control system especially if it is set up on-premise. This may go a long way towards enabling you to restore your infrastructure in case of a disaster.

Configuration Artifacts

Other common configuration artifacts include files that are used to provision workloads in a cloud-native environment. The most common technologies such as Docker and Kubernetes use files such as Dockerfile, .json and .yaml files to define the makeup of cloud-native workloads/applications. Such definition files are typically stored on version control systems to track changes for cloud-native environments and for automated builds and provisioning but they may also need to be backed up in case the version control systems are affected by disastrous events.


Container image repositories store images that are essentially tar files that are used to package everything that is needed to run an application: application code and any runtime it requires. Cloud-native administrative tools used for docker and Kubernetes give you the option to export/import or save/load images that you may use as backups for containers.

Data Volumes

Cloud-native infrastructure predominantly comprises data stored in persistent data volumes. Due to the ephemeral nature of cloud-native workloads, storing data in the workloads does not guarantee the persistence of data after the workloads have been torn down hence the need for persistent storage. Persist volumes represent data that is stored on-disk and they are accessed on cloud-native workloads using mounting mechanisms. In the case of Docker, you can backup or restore data volumes into tar files. You may need to consider using backup tools to continuously backup the tar files.

Final Thoughts

Cloud-native environments are composed of different kinds of files/artifacts that are typically file-based. These files may represent applications, data or configurations. In that case, you may need to consider using file-based backup tools to guarantee the restoration of data, applications, or configurations in case of disastrous events.