AWS Backup / EFS Restore Runbook

Overview

Reusable procedure for restoring an Amazon EFS filesystem from AWS Backup into a new, isolated filesystem for investigation, recovery, file extraction, or validation without modifying the source filesystem.

This procedure also documents common AWS Backup and EFS restore gotchas.

Prerequisites

• AWS CLI installed if CLI access is required
• IAM permissions confirmed for AWS Backup, EFS, and the required S3/AWS resources
• Correct AWS Region identified
• Recovery point identified
• Scratch EC2 instance available for mounting the restored filesystem
• Destination volume has adequate free space for any files being copied locally
• Confirm the restore will not modify the original filesystem

Known Gotchas

1. AWS Backup item path validation can be misleading

For item-level restores, the AWS Backup UI may display a message indicating that the item path must be relative.

The path that validates may require a leading slash:

/path/from/filesystem/root

Do not assume that removing the leading slash will satisfy the validation message.

2. Verify the restore destination

AWS Backup may default to:

Restore to directory in source file system

This can result in data being written back into the original filesystem.

For an isolated recovery or investigation, always select:

Restore to a new file system

Treat this as a mandatory safety check before submitting the restore job.

3. EFS DNS may not work immediately

A newly restored EFS filesystem needs an available mount target before normal EFS DNS resolution works.

If DNS fails:

1. Confirm a mount target exists.
2. Confirm the mount target status is Available.
3. Confirm networking and security groups allow NFS.
4. If necessary, mount using the mount target IP address instead of the EFS DNS name.

4. amazon-efs-utils may not be available

amazon-efs-utils may not be available from the default package repositories on every Ubuntu installation.

For a basic scratch mount, standard NFSv4 can be used:

sudo apt-get install -y nfs-common

Then:

sudo mount -t nfs4 \
  -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport \
  <fs-id>.efs.<region>.amazonaws.com:/ \
  /mnt/efs-restore

5. Vault access policies may block restore jobs

An AWS Backup vault access policy can explicitly deny restore operations.

If the required restore action is denied:

1. Review the vault access policy.
2. Temporarily remove or modify the applicable deny condition.
3. Perform the restore.
4. Immediately restore the original security policy.

Do not leave a temporary security-policy exception in place after the restore.

6. Backup size may represent the entire recovery point

The size displayed for a restore job may represent the full recovery point rather than the specific path being restored.

Do not use the displayed backup size as an estimate of the amount of data contained in a particular item-level restore.

Procedure: Restore to a New Filesystem

1. Identify the Recovery Point

Open:

AWS Backup → Vaults → Recovery Points

Identify:

• Backup vault
• Recovery point
• Backup date/time
• Source filesystem
• Recovery point ID

Record the recovery point before beginning.

2. Verify the Vault Policy

Before starting the restore, confirm the vault policy permits the required restore operation.

If a temporary policy change is required:

• Make the smallest possible change.
• Save the policy.
• Perform the restore.
• Restore the original policy immediately afterward.

3. Start the Restore

Select the recovery point and choose:

Restore

Choose the appropriate restore type:

• Full restore — restore the entire filesystem
• Item-level restore — restore selected paths

For item-level restore, use the path from the filesystem root:

/path/from/root

If the AWS Backup UI requires it, retain the leading /.

4. Select the Restore Destination

For isolated recovery work, select:

Restore to a new file system

Do not select:

Restore to directory in source file system

unless writing into the original filesystem is explicitly intended.

Recommended scratch configuration:

• File system type: Regional
• Performance mode: General Purpose
• Encryption: appropriate approved key
• Restore role: AWS Backup-created/default restore role when appropriate

Submit the restore job.

5. Monitor the Restore

Navigate to:

AWS Backup → Jobs → Restore jobs

Wait for:

Status: Completed

Record the restored filesystem ID.

Do not proceed with mounting until the restored resource is available.

6. Create an EFS Mount Target

For the restored filesystem:

EFS → File systems → Network

Create a mount target in a subnet reachable from the scratch EC2 instance.

Verify:

• Correct VPC
• Correct subnet/AZ
• Mount target status is Available
• Security group permits NFS
• TCP port 2049 is allowed from the scratch instance

7. Mount the Restored Filesystem

On the scratch instance:

sudo apt-get install -y nfs-common

Create the mount point:

sudo mkdir -p /mnt/efs-restore

Mount using NFSv4:

sudo mount -t nfs4 \
  -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport \
  <fs-id>.efs.<region>.amazonaws.com:/ \
  /mnt/efs-restore

Verify:

mount | grep efs
df -h /mnt/efs-restore

If EFS DNS does not resolve, use the appropriate mount-target IP address.

8. Locate and Extract Required Data

Search the restored filesystem:

find /mnt/efs-restore -iname "<filename>"

Copy required data to a local scratch location:

rsync -avh --progress \
  /mnt/efs-restore/<path>/ \
  ~/local-copy/

Verify the copied files before cleanup.

Cleanup

Cleanup is mandatory after completing the recovery.

1. Unmount EFS

sudo umount /mnt/efs-restore

Confirm it is no longer mounted:

mount | grep efs

2. Delete Mount Targets

In the EFS console:

File system → Network

Delete the mount target(s).

Wait for deletion to complete.

3. Delete the Restored Filesystem

From the EFS filesystem list:

1. Select the restored filesystem.
2. Choose Delete.
3. Confirm the filesystem ID when prompted.

Do not delete the original/source filesystem.

4. Restore Any Temporary Security Policy Changes

If the AWS Backup vault policy was modified:

• Restore the original deny/allow configuration.
• Verify the policy.
• Confirm no temporary restore exception remains.

tmux / nohup

Long-running restore, copy, or investigation commands should be run inside tmux unless the operation is intentionally fire-and-forget.

tmux — preferred for interactive work

Start:

tmux new -s efs-restore

Detach without stopping the work:

Ctrl-b
  ↓ release
d

Important: Ctrl-b is a prefix. Press and release it first, then press d separately.

List sessions:

tmux ls

Reconnect:

tmux attach -t efs-restore

Kill the session when finished:

tmux kill-session -t efs-restore

Detaching does not stop commands running inside the session.

nohup — fire-and-forget

For a non-interactive operation where a log file is sufficient:

nohup ./script.sh > /path/to/out.log 2>&1 &

Watch output:

tail -f /path/to/out.log

Check the process:

ps aux | grep script.sh

Stop it:

kill <PID>

Force termination only when necessary:

kill -9 <PID>

Rule of thumb

tmux: long-running, interactive, inspectable work.

nohup: background jobs where the log is all you need.