Part 068 — EFS and FSx Backup, Restore, Replication, and File-System DR

File storage recovery is different from block and object recovery.

With EBS, you restore a volume.

With S3, you restore object versions.

With EFS and FSx, you restore a file system, volume, share, directory, snapshot, clone, or selected files—while preserving permissions, identity, mount paths, client behavior, backup metadata, and application expectations.

A file-system restore is not complete when bytes exist.

It is complete when:

• clients can mount
• users/services can authenticate
• POSIX/ACL permissions work
• applications can read/write
• file locks and paths behave
• restored data matches business state
• catalog references are consistent
• RTO/RPO are measured

This part covers EFS and FSx data protection across AWS file storage services.

1. Problem yang Diselesaikan

Part ini membahas:

• EFS automatic backups and AWS Backup
• EFS full restore vs item-level restore
• EFS replication, failover, and failback
• EFS lifecycle interaction with restore
• FSx automatic backups and user-initiated backups
• FSx restore models by family
• FSx Windows shadow copies vs backups
• FSx ONTAP snapshots, backups, subset restore, and SnapMirror
• FSx OpenZFS snapshots, clones, backups, and replication
• FSx Lustre backup/export considerations
• file permissions and identity restore
• AD/POSIX/KMS dependency recovery
• DataSync migration/copy patterns
• runbooks and game days

2. Mental Model

2.1 File-system restore includes data and access semantics

For file storage:

restore data + restore namespace + restore permissions + restore client access + restore application correctness

A restored file that the app cannot read is not recovered.

2.2 Backup, snapshot, clone, and replication differ

2.3 File restore can be full or partial

Full restore:

restore entire file system/volume/share

Partial restore:

restore selected file/directory/subset

Partial restore is often safer, but requires knowing exact path and ensuring correct permissions.

2.4 Source-of-truth matters

If file storage is source of truth:

• backups required
• restore tested
• replication considered
• permissions validated
• RPO/RTO explicit

If file storage is cache/derived:

• backup may be unnecessary
• rebuild path must exist
• cleanup can be aggressive
• source data protected elsewhere

2.5 Identity systems are part of recovery

File storage may depend on:

• POSIX UID/GID
• EFS access points
• Active Directory
• SMB ACLs
• NFS export policies
• ONTAP SVM identity mapping
• KMS keys
• DNS/DFS aliases
• security groups

If identity fails, restored data may be unusable.

3. EFS Data Protection

3.1 AWS Backup for EFS

Amazon EFS integrates with AWS Backup. EFS file systems created with the EFS console have automatic backups turned on by default. The default EFS backup plan uses AWS Backup recommended settings, including daily backups with 35-day retention.

Do not rely on default blindly. Review:

• backup frequency
• retention
• vault
• cross-account copy
• cross-region copy
• Vault Lock
• restore testing
• tags and ownership

3.2 Full restore

Full restore restores the entire EFS file system.

Use when:

• broad corruption
• accidental large delete
• new environment recovery
• DR restore
• migration test
• forensic comparison

Recommended:

restore to new EFS first
validate
then cut over/copy back

3.3 Item-level restore

AWS Backup supports EFS item-level restore for selected files/directories. AWS docs state you can select and restore up to five items within EFS in that flow.

Use when:

• one directory deleted
• one file corrupted
• small subset needed
• faster recovery than full restore

Runbook:

1. identify path
2. choose recovery point
3. restore item to recovery directory/staging
4. validate file
5. copy back with permissions
6. update app/catalog if needed

3.4 Restore to new vs existing file system

Restore to new EFS:

• safer
• isolated validation
• useful for full recovery
• requires mount targets/access points recreation or IaC
• cutover needed

Restore to existing EFS:

• useful for item restore
• risk of overwrite/conflict
• requires careful target path
• permission validation required

3.5 EFS replication

EFS replication automatically and transparently replicates data and metadata from source EFS to destination EFS. It supports failover to replica and failback to primary.

Use when:

• lower RTO needed than full restore
• regional or AZ-level resilience
• DR exercises
• standby file-system copy
• migration-like switchover

Caution:

• replication can copy corruption/deletes
• backup still needed for point-in-time recovery
• failover/failback must be tested
• app/client remount path required

3.6 EFS replication runbook

Failover:

1. Declare incident.
2. Stop source writes if possible.
3. Check replication status/lag.
4. Fail over to destination.
5. Update mounts/DNS/config.
6. Recreate/verify access points, security groups, IAM if needed.
7. Validate app.
8. Record RPO actual.
9. Plan failback.

