# 29 Working with Elastic Kubernetes Service (EKS)
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.
{% hint style="success" %}
See [Appendix H](/user-guide/appendix-h-velero-installation-guide.md) for the *Velero Installation Guide*.
{% endhint %}
2. **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.
3. **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
4. **Ensure Network connectivity** between the VPC and EKS API endpoint.
5. **Set EKS Access Entry**: Associate the IAM role with EKS access policies.
6. **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](/user-guide/4-defining-backup-policies.md#id-4-2-policies). 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.
{% hint style="info" %}
* 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.
{% endhint %}
### 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](#id-29.7.2-cross-account-dr-prerequisites).
### 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.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowRoleToListBucket",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::"
},
{
"Sid": "AllowRoleToReadWriteObjects",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/"
},
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::/*"
}
]
}
```
**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:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToDRBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::"
},
{
"Sid": "AllowObjectOpsOnDRBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::/*"
}
]
}
```
{% hint style="info" %}
* Replace `` and `` with the IAM role used by CPM/Velero in the source account.
* Replace `` with the DR destination bucket
* The first statement grants bucket-level permissions (listing and location)
{% endhint %}
## 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:**
```
kopia maintenance run --full --safety=none
```
{% hint style="warning" %}
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.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.n2ws.com/user-guide/29-working-with-elastic-kubernetes-service-eks.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.