EKS Backup: Tutorial &  Best Practices

AWS EKS backup with Trilio

Trilio for Kubernetes is a data protection and backup solution specifically designed for Kubernetes environments. It provides backup and recovery capabilities tailored for these dynamic, container-based infrastructures. 

Trilio gives you the power and flexibility to back up all the applications deployed in your EKS cluster or select a specific namespace, label, Helm chart, or operator as the scope for your backup operations. All of that functionality is encapsulated within a convenient interface utilizing Kubernetes custom resource definitions (CRDs) specified in YAML.

Let’s examine how much simpler this configuration can be with automated solutions such as Trilio. After the initial setup, a namespace-scoped backup can be configured using the following commands with the example namespace scope BackupPlan.

First, let’s create ns-backupplan.yaml. Save the following into a text file using your editor of choice.

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
name: ns-backupplan
spec:
backupConfig:
target:
namespace: default
name: demo-s3-target

Now, we’ll apply it with this command:

kubectl apply -f ns-backupplan.yaml

Next, we create sample-schedule.yaml:

kind: "Policy"
apiVersion: "triliovault.trilio.io/v1"
metadata:
  name: "sample-schedule"
spec:
  type: "Schedule"
  scheduleConfig:
    schedule:
      - "0 0 * * *"
      - "0 */1 * * *"
      - "0 0 * * 0"
      - "0 0 1 * *"
      - "0 0 1 1 *"

Next, we apply the file:

kubectl apply -f sample-schedule.yaml

Now we create sample-retention.yaml:

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-retention
spec:
  type: Retention
  default: false
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

And then apply it:

kubectl apply -f sample-retention.yaml

Now we create sample-backup.yaml:

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
  annotations:
  finalizers:
  - backupplan-delete-finalizer
  generation: 2
  name: eks-backupplan
  namespace: eks-backup
spec:
  backupConfig:
    schedulePolicy:
      fullBackupCron:
        schedule: ""
      incrementalCron:
        schedule: ""
    target:
      apiVersion: triliovault.trilio.io/v1
      kind: Target
      name: trilio-target-eks
      namespace: eks-backup
  backupPlanComponents: {}
  retainHelmApps: false

And apply this file as well:

kubectl apply -f sample-backup.yaml

This configuration would encapsulate a full namespace backup, which can be restored using the restore procedure.

Once the sample-backup.yaml has been applied, the following screenshot is what the backup plan looks like in the UI.

Developing an EKS backup strategy

The ideal choice of EKS backup strategy depends on factors such as the criticality of applications, cost considerations, and recovery time objectives (RTOs). Organizations may opt for a combination of these strategies to strike the right balance between data protection, cost-effectiveness, and operational efficiency.

When crafting an EKS backup strategy, having specific goals in mind is important. We’ll discuss three key objectives: disaster recovery, application mobility, and data protection. These objectives guide how to design backup plans and procedures in EKS. Each goal serves a distinct purpose, helping ensure that the EKS setup is resilient, flexible, and secure, addressing different scenarios and needs for containerized applications.

Typical backup strategy objectives

Disaster recovery (DR)

Disaster recovery is all about preparing for worst-case scenarios such as hardware failures, data corruption, or even regional outages. In this context, a robust EKS backup strategy ensures that we can quickly restore our EKS cluster to a known good state.

Backup levels for disaster recovery: Full-cluster backups and control plane backups are crucial. Full-cluster backups capture everything, while control plane backups safeguard the control plane components. Node-level backups provide node-specific recovery options in case of hardware issues, and data volume backups protect critical application data.

Application mobility

Application mobility focuses on the seamless movement of applications across different environments or AWS regions. This goal often comes into play when you need to scale or migrate applications without disruption.

Backup levels for application mobility: Full-cluster and application-level backups play key roles here. Full-cluster backups ensure that the entire cluster can be moved, while application-level backups help package and move specific applications with their configurations and data.

Data protection

Data protection focuses on safeguarding your application data, ensuring its availability, integrity, and compliance with regulatory requirements. It’s crucial for maintaining the trust and continuity of your services.

Backup levels for data protection: Data volume backups are of paramount importance and focus on preserving your application’s data, ensuring that you can recover it if it is lost or corrupted. Application-level backups can also be used to protect application-specific configurations and data.

Disaster recovery for EKS

The ability to recover from disasters is necessary to ensure uninterrupted business operations. Organizations require a well-defined DR strategy when managing one or multiple applications. Such strategies can be stored in Git as a source of truth and managed using the GitOps workflow, ensuring consistency and reliability. 

Visualized examples of disaster recovery plans

Challenges with critical applications

Configuring disaster recovery for critical applications presents one of the most significant challenges for Kubernetes administrators. Some key challenges include:

• Managing complex application dependencies: Ensuring the accurate recovery of intricate dependencies is crucial to prevent disruptions in critical application functionality.
• Configuration and secrets management: Proper disaster recovery requires the precise restoration of configurations and secure handling of secrets, such as API keys and passwords.