Failback:

1. Freeze writes on destination.
2. Replicate/copy back to original or choose new primary.
3. Validate.
4. Switch mounts.
5. Monitor.

3.7 EFS lifecycle and restore

Lifecycle/tiering can affect access latency/cost but is not backup.

Check during restore:

• restored storage class behavior
• cold file access latency
• app timeouts
• lifecycle rules on restored file system
• whether old files should remain cold

3.8 EFS access points after restore

Restoring data does not always restore operating environment exactly as app expects.

Ensure:

• mount targets
• security groups
• access points
• file system policies
• IAM roles
• POSIX identity enforcement
• root directory creation info
• backup/lifecycle/replication settings

are recreated by IaC.

4. FSx Data Protection Overview

4.1 FSx automatic and user-initiated backups

Amazon FSx supports automatic backups and user-initiated backups for file systems/volumes depending on FSx family.

User-initiated backups are retained even after deleting the file system and do not expire automatically. They remain until manually deleted.

Design:

• automatic backup retention
• manual backup before risky changes
• AWS Backup plan where supported/desired
• restore game day
• copy/DR strategy
• KMS and identity dependencies

4.2 AWS Backup restore for FSx

AWS Backup can restore most Amazon FSx backups created by AWS Backup using the AWS Backup console, API, or CLI.

Feature support differs by file system type and Region.

Always check:

• supported FSx family
• restore target type
• same-region/cross-region behavior
• KMS
• subnet/AD requirements
• restore metadata
• service quotas

4.3 Backup restore creates new file system/volume

Often FSx restore creates:

• new file system from backup
• new volume from backup
• restored resource in selected VPC/subnet
• new DNS/mount endpoint

You usually need client cutover.

4.4 File-level restore

File-level restore depends on FSx family:

• Windows: shadow copies / previous versions / restore backup to staging and copy files
• ONTAP: snapshots and .snapshot directory / Previous Versions / subset restore from backup
• OpenZFS: snapshots/clones/backup restore
• Lustre: restore file system backup or reimport/export from S3 depending design

4.5 Restore validation

Validate:

• mount/share path
• user/service access
• ACL/POSIX permissions
• file count/sample checksum
• app smoke test
• backup date vs expected RPO
• DNS/DFS/client path
• KMS decrypt
• AD/domain
• export/share policy

5. FSx for Windows File Server Protection

5.1 Backups

FSx for Windows supports automatic daily backups and user-initiated backups.

User-initiated backups:

• created anytime
• retained after file system deletion
• do not expire automatically
• must be deleted manually

Use manual backups before:

• major ACL change
• migration cutover
• application upgrade
• bulk delete/cleanup
• storage migration
• AD/share reconfiguration

5.2 Restore backup

Restoring backup creates a new FSx for Windows file system.

Restore questions:

• Single-AZ or Multi-AZ?
• storage type/capacity?
• throughput capacity?
• subnet?
• AD integration?
• DNS alias/DFS update?
• security group?
• backup retention on restored file system?
• shadow copies?

5.3 Shadow copies

Shadow copies provide previous versions on the file system for end-user/admin restore.

Use for:

• accidental overwrite
• accidental delete
• quick file/folder recovery

Not replacement for backup:

• same file system
• storage consumed locally
• retention limited
• may be affected by file system issues
• not cross-account immutable

5.4 Windows restore runbook

1. Try Previous Versions/shadow copy for small file restore.
2. If unavailable, restore FSx backup to new file system.
3. Validate AD integration and ACLs.
4. Copy selected files back preserving ACLs or cut over share.
5. Update DFS/DNS if full recovery.
6. Validate user access.
7. Record RTO.

5.5 AD dependency

FSx Windows recovery requires AD health.

For DR:

• AD available in recovery Region/account
• trust relationship works
• service account/computer objects supported
• DNS configured
• security groups allow domain traffic

A file backup without AD recovery may not restore service.

5.6 Finance share example

Protection:

• Multi-AZ file system
• automatic daily backup 35 days
• shadow copies every business interval
• manual backup before ACL migrations
• AWS Backup/cross-account copy if required
• DFS namespace for cutover
• restore game day quarterly

6. FSx for Lustre Protection

6.1 Scratch vs persistent

Protection depends on deployment role.

Scratch:

data can be recreated from S3/source
outputs must be exported

Persistent:

file system stores important working set/checkpoints
backups/export required

6.2 Backups

