Design Considerations - EFS-to-EFS Backup Solution

Design Considerations

Incremental Backups

This solution captures the state of an Amazon EFS file system at a point in time. If you specify a backup window long enough to copy your entire file system, the solution will copy the entire file system or the entire subdirectory the first time it creates a backup. When the solution creates future backups for that file system, it copies only the files and directories that have changed, or been added or removed since the last backup.

We recommend that you launch the solution for the first time with a large instance type, and a backup window large enough to copy your entire file system. After the first backup completes, update the running stack with a smaller instance type and backup window to reduce costs and save burst credits.

Consistent Backups

This solution uses fpsync, a tool that synchronizes directories in parallel using fpart (sorts and packs files into partitions) and rsync (a file-copying tool), to copy the source file system to the backup file system. Note that this solution might exclude any data written while fpsync or the backup process are running. To ensure consistent backups, we recommend that you do not perform writes on the source Amazon EFS file system for the duration of the backup process. Note that after the solution creates the initial backup, future backups are incremental and will take less time to complete.

Sizing and Capacity

This solution uses a single Amazon Elastic Compute Cloud (Amazon EC2) instance (c5.xlarge). The maximum throughput you can drive per NFS client on an Amazon EC2 instance is 250 MB/s. All Amazon EFS file systems, regardless of size, can burst to 100 MiB/s of throughput, and those over 1 TiB large can burst to 100 MiB/s per TiB of data stored in the file system. The size of the file system determines the portion of time a file system can burst. Amazon EFS uses a credit system to determine when file systems can burst. For more information about how the credit system works, see Amazon EFS Performance in the Amazon EFS User Guide.

Large file systems might cause this solution to hit the Amazon EC2 instance throughput limit. Customers who want to back up large file systems can launch multiple deployments of the solution with different source prefixes that point to different locations in the source file system. For example, a customer with a large Amazon EFS file system that contains a home directory and an appdata directory can deploy two solution stacks: one that points to the home directory (<efs-mount-point>:/home) and one that points to the appdata directory (<efs-mount-point>:/appdata). Customers can also launch multiple deployments of the solution to back up multiple Amazon EFS file systems in an AWS Region.

We recommend that you use a rigorous performance testing and optimization process to choose the right instance type for your use case. For more information, see Appendix A.

File systems with a large number of files (around one million or more) can also cause the backup process to fail. For more information about file systems with a large number of files, see Appendix D.

Burst Credits

This solution will consume burst credits while creating backups, which could impact your production workload. We recommend that you verify that you have sufficient burst credits available before you start the backup process. You can also change the solution’s default Amazon EC2 instance type to change how the solution consumes burst credits. For more information, see Appendix A.

Granular Backups

The EFS-to-EFS backup solution enables customers to specify any valid directory from their source file system. To back up part of an Amazon EFS file system, customers can specify the applicable subdirectory as the source, and the solution will copy only files and directories from that subdirectory. Continuing from the previous example (see Sizing and Capacity), if a customer specifies the appdata directory as the source, the solution will copy only the appdata directory to the backup file system.


By default, this solution leverages Amazon EFS encryption so you can encrypt your backups at rest. Amazon EFS integrates with AWS Key Management Service (AWS KMS) customer master keys (CMKs), and uses an industry-standard AES-256 encryption algorithm to encrypt EFS data and metadata. For more information, see Cryptography Basics in the AWS Key Management Service Developer Guide.


The EFS-to-EFS backup solution includes optional dashboards that allow you to visualize Amazon EFS I/O data for both the source and backup file systems during the backup and restore processes. To view the dashboards, open the Amazon CloudWatch console and select Dashboards.

Cross-Account Backups

This solution will not back up Amazon EFS file systems that are mounted from a different account or VPC by default. To back up these types of file systems, you must modify the solution. For more information, see Mounting EFS File systems from Another Account or VPC in the Amazon EFS User Guide.

Solution Updates

EFS-to-EFS backup version 1.5 uses the most up-to-date Node.js runtime. Version 1.4 uses the Node.js 8.10 runtime, which reaches end-of-life on December 31, 2019. In January, AWS Lambda will block the create operation and, in February, Lambda will block the update operation. For more information, see Runtime Support Policy in the AWS Lambda Developer Guide.

To continue using this solution with the latest features and improvements, you can update the stack.

Regional Deployment

This solution uses the Amazon EFS service, which is currently available in specific AWS Regions only. Therefore, you must launch this solution in an AWS Region where Amazon EFS is available. (For the most current Amazon EFS availability by region, see Also, you must deploy this solution in the same AWS Region as your source Amazon EFS file system. You can launch multiple deployments of the solution in a single AWS Region to back up multiple Amazon EFS file systems in that region.