Ctrlk

29 Working with Elastic Kubernetes Service (EKS)

Back up and restore entire EKS clusters and selected Namespaces.

The N2W platform provides a built-in Kubernetes backup and recovery solution for AWS EKS clusters. This capability gives you the ability to protect Kubernetes resources, namespaces, and persistent volumes, while allowing you to manage backups and restores directly from N2W, just like any other AWS resource.

N2W supports backing up entire EKS clusters or selected namespaces, which is useful for:

  • Application-level protection

  • Avoiding system or control-pane namespaces

Restore the backups to the same or different EKS clusters with the same namespace or a different one, at your choice.

29.1 Overview

N2W simplifies Kubernetes backup and restore workflows. You can:

  • Add EKS Cluster or Namespaces to a policy like any other AWS resource.

  • Back up entire an entire EKS Cluster, including:

    • All namespaces

    • Cluster-scoped resources

    • EBS snapshots of Persistent volumes

    • Kubernetes manifests (to S3)

  • Back up specific Namespaces only

  • Restore anywhere:

    • To the same or new account

    • To the same or new region

    • To the same or new cluster

    • Rename namespaces

  • Combine EKS backups with other AWS services in a single policy. In the same policy, you can back up:

    • An EKS namespace containing a WordPress deployment together with

    • The associated AWS RDS database instance

29.2 Backup Modes

N2W supports two backup modes for EKS:

Standard Mode (EBS Snapshots)

  • Uses AWS EBS snapshots for persistent volumes

  • Provides fast backup and restore performance

  • Supported only within the same AWS Region

Portable Mode (Kopia – Cross-Region / Cross-Account)

  • Uses file-level backups for persistent volumes

  • Stores backup data in Amazon S3

  • Supports recovery across regions, accounts, and clusters

29.3 Cross-Region Backup Flow (Kopia)

In Portable (Kopia) mode:

  1. Kubernetes resources (manifests) are backed up and stored in Amazon S3.

  2. Persistent volume data is backed up at the file level and stored in Amazon S3.

  3. If Disaster Recovery (DR) is enabled in the policy, backup data is replicated to a designated DR S3 bucket.

  4. Both metadata and data are stored under a unique path per cluster and policy.

This architecture ensures that backups are fully portable and can be restored in different environments, including cross-region and cross-account scenarios.

29.4 Prerequisites

Before adding EKS resources to a CPM policy, the following steps must be completed:

  1. Install Velero on each EKS cluster you want to protect.

Velero is an open-source tool that provides backup and restore for Kubernetes clusters. It backs up Kubernetes resources and persistent volumes, saves them in S3-compatible storage, and lets you safely restore clusters when needed.

Velero must be installed on:

  • Every source EKS cluster you back up.

  • Every destination EKS cluster you restore into.

See Appendix H for the Velero Installation Guide.

  1. Configure the Velero backup storage (S3).

During Velero installation, specify:

  • An S3 bucket that stores your Kubernetes manifests.

  • The velero-plugin-for-aws, which enables Velero to create EBS snapshots.

  1. Ensure that the following IAM permissions and access are set:

  • Kubernetes RBAC (EKS Access Entry & Policies). Configure an EKS Access Entry for the EC2 instance's IAM role with appropriate policies:

    • Required: Velero Namespace Admin Access

      • Policy: AmazonEKSClusterAdminPolicy

      • Scope: namespace - specifically the velero namespace

      • Purpose: Allows creating and managing Velero backup/restore resources

    • Optional: Cluster-Wide Read Access

      • Policy: AmazonEKSViewPolicy

      • Scope: cluster

      • Purpose: Enables viewing pods, deployments, and services across all namespaces for monitoring and observability

  • Velero S3 and IAM Roles for Service Accounts (IRSA) Configuration. Ensure that the Velero pod uses IRSA with permissions to:

    • Access the Velero backup S3 bucket

    • Create and manage EBS snapshots

    • The IAM role trust policy must allow the Velero Service Account to assume the role via the cluster’s OIDC provider

    • IRSA requires an OIDC identity provider to be associated with the EKS cluster

  1. Ensure Network connectivity between the VPC and EKS API endpoint.

  2. Set EKS Access Entry: Associate the IAM role with EKS access policies.

  3. Enable Security Group: Allow outbound HTTPS (port 443) to the EKS cluster API endpoint.

29.5 Defining EKS Policies

To define EKS policies, see section ‎4.2. Select EKS Clusters or EKS Namespaces from the Backup Targets menu.

29.6 Recovering EKS

N2W provides flexible recovery operations for EKS, enabling restoration of full clusters or selected namespaces across clusters, accounts, and regions.

29.6.1 Recovery Scope

Supported recovery operations include:

  • Restore the entire EKS cluster backup, including:

    • All namespaces

    • All workloads and resources

    • Persistent volumes

    • Optional cluster-scoped resources

    • Restore to the same or a different account

    • Restore to the same or a different region

  • Restore only selected namespaces, which allows restoring workloads into the same or a different EKS cluster, account, or region:

    • One or multiple namespaces

    • Optionally rename namespaces during recovery

Cluster-Scoped Resources:

  • During recovery, you can choose whether to restore cluster-scoped resources, such as:

    • ClusterRoles

    • ClusterRoleBindings

    • CustomResourceDefinitions (CRDs)

When to enable the Cluster-Scoped Resources option:

Scenario

Recommendation

Restoring into the same cluster