FSx for Lustre supports user-initiated backups. For persistent workloads, backups protect file system state.

User-initiated backups are retained after file system deletion and do not expire automatically.

6.3 S3 export as protection

For many Lustre workloads, the durable truth is S3.

Protection pattern:

S3 input -> FSx Lustre processing -> S3 output manifest

A scratch Lustre file system can be deleted if:

• outputs exported
• checkpoints retained if needed
• job state committed
• source input remains durable

6.4 Restore from backup

Restoring Lustre backup creates a new file system.

Validation:

• mount from compute node
• validate files
• validate permissions
• run job smoke test
• export path works
• S3 data repository association if needed

6.5 Lustre recovery runbook

If file system lost:

1. Determine scratch vs persistent.
2. If scratch, recreate from S3/input manifest.
3. If output missing, rerun from last checkpoint/source.
4. If persistent, restore from backup.
5. Validate compute mount.
6. Resume jobs.
7. Export durable outputs.

6.6 Checkpoint RPO

For ML/HPC:

RPO = last durable checkpoint, not last file written to FSx

If checkpoint only exists on scratch file system, RPO may be unacceptable.

7. FSx for NetApp ONTAP Protection

7.1 Volume backups

FSx for ONTAP supports automatic daily backups and user-initiated backups of volumes. AWS docs state you can restore volume backups to an existing FSx for ONTAP file system in the same Region where the backup is stored.

This is volume-level protection, not always entire file-system protection.

7.2 Snapshots

ONTAP snapshots are fast point-in-time views.

Use for:

• operational file restore
• pre-change safety
• quick rollback
• source for clones
• user restore through .snapshot or Previous Versions

Snapshots are local to the file system/volume. Pair with backups/replication for broader recovery.

7.3 File restore from snapshots

Users can restore previous versions of files/folders:

• Linux/macOS: .snapshot directory at root of volume
• Windows: Previous Versions tab in Explorer

This can reduce operator workload for simple restore.

7.4 Subset restore from backup

FSx for ONTAP supports workflows to restore a subset of data from a volume backup by restoring backup to a new volume and copying needed data.

Use when:

• snapshot unavailable
• backup is needed
• only a directory/file subset should be recovered
• full volume rollback is too disruptive

7.5 SnapMirror and DR

ONTAP replication/SnapMirror patterns support:

• migration
• DR
• cross-environment copy
• failover/failback workflows

Protection design:

• snapshot schedule
• SnapMirror schedule
• backup retention
• DR SVM/volume readiness
• identity mapping
• DNS/client cutover
• split-brain prevention

7.6 ONTAP restore runbook

1. Determine restore source: snapshot, backup, replica.
2. For file restore, use .snapshot/Previous Versions if possible.
3. For subset backup restore, restore to new volume.
4. Mount new volume.
5. Copy selected files back.
6. Preserve ACL/POSIX ownership.
7. Validate application.
8. Clean temporary volume.

8. FSx for OpenZFS Protection

8.1 Snapshots

OpenZFS snapshots are point-in-time volume images.

Use before:

• bulk update
• migration
• app deployment
• cleanup
• test run
• data transformation

8.2 Clones

Clones create writable volumes from snapshots.

Use for:

• restore validation
• dev/test
• rollback rehearsal
• CI fixtures
• data comparison

8.3 Backups

FSx for OpenZFS supports user-initiated backups; user-initiated backups are retained after file system deletion and do not expire automatically.

Use backups for:

• broader recovery
• compliance retention
• file system/volume protection
• recovery beyond local snapshots

8.4 On-demand replication

FSx for OpenZFS supports on-demand replication to synchronize snapshots between file systems within or across Regions.

Use for:

• DR copy
• migration
• periodic environment sync
• RPO-based replication schedule

8.5 OpenZFS restore runbook

1. For quick restore, create clone from snapshot.
2. Validate data in clone.
3. Copy selected files back or cut over to clone.
4. For full recovery, restore backup.
5. For DR, use replicated snapshot/volume.
6. Validate NFS access and app behavior.
7. Delete stale clones after recovery.

8.6 Clone dependency risk

Clones can keep source snapshots alive.

During recovery cleanup:

• identify clone dependencies
• delete expired clones
• avoid deleting needed snapshot
• decide CLONE vs FULL_COPY for independence

9. Identity and Permission Recovery

9.1 POSIX recovery

For EFS/OpenZFS/ONTAP NFS:

Validate:

id
stat path
getfacl path
touch test
sudo -u appuser test -r path
sudo -u appuser test -w path

