Rehearse an AWS Backup Cross-Account EFS Restore

Copy one Amazon EFS recovery point to a separate account, restore an isolated new file system, test permission boundaries and retain file-integrity evidence.

Copy into the recovery account before trying to restore there

For this rehearsal, use one Amazon EFS recovery point, two AWS accounts in the same organization and one selected AWS Region. Copy the recovery point into the recovery account's vault, verify the resulting copy, then restore it into a new EFS file system in that account. Keep the test client isolated and accept the result only after checking the expected files and denied access paths.

The distinction is operational: AWS Backup's cross-account procedure describes copying a backup into the destination account and restoring locally there. A vault permission that allows a copy does not grant an operator authority to perform a restore. A successful copy job does not establish that the destination's restore role, encryption access or file reader works.

This is an unexecuted reference playbook. Its fixture, account names and evidence template are illustrative. It contains no customer outcome, achieved recovery time, compliance assertion or reviewed production configuration. AWS documentation was checked on 2026-10-07; the accountable AWS reviewer must recheck it and the actual environment before executing the procedure.

1. Agree one EFS recovery question and assign the owners

Owner: recovery owner. Output: exercise contract. Define the accepted question narrowly: can the designated recovery operator use a completed destination copy to recover one approved EFS file set without borrowing the source account's operator credentials? This exercises account and permission boundaries. It does not simulate an AWS Region outage, organization-management compromise, unavailable identity provider or application cutover.

Use synthetic data for the first run. If a later run uses protected files, the data owner must authorize that handling and restrict evidence access. Agree a cost ceiling, resource lifetime, retained evidence location and participant list before requesting copies or restores. Set a maximum elapsed exercise window and an owner who can halt further work if resources remain chargeable.

Assign five responsibilities: source backup operator selects and copies; destination platform operator prepares isolation and restores; IAM/KMS reviewer checks authority and encryption; file/application owner defines invariants; independent observer records milestones and compares evidence. Name actual people in the exercise record. A role label in this article does not mean somebody has completed the review.

The existing PostgreSQL restore drill covers database target selection and external-effect reconciliation. This playbook adds a different task: EFS recovery-point copying, destination-local restore authority and NFS/file-path validation. Do not substitute it for a PostgreSQL point-in-time procedure or a whole-application recovery plan.

2. Check resource support and copy prerequisites

Owner: source backup operator with organization administrator. Output: prerequisite register. The selected resource is Amazon EFS only. The AWS Backup availability table lists EFS cross-account backup and full AWS Backup management. Check its Region tables for the actual exercise Region. Do not infer support for another resource, an opt-in Region or a different vault mode from EFS support.

For this reference run, choose a warm recovery point and standard backup vaults in the same selected Region. The source and recovery accounts must belong to the same AWS organization, and cross-account backup must be enabled by the organization management account. Check those facts using the authorized organization's existing controls; enabling an organization feature is a separately owned setup change.

Record source resource ARN, source vault ARN, destination account ID, destination vault ARN and Region. Record any candidate recovery-point ARN and state as provisional. For the new synthetic fixture in step 4, bind the final selected recovery point only after that fixture's backup completes; step 7 must copy that final point, not an earlier candidate. Verify both sessions' actual account identities. Reject a point in an unexpected vault, an incomplete backup, an unsupported storage tier or a Region mismatch rather than working around the discrepancy mid-run.

Preserve the source backup and its retention. This rehearsal neither changes production backup schedules nor shortens existing retention. The copy must remain available through verification and agreed evidence retention. If cold-storage or immutable-retention requirements apply, design a separate exercise around those restrictions instead of silently applying this warm-vault procedure.

3. Separate the encryption and authority dependencies

Owner: IAM/KMS reviewer. Output: permission and key ledger. EFS recovery points use independent AWS Backup encryption controlled by the vault key. A cross-account copy is re-encrypted under the destination vault key. The restored file system has a separately selected encryption configuration. These are distinct dependency records, even if an organization elects to use one destination key for more than one purpose. See AWS Backup encryption.

