Amazon Elastic File System (EFS) is a simple, scalable and fully managed file storage service to support the storage and throughput needs of your Kubernetes applications. Amazon EFS is designed to be highly available and durable, however your EFS data can still be prone to data loss, data corruption, and have compliance issues. Amazon EFS Backup and Restore of data helps protect against data loss due to hardware failures, accidental deletion, ransomware attacks, or other types of disasters. Depending on your industry or regulatory requirements, companies may be required to maintain copies of their data for a certain period of time. In the event of a disaster, having EFS backups can help recover data and get the applications up and running again more quickly.
Given it is a best practice to regularly back up your data, how can you best accomplish that for Amazon EFS volumes used by your Amazon Elastics Kubernetes Service (EKS) applications? AWS recommends that you do your EFS backups with AWS Backup, given EFS does not have the snapshot feature like EBS does. However, what they don’t tell you is that approach will not provide you with EKS aware recovery capabilities like per namespace, nor will it provide you with an application-consistent backup and restore point for your entire Amazon EKS application.
In this blog you will learn CloudCasa fully supports Amazon EFS backup as part of protecting your Amazon EKS clusters, and how it provides granular restore options with dynamic cluster creation to support disaster recovery and test/dev use cases.
What is Amazon EFS and How Does it Work?
Amazon EFS is one of three main storage services offered by Amazon. It is a file sharing service that lets you manage file shares, like those used on traditional networks, and mount them on a compute Instance or on-premises machines using the NFS protocol.
The elastic part of an Amazon EFS means its storage capacity can be automatically scaled up (add more storage) or scaled down (shrink storage capacity) as folders and files are added to or removed from the system.
By default, every EFS object (such as directory, file, and link) is redundantly stored across multiple Availability Zones (AZs) for file systems using Standard storage classes.
Benefits of Dynamic Provisioning in Amazon EFS
Dynamic provisioning allows users to automatically create an Amazon EFS when deploying applications to Amazon EKS. This can be useful for several reasons:
- Cost savings: It allows users to create file systems on demand by automatically scaling up or down as needed and avoid paying for idle resources that are not being used.
- Reduced complexity: It can simplify the process of deploying applications that require file systems, as users can create EFS as part of the deployment process.
- Improved efficiency: It can help save time and resources by only creating an EFS when they are actually needed, without having to manually create them ahead of time.
- Increased flexibility: It can help ensure that you always have the necessary file systems available when deploying applications, as they will be created automatically as needed.
Amazon EFS Backup of Dynamically Provisioned Persistent Volumes in EKS
CloudCasa supports Kubernetes backup and restore for applications using the Container Storage Interface (CSI), including support for Amazon EBS (Elastic Block Store). A CSI driver provides an interface that allows Kubernetes applications to manage the lifecycle of container storage, including the snapshot and copy operations needed for backup.
The Amazon EFS CSI driver supports both dynamic provisioning and static provisioning. Currently dynamic provisioning creates an access point for each Persistent Volume. This means an Amazon EFS has to be created manually on AWS first and then it should be provided as an input to the storage class parameter.
We will now show how a dynamically provisioned volume created through EFS access points can be backed up and restored. For the setup, we have an EKS cluster created and configured with the Amazon EFS CSI Driver (aws-ebs-csi-driver).
The following screenshots show the description of the Storage class, Persistent volume claim, Persistent volume and Pod used for the examples in this blog.
- Installed Amazon EFS CSI Driver
2. Amazon EFS Storage Class
3. Amazon EFS Persistent Volume Claim
4. Amazon EFS Persistent volume
5. Amazon EFS Backup Test Pod
A few points to consider in configuring your Amazon EFS for use in EKS:
- When you create an EFS to use, be sure to add mount targets for all the subnets that your nodes are in.
- In the Security Group used by the EFS volume, be sure add a new rule of Type NFS and protocol TCL to allow CloudCasa to access the EFS volumes.
Steps to be performed on CloudCasa for the EFS Backup
The Amazon EFS CSI driver does not support the CSI snapshot feature like the Amazon EBS CSI driver does. For Amazon EBS backups, the EBS CSI driver is used to take a snapshot and then CloudCasa copies it to create a backup recovery point. Instead, for Amazon EFS backups in EKS, CloudCasa uses the CSI Copy operation to create a backup copy of an EFS Persistent Volume.
Let’s walk through the process of the EFS CSI Copy in CloudCasa:
- Define a Copy Job for the Cluster and Run the Job as shown below.
For this example, we skipped the steps of using pre- and post-App Hooks for application consistency. In CloudCasa, using App hooks is very simple with the use of pre-built templates, as can be seen here for creating MySQL backups.
2. When the job has successfully completed, the copied PV can be seen in “PV Details (Copy)” tab in the Job activity.
Now that you have a successful Amazon EFS backup on EKS, you can use this EFS backup copy to restore your deployment to the same EKS cluster and the same namespace, or to the same cluster and a different namespace, or to a completely different cluster. Users can also perform Restore when the namespace is deleted from the EKS cluster in the same way as demonstrated below.
Using the Amazon EFS PV Backup to Restore to Same Cluster but a Different Namespace
- From Restore cluster, choose the appropriate Recovery Point to restore a cluster or a specific namespace in the Amazon EFS backup.
2. Select the Resources to restore which could be all of the namespaces or a subset of them.
3. Next you can restore to an existing cluster or dynamically create a new one to restore to.
4. In the Activity logs as shown below, you can find the details that the Restore job is executed successfully.
5. Upon successful completion of the restore operation, you can use the CLI to see the successfully restored EFS PV backup done by CloudCasa.
a. Restored Cluster Namespace
b. Restored EFS Persistent Volume Claim
c. Restored EFS Persistent Volume
And that is how easy it is to use CloudCasa to perform Amazon EFS backup and restore operations for your Amazon EKS clusters that are using an Amazon EFS filesystem.
Check out our blog on why you must upgrade to CloudCasa from Velero. Learn more about Comprehensive Backup Service for Amazon EKS with CloudCasa by Catalogic.
You can try the free service plan for CloudCasa, no strings attached. We’d be happy to connect with you over a call and talk through your issues in using Amazon EFS backup for EFS PVs. If you want to see a custom demonstration or just have a chat with us, feel free to get in contact via firstname.lastname@example.org.