Potential issues:

• UID/GID mismatch
• restored ownership outdated
• access point not recreated
• export policy wrong
• root squash behavior
• container user changed

9.2 SMB/Windows recovery

Validate:

• AD group membership
• share permissions
• NTFS ACLs
• inheritance
• DFS target
• user can open file
• service account can write
• file locks
• Previous Versions

Potential issues:

• AD unavailable
• orphaned SIDs
• broken trust
• DNS alias points old target
• ACLs copied incorrectly

9.3 KMS recovery

For encrypted file systems/backups:

• restore role decrypt
• destination KMS key policy
• cross-account/cross-region key access
• key not disabled/deleted
• backup service role access

9.4 Network recovery

Restored file system needs:

• VPC
• subnets
• mount targets/endpoints
• security groups
• route tables
• DNS
• client config
• on-prem connectivity if needed

Data restore without network restore is incomplete.

10. DataSync and File Recovery

10.1 DataSync as copy/recovery tool

AWS DataSync can transfer data between:

• on-prem NFS/SMB
• EFS
• FSx
• S3
• cross-region/cross-account paths

Use for:

• migration
• restore copy-back
• subset restore
• DR sync
• backup staging
• archive movement

10.2 Copy-back from restored file system

Pattern:

restore backup to staging FS
validate
DataSync/rsync/Robocopy selected data back to prod

This avoids full production rollback.

10.3 Permission preservation

Choose tool/options based on protocol:

• Robocopy for Windows ACL/metadata
• DataSync for NFS/SMB with metadata options
• rsync for POSIX files where appropriate
• ONTAP-native tools for ONTAP

10.4 Copy-back risk

Risks:

• overwriting newer data
• changing ownership
• path mismatch
• copying partial/infected data
• losing ACLs
• app writes during copy

Mitigation:

• staging validation
• maintenance/freeze window
• backup before copy-back
• dry run
• owner approval
• app smoke test

11. Lifecycle and Tiering Interaction

11.1 EFS lifecycle

EFS lifecycle can move cold files to lower-cost storage classes.

Restore/access concern:

• cold files may have latency/cost implications
• restored data may inherit/change storage class behavior
• application timeouts must tolerate cold access

11.2 ONTAP tiering

ONTAP capacity pool/SSD tier affects restore performance and cost.

During recovery:

• hot set may be on capacity pool
• recall latency may affect RTO
• restore volume tiering policy matters
• snapshot/backup restore may need warmup

11.3 FSx Windows HDD/SSD

Restored file system can choose configuration. Performance after restore depends on:

• storage type
• throughput capacity
• client count
• directory structure
• AD/DNS

11.4 Archive/cold data is not instant DR

If RTO is low, do not rely on cold-tier restore without testing.

12. Observability

12.1 EFS metrics

Track:

• latest backup
• backup failures
• restore test status
• replication status
• replication lag/time since sync
• file system size
• bytes by storage class
• mount/access errors
• item-level restore test result

12.2 FSx metrics

Track:

• automatic backup status
• manual backup age
• backup restore tests
• snapshot count
• clone count
• replication status
• capacity used
• throughput/IOPS
• AD health for Windows
• ONTAP tiering/snapshot metrics
• OpenZFS replication status
• Lustre export/checkpoint status

12.3 Governance metrics

Track:

• file systems without backup plan
• backup retention below policy
• file systems without recent restore test
• critical FSx/EFS without cross-account/cross-region copy
• untagged file systems
• unknown owner volumes/shares
• shadow copies disabled where expected
• stale clones/snapshots

12.4 AWS Config/Security Hub

AWS Config has managed rules such as checking whether EFS file systems or FSx resources are protected by backup plans. Use compliance tools to catch drift.

13. Runbooks

13.1 EFS item restore

1. Identify path and deletion/corruption time.
2. Choose recovery point.
3. Start item-level restore.
4. Restore to recovery directory/staging.
5. Validate content and permissions.
6. Copy back or update app reference.
7. Test app.
8. Record RTO/RPO actual.

13.2 EFS full restore

1. Choose recovery point.
2. Restore to new EFS.
3. Create mount targets/security groups/access points.
4. Mount from test client.
5. Validate data/permissions.
6. Plan cutover.
7. Switch clients.
8. Monitor.
9. Keep old source isolated if needed.

13.3 FSx Windows file restore

