Do you know the difference between experienced DevOps and non? Experienced DevOps already made a backup, and non-experienced will do it in the nearest time.
Share this article:
Why worry about Backup and Restore?
It’s important when dealing with data to always have in mind what would happen, both to you and your customer, if that data were to be lost and were no longer available. As you can imagine, the outcome is rarely optimal. When it comes to cloud computing, concepts such as Disaster Recovery and High Availability are often discussed and put into practice for this very reason. If any of the data storage in AKS cluster were to fail, we need to ensure that we have a backup data disk from which we can restore and continue running normally.
What resources should I be backing up?
The only resources that need to be backed up from an AKS resource group are the mounted Persistent Storage disk resources. This means any OS Disk resources, often labeled aks-agentpool-NUMBER-1_ID, or other VM components, NSG, Load Balancers, etc need not be snapshot as they do not contain any data we need. For an example, see the picture below.
What format should the data be backed up in?
The backed-up data should be snapshot of the desired disk.
How do I go about backing up my AKS Cluster?
As there is currently no way to natively back up persistent storage in Azure, you must manually snapshot each disk you wish to back up. Ideally this would be done by writing a Snapshot Persistent Storage Disks task where applicable. Please refer to Dynamically create and use a persistent volume with Azure disks in Azure Kubernetes Service 1 for more information and steps on how to do so. Keep in mind, you will need the subscription ID and resource group name for appreciate AKS resource group, as well as the kubectl tool.
How do I go about restoring data I have backed up?
Again, as there is currently no way to natively back up persistent storage in Azure, you must manually restore each disk you’d like from each individual snapshot.