Usually leave unchecked

Restoring into a new empty EKS cluster

Recommended to enable

29.6.2 Recovery Flow

To perform cross-region or cross-account recovery:

  1. Ensure the target EKS cluster has Velero installed (including node-agent for Kopia).

  2. Select a backup in N2W.

  3. Choose the target account, region, and cluster.

  4. Select the recovery source (source bucket or DR bucket).

  5. Start the recovery.

During recovery:

  • Kubernetes resources are restored from S3.

  • Persistent volume data is restored from the Kopia repository.

  • The required Backup Storage Location (BSL) is automatically created or updated.

Recovery is supported for any cluster with access to the selected S3 bucket.

29.6.3 Recovery Behavior and Constraints

  • EBS Snapshot backups restore volumes directly from AWS snapshots (same region only).

  • Kopia backups restore volume data from S3 (cross-region and cross-account supported).

  • Kubernetes resources and volume data are restored together to recreate the application environment.

  • Kopia and EBS snapshot modes are mutually exclusive per backup.

  • Cross-region recovery requires Kopia backups and DR configuration.

  • Both Kubernetes metadata and volume data must be available in S3.

  • Target cluster must have the required CRDs and Velero components installed.

29.6.4 Recovery Procedure

To recover EKS clusters or EKS namespaces:

  1. In the Backup Monitor, use the Cloud buttons to display the AWS backups.

  2. In the Search backups box, enter a string to search by. The string can be part of the resource ID or part of the resource tag value.

  3. To filter by resource type, select a resource type in the By Instance list, such as EKS Cluster.

  4. Select and then choose a backup in the list and then select Recover. A list of clusters opens.

  5. Select a Cluster Name.

  6. Select a cluster, or enter a resource ID, or name in the Search by Resource box.

  7. In the Restore from list, select the repository where the backup is located.

  8. In the Restore to Account list, select the AWS account where the backup should be restored.

  9. In the Restore to Region list, select the region where the backup should be restored.

  10. Select Recover.

To recover namespaces:

  1. To recover specific namespaces, select the Namespaces tab.

    1. To include Cluster-Scoped Resources, select Include Cluster Resources.

    2. In the Namespace Name list, select one or more Names.

    3. For each Name, change the Target Namespace Name, if required.

  2. Select Recover.

29.7 EKS Disaster Recovery (DR)

N2W’s EKS DR (Disaster Recovery) solution allows you to recover your data and servers in case of a disaster. N2W flexibility allows users to copy their backup snapshots to multiple regions and to various accounts, combining cross-account and cross-region options.

Cross-account recovery requires appropriate IAM and S3 permissions, see section 29.7.2.

29.7.1 EKS DR Configurations

To add a new EKS disaster recovery configuration:

  1. In the main navigation menu, select EKS DR Configurations.

  2. Select New.

  3. Select a user.

  4. In the Backup Bucket section, select the account, region and bucket to back up.

  5. In the DR Bucket section, select the account, region and bucket for disaster recovery.

  6. Select Save. The new configuration is added to the list.

To edit or delete an EKS disaster recovery configuration:

  1. In the main navigation menu, select EKS DR Configurations.

  2. Select a configuration.

  3. Select Delete or Edit.

29.7.2 Cross-Account DR Prerequisites

Cross-account disaster recovery requires appropriate permissions between the source and destination accounts.

S3 Bucket Policy (Destination / DR Account)

The destination S3 bucket must allow access to the IAM role used in the source account.

IAM Policy (Source Account – Velero IRSA Role)

The IAM role used by the Velero server (IRSA) in the source account must be granted access to the DR S3 bucket.

Attach a policy similar to the following to the IAM role used by the velero-server pod:

  • Replace <AccountId> and <RoleName> with the IAM role used by CPM/Velero in the source account.

  • Replace <BucketName> with the DR destination bucket

  • The first statement grants bucket-level permissions (listing and location)

29.8 Kopia Maintenance and CLI

When using Portable (Kopia) backups, backup deletion occurs in two stages due to the repository’s deduplicated design.

29.8.1 Backup Deletion Behavior

When a backup is deleted, Velero removes:

  • Backup metadata from Amazon S3

  • Kopia snapshot references

The underlying deduplicated data (blobs) remains in S3 until it is no longer referenced by any backup and is later removed by maintenance.

29.8.2 Kopia Maintenance

Kopia uses a shared repository model. Data is deleted only when no longer referenced.

  • A scheduled maintenance task runs periodically (typically every 24 hours).

  • The task performs garbage collection (GC) and removes orphaned data.

  • Without maintenance, unused data remains in Amazon S3.

In some environments, automatic maintenance may be delayed or not executed, requiring manual intervention.

29.8.3 Manual Maintenance (CLI)

In certain Velero versions (for example, v1.16.1), automatic Kopia maintenance may not run reliably. In these cases, orphaned backup data in S3 may not be cleaned up automatically. As a solution, manual maintenance can be performed using the Kopia CLI.

Prerequisites:

  • No Velero backup or restore operations in progress.

  • No processes accessing the Kopia repository.

  • If the repository is shared, all clusters must be idle.

Command:

The --safety=none flag disables built-in safety checks. It must only be used when no active operations are accessing the repository. Running this command concurrently with backup or restore operations may result in repository corruption.

Previous28 Using Wasabi StorageNextAppendix A -Recommended Configuration for Copy to S3

Last updated

Was this helpful?