1. Try shadow copy/Previous Versions.
2. If not available, restore backup to new FSx.
3. Validate AD and ACLs.
4. Copy file/folder back preserving ACLs.
5. Validate user/service access.
6. Update DFS/DNS if full cutover.

13.4 FSx ONTAP file restore

1. Check snapshot.
2. Use .snapshot or Previous Versions for file restore.
3. If backup needed, restore to new volume.
4. Mount restored volume.
5. Copy subset back.
6. Validate NFS/SMB access.
7. Clean temporary volume.

13.5 FSx OpenZFS rollback

1. Identify pre-change snapshot.
2. Create clone for validation.
3. Validate app.
4. Copy back selected files or cut over volume.
5. Delete clone after recovery.
6. Review snapshot policy.

13.6 File-system DR failover

1. Declare incident.
2. Freeze source writes if possible.
3. Choose replica/backup recovery point.
4. Promote/restore destination.
5. Recreate access/network/identity dependencies.
6. Switch mount paths/DNS/DFS.
7. Validate app.
8. Record RPO/RTO.
9. Plan failback.

13.7 Permission broken after restore

1. Identify protocol.
2. Check user/service identity.
3. Check restored ownership/ACL.
4. Check access point/export/share.
5. Check AD/KMS/network.
6. Compare with pre-restore baseline.
7. Fix via IaC/policy/copy options.
8. Add restore validation test.

14. Game Days

Scenario 1 — EFS deleted directory

Expected:

• item-level restore works
• permissions validated
• app sees restored files
• RTO measured

Scenario 2 — EFS regional DR

Expected:

• replica failover tested
• clients remount
• app validates
• failback plan documented

Scenario 3 — FSx Windows restore

Expected:

• shadow copy used for file restore
• backup restore to new FSx tested
• AD/DFS path works

Scenario 4 — ONTAP snapshot restore

Expected:

• .snapshot or Previous Versions restores file
• backup-to-new-volume subset restore tested
• ACL/POSIX preserved

Scenario 5 — OpenZFS clone rollback

Expected:

• clone from snapshot created
• validation performed
• selected files copied back
• clone cleaned

Scenario 6 — KMS denied restore

Expected:

• restore fails in controlled test
• key policy fixed
• recovery role validated

15. Terraform/IaC Concepts

15.1 EFS with backup tag

resource "aws_efs_file_system" "app" {
  encrypted = true

  tags = {
    Service    = "report-service"
    BackupTier = "Gold"
    DataClass = "shared-app-files"
  }
}

15.2 AWS Backup selection for EFS/FSx by tag

resource "aws_backup_selection" "file_storage_gold" {
  name         = "file-storage-gold"
  iam_role_arn = aws_iam_role.aws_backup.arn
  plan_id      = aws_backup_plan.gold.id

  selection_tag {
    type  = "STRINGEQUALS"
    key   = "BackupTier"
    value = "Gold"
  }
}

15.3 FSx backup before change

CLI concept:

aws fsx create-backup \
  --file-system-id fs-1234567890abcdef0 \
  --tags Key=Reason,Value=pre-migration Key=Owner,Value=storage-platform

15.4 EFS replication concept

aws efs create-replication-configuration \
  --source-file-system-id fs-12345678 \
  --destinations Region=us-west-2

Validate current parameters and required permissions.

15.5 DataSync copy-back concept

aws datasync start-task-execution \
  --task-arn "$TASK_ARN"

Use DataSync task configured from restored staging file system to production target only after validation.

16. Design Checklist

16.1 EFS

• AWS Backup plan configured.
• Retention matches data class.
• Full restore tested.
• Item-level restore tested.
• Replication evaluated.
• Failover/failback runbook exists.
• Access points recreated by IaC.
• KMS restore tested.
• Lifecycle does not break RTO.

16.2 FSx Windows

• Automatic backup retention set.
• Manual pre-change backup process.
• Shadow copies enabled where useful.
• Restore to new file system tested.
• AD/DFS/DNS recovery tested.
• ACL restore validated.
• Backup/copy strategy aligned with RPO/RTO.

16.3 FSx Lustre

• Scratch vs persistent documented.
• Durable S3 input/output manifests.
• Checkpoint export policy.
• Backup required only for persistent/stateful data.
• Restore/reimport tested.
• Cache/scratch not treated as source of truth.

16.4 FSx ONTAP

• Volume backup policy.
• Snapshot policy.
• File restore from snapshot tested.
• Backup to new volume tested.
• SnapMirror/DR runbook if used.
• Identity mapping validated.
• Clone/snapshot sprawl monitored.

