Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths
A side-by-side comparison of copy-and-replay recovery and branch-at-a-point restores, showing why restore time scales with data size in one model and not the other.
Loading…
Topic
Disaster Recovery
3 posts about Disaster Recovery. Every summary links to the original.
- 3 posts
- 1 company
- 2 explainers
See the idea
Disaster Recovery explainers
Amazon EVS Architecture: Where vSAN Ends and FSx for ONTAP Begins
Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Multi-region disaster recovery for Amazon API Gateway WebSocket APIs
WebSocket connections for real-time applications like live auctions and collaborative editors are vulnerable to regional outages because each connection is tied to a single AWS Region. A regional failure severs all active connections and loses session state. This post presents an active-passive multi-region disaster recovery pattern that uses Amazon API Gateway WebSocket APIs, Route 53 failover routing, DynamoDB Global Tables for cross-Region state replication, a canary health probe, and client-side reconnection logic. The canary Lambda function tests the endpoint every minute and drives a CloudWatch alarm that triggers a Route 53 health check to mark the primary Region unhealthy. Clients detect connection drops via application-level heartbeat messages and reconnect with exponential backoff and full jitter to avoid thundering herd. After reconnection, clients retrieve the latest application state from the secondary Region’s DynamoDB replica and resume their session automatically.
Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP
This post provides step-by-step procedures to deploy Oracle Database on Amazon Elastic VMware Service (Amazon EVS) with Amazon FSx for NetApp ONTAP as NFS datastore storage. It covers provisioning storage volumes, mounting NFS datastores, installing Oracle 19c, and configuring SnapMirror replication for cross-region disaster recovery. The deployment uses FSx for ONTAP volumes pinned to SSD tier and presents them as VMDKs on NFS datastores, with Oracle accessing them as local XFS filesystems. Four migration paths are detailed for moving on-premises Oracle workloads, including SnapMirror-based replication for existing ONTAP environments and RMAN backup/restore for non-ONTAP storage. Day-2 operations such as snapshot backup, point-in-time recovery, and database cloning via SnapCenter FlexClone are also covered.
Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP
Enterprises with existing VMware Cloud Foundation investments can migrate Oracle databases to AWS using Amazon Elastic VMware Service (EVS) and Amazon FSx for NetApp ONTAP without rearchitecting applications or retraining operations teams. The architecture splits storage between vSAN for low-latency transient workloads and FSx for ONTAP NFS datastores for Oracle data files and redo logs, delivering sub-millisecond latency and up to 80,000 IOPS. Cross-region disaster recovery uses SnapMirror to asynchronously replicate FSx for ONTAP volumes, with pre-provisioned standby Oracle VMs that mount replicas only after failover to avoid Oracle double licensing. Recommended EC2 bare metal instance types include i7i.metal-24xl for per-core compute speed and i7i.metal-48xl for vertical scaling, both supporting VCF 9.1. Migration options include VMware HCX for live migration, SnapMirror for ONTAP-to-ONTAP transfer, and RMAN for universal database movement.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.