[Blueprints, 02-at-scale] Best Practice for EFS PV backup/restore

[carlosrodlop]

Currently, there is not a EKS Best Practice recommendation for EFS PVs but it does for EBS (Velero).

The EFS backup/restore based on the AWS Backup (tutorial) is not prepare for EKS (Restore is happens in a different drive). See

• support dynamic recovery of PV/PVCs from existing file system kubernetes-sigs/aws-efs-csi-driver#476
• Backup and Restore a Access Point ID kubernetes-sigs/aws-efs-csi-driver#641

[DraganBocevski]

Some excerpts from the AWS documentation:
https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-efs.html

For full restore:
AWS Backup does not support destructive restores with Amazon EFS. A destructive restore is when a restored file system deletes or overwrites the source or existing file system. Instead, AWS Backup restores your file system to a recovery directory off of the root directory.

For item level restore:
AWS Backup creates a new Amazon EFS directory (aws-backup-restore_datetime) off of the root directory to contain the items. The full hierarchy of the specified items is preserved in the recovery directory.

[carlosrodlop]

Using AWS Backsup for EFS would require the following steps:

Restore the AWS Backup into existing EFS drive

1.- Mount the EFS locally to check the access points
2.- Set replicas to zero to the controller to restore
3.- Use mv to replace name of backup access point (recovery...) by current name used by Aplications
4.- set replicas to 1

Restore the AWS Backup intoa new EFS drive

Same as before but running the terraform files to use an existing EFS id (AWS backup restore) to be used for EFS CSI Drive for EKS cluster.

The existing Access Points names will be empty no content

[carlosrodlop]

EFS Back script example (internal): https://github.com/cloudbees/tsm-dcs-solutions/tree/main/cloudbees-ci/jira-tickets/TSM-1654_restore-pvc-from-efs