Protect Kubernetes with Druva for Amazon EKS and custom EC2 clusters

Druva’s SaaS-based data protection solution for application deployments from mid-market up to large organizations is now available to all customers. This release will quickly enable stateful backup and restore of Kubernetes workloads using Druva’s simple workflows and intuitive UI-based policy automation.

The container-based orchestration software ‘Kubernetes,’ which is also known as ‘K8s,’ is currently one of the fastest-growing open-source projects. Kubernetes was first developed by Google in 2013. Since then, they have publicly announced that they run everything in containers. Per a recent Gartner analyst report, by 2023, 70 percent of global organizations will be running three or more containerized applications in production, a significant increase from 30% in 2019.

Druva’s solution not only focuses on the Kubernetes administrator, but also on other stakeholders such as DevOps, cloud admins and application owners. Druva provides application group-centric protection present in the customer’s Amazon EKS and custom Amazon EC2 clusters. With Druva’s intuitive UI, cloud operation teams can easily protect their workloads by securing snapshots of these application groups, providing a quick and easy stateful recovery as needed. Druva’s unique approach of combining Kubernetes-level stateful backup with the AWS resources provides the most comprehensive AWS backup solution for Kubernetes. Snapshots can be restored to a new location for migration, cloning, or troubleshooting of the production workloads. 

In this blog, we’ll explain the ‘Why and How’ of protecting your Kubernetes workloads running within the EKS and custom EC2 clusters using Druva.

Druva solution overview:

Business challenges faced when protecting your Kubernetes applications

  • As container technology is evolving rapidly, enterprises have adopted stateful containers,, which need persistent storage and efficient backups
  • Enterprises need to restore critical applications on EKS and custom EC2 clusters
  • Enterprises’ current backup solutions focus on the Kubernetes admin, but lack focus for DevOps, cloud admins, and application owners

A successful protection plan should simply add their Kubernetes applications to automated backup policies, which can be scheduled per organizational requirements. This gives the customer the ability to restore backups whenever required while taking advantage of all the merits of the AWS cloud.

A good Kubernetes protection solution should cover the following 

  • Security and Ransomware: A sharp increase in the adoption of Kubernetes among enterprises has led to security and ransomware concerns to protect workloads. Backing up K8s applications to cross-region and cross-account and restoring it whenever required always give an upper hand to the enterprises.
  • Data Reuse: Application mobility and migration of Kubernetes workloads allows cloning the K8 applications for maintenance, investigation, and troubleshooting.
  • Avoid Downtime: Critical workloads that are hosted on the Kubernetes require zero downtime, hence why the ability to make copies and restore in cross clusters and regions are important.
  • User Awareness: Support various roles involved in handling Kubernetes for enterprise, including Kubernetes admins, DevOps, cloud admins, and application owners.
  • Compliance and Controls: Support for data residency requirements and operational needs. AWS Identity and Access Management (IAM) roles are account-specific, and AWS Key Management Service (KMS) keys for data encryption are region-specific.

Druva is here for you

Druva’s protection plan for application groups within the Amazon EKS and custom EC2 clusters is built upon AWS. It integrates natively with the user’s AWS environment to provide secure access to the EKS and custom EC2 clusters for backup and restore capabilities using an intuitive UI.

With Druva’s Kubernetes protection solution:

  • Automatic snapshots of Kubernetes applications are replicated cross-account and cross-region
  • Backups created by EBS snapshots are incremental in nature
  • Multiple application groups within the clusters can be backed up and restored at once
  • Recipes can be assigned to the backup copies to determine the state of data in the backups
  • Retention of snapshots even after deletion of the persistent volume
  • Support for multi-admin — Kubernetes admin, application admin, and cloud admin
  • Simple UI to register clusters with Druva, install helm commands, schedule backups, monitor and visualize backup health, and recovery updates

What are application groups in a Kubernetes EKS and custom EC2 cluster?

An application group is a Kubernetes application in your EKS and custom EC2 clusters, which are defined by the application admin, that are eligible for backup and restore. Example: WordPress server + MySql Database together constitute an application group. Within an application group, there can be more than two applications, and within one cluster there can be many application groups. These application groups can be identified easily in the UI with the application group name and application UID on the application groups listing page.

Applications are the primary Kubernetes protection objects and help determine the data protection workflow in line with your business requirements. The components of an application can include one or more of the following:

  • Kubernetes resources 
  • Persistent volumes 
  • External data stores that are not Kubernetes volumes 

What are recipes?

Recipes are labels that define the state of data by which the backup must be performed, as defined by the application admin. Recipes are the backup definition criteria for the data state upon backup execution, for example application-consistent, crash-consistent, etc.

How to protect applications in your EKS and custom EC2 clusters

Step 1: Grant permission for cluster discovery

1. Log in to the Druva console and navigate to Resources > Kubernetes.

2. Click Register New Cluster and select Simple if you want to install a public connection in your AWS Account. OR select Advanced if you want to install a private connection router in your AWS account (please only choose private subnets for this deployment).

3. On the Register New Cluster page, do one of the following: 

  • If you have not yet deployed Druva Backup Operator, click Prerequisites to verify the prerequisites. Then proceed with step 4.
  • If Druva Backup Operator has already been deployed, proceed to the Activate Druva Backup Operator section.

4. Select the appropriate VPC, subnet, and security group from the available list, and click Get CF Template to copy or download the CloudFormation template. Likewise, you can directly navigate to the AWS console with a pre-configured URL for running the CloudFormation template.

Step 2: Execute Helm commands to fetch Helm charts 

Once VPC is deployed, you will need to authorize Helm to fetch the chart repository. You can simply run these commands in your AWS CLI.

Step 3: Install backup CRDs

The following commands will help to export charts for Druva backup CRDs.

Step 4: Execute helm command to install backup operator

Execute Helm commands to deploy Druva Backup Operator and discover new clusters or specific applications.

Step 5: Check the cluster listing page

  • Registered clusters will show the connection status with Druva as connected.
  • If for any reason the cluster registration doesn’t connect successfully, there will be an error state.

Step 6: Create backup policies with application groups

  • Users can create backup policies to schedule backups of application groups.
  • Just like other AWS workloads, users can add application groups using Include Resource within Backup Policy > Resources.
  • Users can also exclude application groups that aren’t required as part of the automated policy.

Step 7: Assign recipes to each application group

  • Users can map recipes (e.g: application consistent, crash consistent, etc) to the application groups selected within the backup policy in Backup Policy > Additional Options.

  • Once the backup policy is successfully created and run as per the schedule, the backups are created within the selected accounts.

Step 8: Restore application groups

  • Navigate to Kubernetes > Backups and select the backups that need to be restored to the same region, but different cluster or namespace.


Druva’s Kubernetes support is available to existing Enterprise and Elite customers on request and new customers beginning October 2021. Please reach out to customer support to access these features. 

Next steps

With the rapid growth in usage of Kubernetes workloads, enterprises need to ensure their mission-critical applications on EKS and custom EC2 clusters have a solution that is designed and developed to protect Kubernetes workloads.

Druva offers a simple UI and workflow to manage and protect your applications within Amazon EKS and custom EC2 clusters. Multiple backup copies of application groups can be stored in multiple regions/accounts for better availability using automated and scheduled policies. 

Backup copies just get your work halfway done, it is equally important to restore application groups for business continuity. Druva not only checks all the boxes when protecting your Kubernetes workloads, but also helps you manage your applications by cloning them to another account for troubleshooting, debugging, and testing.

If you are interested in learning more about Druva’s Kubernetes solution, contact us today, and visit the Kubernetes page of the Druva site.