Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Cross-Region and cross-account disaster recovery for Amazon FSx for OpenZFS with on-demand replication

4 minute read
Content level: Intermediate
0

EDA and high-tech R&D depend on large shared design-data and simulation-scratch filesystems, frequently replicated across global design centers. On-demand OpenZFS replication provides a warm DR standby and geographic distribution for that IP-heavy data, with incremental block-level transfers. Typical uses:

  • EDA design-data and simulation-scratch DR standby in second Region/account
  • Distributing design data to global R&D and design centers
  • Read replicas for verification and analysis pipelines

Overview

Amazon FSx for OpenZFS supports on-demand data replication, letting you "transfer snapshots of data between file systems within and across AWS Regions and accounts." Common uses include maintaining a passive standby file system for disaster recovery, establishing read replicas for scale-out read performance, and synchronizing data to dev/test environments. (FSx for OpenZFS: Protecting your data with on-demand replication)

You trigger a copy with a single API call or CLI command; FSx transfers data incrementally at the block level using OpenZFS's native send and receive, "manages potential network interruptions and retries automatically until the transfer completes," and encrypts data in transit and at rest. For cross-account transfers it integrates with AWS RAM to authorize volume access. (AWS News Blog: on-demand data replication for Amazon FSx for OpenZFS; FSx for OpenZFS docs)

On-demand data replication is available for all deployment types in Regions where FSx for OpenZFS is available. (FSx for OpenZFS docs)

How it fits a DR strategy

FSx for OpenZFS gives you layered data protection:

  • Daily automatic backups to Amazon S3 (schedule/retention configurable), which you can copy across Regions. (FSx for OpenZFS FAQs)
  • Point-in-time volume snapshots stored within the file system for file-level restore.
  • On-demand replication to a second file system — "By scheduling regular, incremental replication to a second file system, you can implement an active-passive disaster recovery solution." (Amazon FSx for OpenZFS documentation overview)

For a warm standby, replication to a file system in another Region gives you a mountable, ready-to-promote copy — a stronger RTO than restoring from a backup.

Architecture at a glance

on-demand-replication On-demand replication transfers point-in-time snapshots to a separate destination file system that you promote during a DR event (not synchronous mirroring). Diagram summarizes facts cited above.

Reference workflow

  1. Create the destination file system in the target Region (and, for cross-account, in the DR account).
  2. (Cross-account) Share the volume via AWS RAM so the source is authorized to replicate into it.
  3. Start on-demand replication from a source snapshot to the destination file system (single API/CLI call). FSx establishes and maintains connectivity for you.
  4. Schedule ongoing incremental replication — see "Setting up ongoing periodic data replication" in the OpenZFS guide — to keep the standby current.
  5. Test promotion of the standby periodically to validate your recovery runbook.

Best practices

  • Right-size replication frequency to your RPO. Incremental block-level transfers are efficient; schedule them to match how much data loss you can tolerate.
  • Pair replication with cross-Region backups. Replication gives a fast-recovery standby; cross-Region backups give long-retention, cross-Region protection. Use both.
  • Use AWS RAM deliberately for cross-account DR. Isolating the DR copy in a separate account limits blast radius from account-level events.
  • Rehearse failover. A replicated standby you have never promoted is an untested plan — validate mount, permissions, and application connectivity on a schedule.
  • Watch the endpoint/route design if the standby must be reachable from other VPCs (see the Multi-AZ / Transit Gateway guidance for cross-VPC access).

Resources

No comments

Relevant content