For the reference exercise, use explicitly approved customer-managed keys for the source vault, destination vault and encrypted restored EFS file system. This is an exercise choice to make policy ownership inspectable, not a claim that EFS always requires customer-managed source keys. AWS documents independent encryption and different key options for fully managed resources; do not transfer rules for RDS snapshots or other resources into this EFS procedure.

For each key record account, Region, key ARN, enabled state, policy owner, expected service use and evidence of the relevant role's permission. Review IAM policy, key policy, grants, explicit denies, service control policies and permission boundaries together. A key appearing in a selector or a role having a broad allow statement cannot establish effective access.

Keep copy and restore permissions distinct. Review the source copy role's backup:CopyFromBackupVault and backup:CopyIntoBackupVault access, plus the destination vault's resource permission for the intended copy principal. Then review the destination operator's restore request and role-passing authority, the role AWS Backup assumes for restore and resource-creation/key-use permissions. The security reviewer supplies the environment-specific policies; this article intentionally supplies no wildcard policy to paste into a live account.

Ensure required destination service-linked roles exist. Amazon EFS uses AWSServiceRoleForAmazonElasticFileSystem; its purpose differs from a user-selected AWS Backup restore role. EFS service-linked-role guidance explains ownership and creation. Record the relevant AWS Backup service-linked role and restore-role identities separately. Do not reuse their names as though they were interchangeable credentials.

Account and recovery boundaries

Reference account and permission view. Copy crosses accounts; restore and file inspection stay in the recovery account. Key icons identify encryption dependencies, not a network data route.

The source EFS backup is protected by the source vault key. The destination copy is protected by the destination vault key. A destination restore role creates an encrypted new EFS file system using the selected target key. The isolated client then reads the recovery directory under network, IAM and file permissions. There is no production traffic arrow: routing production to the recovered copy is outside this exercise.

4. Build the fixture before the selected backup

Owner: file/application owner. Output: independent fixture manifest. Choose a small synthetic file tree with a known document, a nested directory, a zero-byte file and one file requiring restricted access. Record expected relative paths, sizes, content hashes, UID/GID and mode bits where the application relies on them. Include a non-ASCII filename only if your workload depends on such names and your tooling handles them consistently.

Capture the reference manifest outside the file system being backed up, in an access-controlled evidence store. Keep a unique fixture marker identifying the attempt. The observer must be able to obtain the expected record without reading the restored copy as its own reference. Do not hash private production data into a widely shared report.

Quiesce writes to the synthetic fixture while establishing the manifest and backup boundary. The fixture should describe a stable expected file set, rather than assume an actively changing tree is a transactional snapshot. Capture the source backup job and its completion record, then identify the recovery point actually produced. A manifest collected after unrelated writes is not a valid comparison for an earlier backup.

Define which checks are exhaustive for the tiny fixture and which are merely sampled for a larger later run. One matching document cannot prove all retained files match. Permission and application-path expectations belong in the fixture contract as well as byte-level checks.

5. Prove destination isolation before granting a mount path

Owner: destination platform operator with security reviewer. Output: isolation evidence. Create or identify an approved exercise network and a test client in the recovery account. Keep production applications, schedulers and external-effect integrations disconnected. Record the client identity, network interfaces, routes, security groups and intended EFS mount-target scope before making the recovered data reachable.

EFS network-access guidance identifies NFS port 2049 and the client/mount-target security-group relationship. For this exercise, restrict the mount target to the designated exercise client group and review connected networks as well as local subnet membership. A private mount target can still be reachable through an unwanted connected path.

Use a reviewed file-system policy and an approved EFS mount-helper configuration with IAM authorization and TLS. EFS IAM access guidance distinguishes client mount, write and root authority and warns that the default file-system policy allows anonymous clients able to reach the mount target. An exercise account name is not sufficient isolation.