16.5 FSx OpenZFS

• Snapshot policy.
• Clone lifecycle policy.
• Backup policy.
• On-demand replication evaluated.
• Restore via clone tested.
• NFS permission restore validated.
• Sensitive clone policy exists.

17. Mini Case Study — EFS Shared Reports Directory

17.1 Context

Report service stores generated PDFs and templates on EFS.

Directories:

/templates
/reports
/tmp

17.2 Data class

17.3 Protection design

• EFS BackupTier Gold
• daily backup 35 days
• item-level restore test for /templates
• full restore test quarterly
• replication for lower RTO if app critical
• cleanup excludes /templates
• access point root /services/report

17.4 Invariant

Backup policy follows data class, not parent file system alone.

18. Mini Case Study — FSx Windows Finance Share DR

18.1 Context

Finance share requires:

• SMB
• AD groups
• previous versions
• 4-hour RTO
• 24-hour RPO
• quarterly recovery test

18.2 Design

• FSx Windows Multi-AZ
• automatic daily backups
• shadow copies enabled
• manual backup before ACL changes
• backup copied/protected according to compliance requirement
• DFS namespace for client abstraction
• restore test to isolated FSx
• AD DR tested

18.3 Invariant

Windows file recovery requires data, ACLs, AD, DNS/DFS, and client validation.

19. Mini Case Study — ONTAP Dev/Test Restore

19.1 Context

Enterprise app uses FSx ONTAP volume with snapshots.

Need to test new release against production-like data.

19.2 Pattern

• create snapshot before release
• create clone for staging
• run migration/release test
• validate
• delete clone after test
• keep snapshot through rollback window

19.3 If release corrupts prod

• use snapshot/backup to recover selected files/volume
• validate clone first
• copy back or revert with approval

19.4 Invariant

Snapshots/clones reduce recovery risk only when clone lifecycle and restore validation are disciplined.

20. Summary

EFS and FSx data protection is file-system-specific.

Key principles:

1. Restore data and access semantics.
2. Test full and partial restore.
3. Treat identity systems as recovery dependencies.
4. Use EFS Backup for point-in-time restore and EFS replication for lower-RTO DR.
5. Use FSx backups and family-native snapshots/clones where appropriate.
6. Do not confuse shadow copies or snapshots with immutable backup.
7. Preserve permissions and ACLs during copy-back.
8. Restore to staging before production overwrite.
9. Use DataSync/Robocopy/native tools based on protocol semantics.
10. Measure RPO/RTO with app validation.
11. Keep cache/scratch out of backup unless rebuild time exceeds RTO.

The core rule:

A file system is recovered only when the right users and applications can safely use the restored files through the expected protocol.

Next, Part 069 connects compute/storage recovery into full DR architectures: backup-and-restore, pilot light, warm standby, active-active, cross-account recovery, DNS cutover, failover/failback, and region evacuation runbooks.

References

• Amazon EFS User Guide — Backing up and replicating data in Amazon EFS: https://docs.aws.amazon.com/efs/latest/ug/backup-replication.html
• Amazon EFS User Guide — Backing up EFS file systems: https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html
• AWS Backup Developer Guide — Restore an Amazon EFS file system: https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-efs.html
• Amazon EFS User Guide — Replicating EFS file systems: https://docs.aws.amazon.com/efs/latest/ug/efs-replication.html
• Amazon FSx for Windows File Server User Guide — Protecting your data with backups: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html
• Amazon FSx for Windows File Server User Guide — Restoring a backup to a new file system: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/how-to-restore-backups.html
• Amazon FSx for Windows File Server User Guide — Protecting data with shadow copies: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html
• AWS Backup Developer Guide — Restore an FSx file system: https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-fsx.html
• Amazon FSx for Lustre User Guide — Protecting your data with backups: https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-backups-fsx.html
• Amazon FSx for NetApp ONTAP User Guide — Protecting your data with volume backups: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html
• Amazon FSx for NetApp ONTAP User Guide — Restoring files from snapshots: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/user-restore-all-clients.html
• Amazon FSx for NetApp ONTAP User Guide — Restoring a subset of data: https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/data-subset-restore.html
• Amazon FSx for OpenZFS User Guide — Protecting data with snapshots: https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/snapshots-openzfs.html
• Amazon FSx for OpenZFS User Guide — On-demand replication: https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/on-demand-replication.html
• Amazon FSx for OpenZFS User Guide — Restoring backups: https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/restoring-backups.html