Turn-Key Disaster Recovery Plans 

To address these challenges, it is ideal to implement a simple turn-key solution that can back up critical applications along with their dependencies and let you restore multiple applications or namespaces to a different cluster in parallel.

The Trilio DRPlan feature lets users restore multiple applications and namespaces efficiently within a single workflow, facilitating the seamless resumption of business operations. The process is made user-friendly through a management console located within the destination cluster.

Through this feature, users can create and execute various DRPlans tailored to the criticality of applications. These plans can source data from multiple targets or backup locations, ensuring flexibility in disaster recovery. Notably, the DRPlan is stored within the destination cluster, enabling execution even when the source cluster is inaccessible.

Application mobility with EKS backups

In Kubernetes deployments, we use three important methods to manage applications:

• Label-based
• Helm-based
• Operator-based

Each method relies on a distinct Kubernetes working mechanism and offers specific advantages. Trilio’s application-aware backup system leverages those standard capabilities and implements an intelligent and holistic application mobility solution. Let’s review that in detail:

Visualized examples of application mobility

Label-based applications

For label-based applications, Trilio relies on user-defined labels associated with application resources. During the backup process, the system lists all Kubernetes resources matching the specified labels and identifies resource dependencies, ensuring comprehensive backups. For example, if a deployment bears the specified label, the system ensures that associated resources like service accounts are also included in the backup to maintain consistency.

Helm-based applications

In the case of Helm-based applications, the backup strategy should operate on the Helm release name as input. Moreover, if the Helm release includes dependent Helm subcharts, the backup strategy should take care of them as well. 

In such cases, Trilio’s application mobility system intelligently decodes the Helm release secret within the same namespace to identify the associated resources. After that, it extends the backup to encompass resources from these subcharts. During restoration, the application is reconstructed as a Helm chart, offering flexibility and treating the entire application as a new Helm release.

Operator-based applications

Operator-based applications typically consist of custom resource definitions (CRDs) and controllers. Trilio facilitates backup by considering operator resources, custom resources, and application resources as input. Within operator resources, it can identify resources based on user-defined labels or Helm release names, depending on the operator’s installation method. For custom resources, Trilio requires the CR name and its associated CRD, which includes the GroupVersionKind (GVK). 

To identify application resources, the system relies on the reconciliation process initiated by the operator. It automatically detects these resources using owner references from the CR. In cases where operators do not establish owner references, the system uses the provided labels to identify the associated resources.

Data protection on EKS

Robust data protection is essential to safeguard cloud-native applications from potential data corruption or malicious activities that can jeopardize production data. Leveraging advanced backup and recovery technology, like that Trilio offers, is a powerful solution to address these critical concerns.

Visualized examples of data protection on EKS

Point-in-time backups for data protection

One of the fundamental pillars of data protection within EKS is the concept of point-in-time backups. These backups capture the state of your cloud-native applications at specific moments in time, allowing you to revert to a known, healthy state in case of data corruption, accidental deletions, or malicious attacks like ransomware. Creating point-in-time backups establishes a secure and restorable copy of your applications and their data, reducing the risk of prolonged downtime and data loss.

Restoring data integrity

Ensuring data accuracy is a critical aspect of EKS backup. Highly accurate backup data guarantees that it faithfully represents the state of the original resources at the time of backup. Inaccuracies in backup data can lead to data corruption or loss during the restoration process, undermining the reliability of disaster recovery efforts. Meticulous attention to data accuracy is essential for maintaining the integrity of EKS backups.

Data consistency is another vital dimension of EKS backup. Consistency ensures that backup data is coherent and free from discrepancies, preventing issues that may arise from incomplete or mismatched data during recovery. Maintaining data consistency throughout the backup lifecycle is imperative to minimize disruptions and maintain the effectiveness of data protection strategies for EKS clusters.

Proactive data protection measures

The prevalence of ransomware attacks highlights the need for proactive data protection measures. Organizations must be prepared to defend against such threats by implementing a robust backup and recovery strategy. Regularly scheduled point-in-time backups coupled with secure storage practices provide a proactive defense against data loss and ensure that critical applications and their data are shielded from potential threats. 

Here are a few examples of such measures:

• Enabling encryption: Implementing encryption for EKS backups adds an additional layer of security, safeguarding data from unauthorized access or breaches. Encryption measures, such as AWS Key Management Service (KMS), help protect backup data both in transit and at rest.
• Access controls: Robust access controls and policies should be in place to restrict unauthorized access to EKS backup data. By defining granular permissions and role-based access, organizations can ensure that only authorized personnel can manage and restore backups.
• S3 data lock features: including S3 Object Lock, offer an additional safeguard against accidental or intentional data deletions, ensuring data integrity over time. It’s worth noting that Trilio can seamlessly interface with S3 Object Lock, allowing for smooth integration and proper functioning with locked objects. This capability enhances data protection efforts, providing organizations with added assurance in their backup and recovery processes.