Initially grant the validation client read-only access to the intended restored data. Configure the host mount accordingly, but test server-side authorization too: a locally read-only mount can block a write without proving the server would deny it. Review POSIX permissions and any access-point identity mapping used by the test client. Hold the run until expected network and file-access boundaries have been checked.

6. Design negative probes without weakening live controls

Owner: IAM/KMS reviewer with independent observer. Output: permission-negative results. Test with narrowly provisioned exercise identities and synthetic resources. Do not disable keys, remove production denies, alter source retention or delete a backup to produce a failure demonstration. Policy simulation and review may explain expected denial but cannot be labelled a tested end-to-end denial.

Prepare separate control-plane and data-plane tests now. A designated reader should retrieve agreed metadata but have no approved restore-start or role-passing path. An excluded client should fail the intended network or IAM mounting boundary. The validation reader should read a permitted fixture and fail a prohibited file-access/write operation according to the contract. These are expected results, not observations at this stage: the destination recovery point and restored file system have not yet been created. Schedule metadata checks after the copy in step 7 and target-dependent probes after the restore in step 9. Record the exact identity, request, intended boundary, observation and timestamp when each test actually runs.

For a create/write negative check, use only the agreed synthetic path on the exercise copy, with an explicitly scoped probe design reviewed beforehand. A surprising success could mutate data or allocate a resource. Record it as a failed control, stop further validation, and use the owned containment/cleanup path. Do not turn an unexpected mutation into a passing test because it happened outside production.

The key-use negative check is a policy/permission review unless a separately reviewed synthetic-key test is available. Never revoke a shared key grant during an ordinary backup or restore job to demonstrate denial. Label unexecuted checks not tested, preserve the gap and keep any recovery claim within the verified scope.

7. Copy and independently verify the destination recovery point

Owner: source backup operator. Output: copy job and destination-point record. Reconfirm the source session and selected recovery point immediately before starting the approved copy. Choose the exact destination vault ARN and same exercise Region in the AWS Backup console. Capture the request, source recovery-point identity, destination vault, copy role and resulting job ID. The observer records copy-request time.

Follow the documented on-demand copy workflow; do not broaden vault access through a convenient organization-wide example. Await the actual job outcome. A failed or ambiguous job remains a separate attempt, with its reason and elapsed time. Do not initiate unbounded retries or assume a submitted request has delivered a usable copy.

Switch to the verified recovery-account session. Locate and describe the destination recovery point rather than reusing the source ARN. Bind it to the copy-job evidence. Inspect status, resource type, destination vault, encryption-key identity and retention/lifecycle observations. The describe-recovery-point CLI reference defines the returned metadata; preserve actual values rather than filling the register from the intended configuration.

No source-account session should be needed by the destination operator for the next steps. That is evidence about the operator path exercised here, not proof that every underlying service dependency is independent of the source account or organization. Do not disable source infrastructure to extend the claim.

8. Review restore metadata, then restore into a new file system

Owner: destination platform operator. Output: reviewed restore request and job record. Retrieve restore metadata for the destination recovery point. GetRecoveryPointRestoreMetadata returns the original configuration metadata; it is an input for review, not the final exercise target configuration. Inspect any inherited identifiers before authorizing the restore.

Select full restore into a new EFS file system, encrypted with the approved destination target key, with the reviewed destination restore role. Use the console's supported choices for file-system type and performance mode. Record those choices, the request identity and the job ID. Do not restore into an existing production file system as a shortcut.

The EFS restore documentation describes new-file-system and encryption choices. It also says restored files are placed beneath a recovery directory rather than directly at their original root paths. Inspect the actual resulting directory name; do not hard-code a timestamp or move files to the original location during this read-only rehearsal.

Review vault access policies before starting. An explicit restore denial is a hold that the vault owner must assess, not permission for the operator to remove the deny casually. Use the organization-approved change path for any required exercise-vault exception. Maintain ordinary backup protection throughout the run.

When the job reaches its reported outcome, record the actual created resource ARN using DescribeRestoreJob. Independently verify that the account, Region, file-system ID, encryption key and chosen configuration match the contract before creating the approved mount path. A job status and a resource identity are intermediate evidence; file acceptance is next.

9. Validate files and application paths through the isolated client

Owner: file/application owner with observer. Output: comparison results. Use the approved read-only mount procedure for the verified restored file system. Record which identity, file-system ID and mount path were actually used. Locate the recovery directory and map each manifest's relative path beneath it. An old source mount still available on the host can otherwise produce convincing but irrelevant hashes.

Run the reviewed target-dependent negative probes from step 6 only after that identity and isolation readback. Keep an allowed read as the positive control, then inspect the expected network, IAM and file-level denials separately. A failed mount without attribution is not proof that every layer denied access. Stop and contain a surprising allowed write; do not continue to acceptance by ignoring the failed boundary.

Compare fixture presence, sizes and hashes against the independent expected manifest. Compare required UID/GID/mode behavior and the allowed/denied reader fixtures. Report each mismatch separately. If permission semantics differ, investigate restored file metadata, client identity, access-point mapping and the actual policy path; do not repair all permissions to a broad default and call restoration faithful.

For the selected application function, configure a minimal isolated reader to use the recovery directory explicitly. Confirm it can find the expected document and handle a deliberately absent fixture without silently reading the source mount. No file relocation or write-enabled application worker is needed for this first run.

If the application normally joins EFS files with database records, this drill does not establish that those records share the same recovery boundary. Record that dependency as untested unless the exercise includes an independently approved paired-state fixture. Keep byte recovery, access recovery and whole-application acceptance as separate conclusions.

10. Record full elapsed time and abort reasons

Owner: observer. Output: milestone and limitation log. Record declaration, usable destination credentials, source-point selection, copy request/completion, destination-point validation, restore request/completion, mount readiness, final file checks and owner decision. Calculate elapsed time from the agreed start to acceptance. Do not add overlapping work twice or hide credential preparation and permission repairs outside the stated clock.

Use a distinct attempt record when retrying after a failure. Compare data size, file count, file-system configuration, client conditions, fixture coverage and whether infrastructure was prebuilt. A small synthetic fixture provides correctness evidence for those files under those conditions. It cannot establish a production recovery-time objective for a much larger tree.

Abort further action when the account or ARN is uncertain, copy/restore status contradicts the selected point, protected data escapes the approved boundary, denied access unexpectedly succeeds, a production destination becomes reachable, the spending ceiling is exceeded or the exercise window expires. Preserve job IDs and observations and assign the containment owner. Halting new requests does not imply an already running job has stopped or that ongoing storage costs have ceased.

11. Contain failed attempts and clean up exact exercise resources

Owner: destination platform operator with resource/data owner. Output: cleanup readback. This drill's rollback means containing and retiring the exercise copy through its approved lifecycle. It does not mean routing production back from a newly promoted file system, because no promotion was permitted. If a production mutation happened, handle it as a separate incident with the relevant owner.

First block new access to the exercise target using the pre-reviewed isolation control. Preserve investigation evidence before retiring resources. Record exact client, mount target, restored file system, temporary role grants and any exercise-only recovery point with account/Region and ownership confirmation. List production resources explicitly excluded from cleanup.

The resource owner then follows the separately reviewed disposal procedure, respecting retention, vault lock and organizational restrictions. This article provides no deletion commands. Do not delete a shared service-linked role or schedule a shared key's deletion as a convenience. Inspect EFS automatic-backup settings on the new target and account for any additional recovery points or resources created during the exercise.

Verify the resulting resource states, removed exercise access and remaining storage/compute obligations. Record any retained target or backup with a named owner and expiry. A requested deletion, disconnected client or successful final screenshot does not establish that all exercise spend and data retention have ended.

12. Use a fillable evidence record with read-only observations

The following checklist is a proposed record, not proof of execution. Replace unrecorded with actual evidence references after checking the account and permission scope. Keep credentials and file contents out of the report.

exercise: efs-cross-account-fixture-01
state: not-executed
scope: same-region-warm-copy-to-new-encrypted-efs
source_account: unrecorded
recovery_account: unrecorded
region: unrecorded
source_recovery_point_arn: unrecorded
destination_recovery_point_arn: unrecorded
copy_job_id: unrecorded
restore_job_id: unrecorded
restored_file_system_arn: unrecorded
key_ledger: unrecorded
independent_fixture_manifest: unrecorded
positive_read_results: unrecorded
permission_negative_results: unrecorded
milestone_log: unrecorded
cleanup_readback: unrecorded
decision: hold-until-required-evidence-exists
untested: [region-loss, source-key-loss, live-cutover, production-scale]

These AWS CLI v2 examples retrieve observations only. They were checked against the linked command references but have not been run in an AWS account. Use approved read-only profiles, supply exact values from the contract and inspect each output. Do not paste placeholder strings as though they identify resources. An access-denied response is evidence to investigate, not a reason to switch to an unrestricted administrator.

aws sts get-caller-identity --profile recovery-readonly --no-cli-pager

aws backup describe-recovery-point \
  --profile recovery-readonly --region EXERCISE_REGION \
  --backup-vault-name EXERCISE_VAULT \
  --recovery-point-arn DESTINATION_RECOVERY_POINT_ARN \
  --no-cli-pager

aws backup get-recovery-point-restore-metadata \
  --profile recovery-readonly --region EXERCISE_REGION \
  --backup-vault-name EXERCISE_VAULT \
  --recovery-point-arn DESTINATION_RECOVERY_POINT_ARN \
  --no-cli-pager

aws backup describe-restore-job \
  --profile recovery-readonly --region EXERCISE_REGION \
  --restore-job-id RECORDED_RESTORE_JOB_ID \
  --no-cli-pager

The commands answer identity and metadata questions. They cannot prove a file hash matches, a prohibited mount is denied or an application can read the recovery directory. Use the operator's verified mount and fixture procedure for those checks, and retain its actual results.

13. Check the acceptance criteria and record remaining gaps

Owner: recovery owner. Output: accepted, held or failed decision. Record success only when all mandatory checks below have actual evidence. An observer may record a completed job, but only the designated owner can accept the exercised recovery capability.

• [ ] Source and destination point identities are linked through a completed copy record.
• [ ] The selected EFS/Region/storage-tier prerequisites were verified.
• [ ] Destination-local restore role and encryption dependencies were reviewed.
• [ ] The new restored file system and actual recovery directory were independently identified.
• [ ] The fixture manifest matches the agreed content and access expectations.
• [ ] Required negative checks passed, or the owner explicitly held acceptance for untested boundaries.
• [ ] The isolated reader used the recovery copy and never relied on a source mount.
• [ ] Full elapsed milestones, failures and environment differences are retained.
• [ ] Exercise resource/access cleanup has verified readback or owned retention.
• [ ] No conclusion claims production-scale timing, regional survival, source-key-loss survival or traffic cutover without a separate test.

This reference procedure has not been executed in an AWS account. Before operational adoption, choose the exercise Region, review the actual IAM/key/vault policies, design environment-specific permission-negative probes and observe restored metadata and automatic-backup behavior. Educational review does not substitute for those workload-specific tests.

The next useful action is to complete the prerequisite and fixture registers, then have the AWS reviewer check the proposed request and isolation controls. Bring the sanitized evidence and held boundaries to Ampity's reliability review if independent help is needed. The technical conclusion remains the bounded exercise result, not a promise of recovery for every workload.