---
title: "Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths"
description: "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."
---

# Copy-and-Replay vs Branch-at-a-Point: Two Backup Recovery Paths

**Type:** [Comparison](https://yomu.fyi/visual-explainers/category/comparison.md)

![Two-column comparison diagram: the left column shows copy-and-replay recovery from snapshot copy to WAL replay, the right shows a branch-at-a-point restore as one metadata step on a shared timeline, with a decision cue bar below.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/40b2363e-f75f-48f1-9f5d-5927c0a217c2/image-0a8e53ed-6c1d-46f4-ab01-a50fca87718a.webp)

> 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.

## Explanation

Backups carry two separate costs: the read load a backup puts on production while it runs, and the time a restore takes when you actually need it. This comparison sets copy-and-replay recovery, where a snapshot is copied to disk and WAL is replayed, against branch-at-a-point restores on decoupled storage, where recovery is a metadata operation. It also shows where snapshot replication and standby instances fit, and why replication alone is not a backup.

## FAQ

### Why does a large database restore take hours in one model and seconds in the other?

In copy-and-replay, restore provisions a new instance, copies the snapshot from object storage back to disk, then replays WAL to the target point, so work scales with data size. With decoupled compute and storage, history is an immutable timeline and a restore is a branch at a point, a metadata operation that copies no data. So a 100 TB database can restore about as fast as a 10 GB one.

### Does a backup slow down the production database it reads from?

It can. A base backup reads every byte off the same drives serving queries, and buffered reads pass through the kernel page cache, evicting warm database pages. Direct I/O skips that cache so warm data stays in place, but it also disables kernel readahead, so read sizes may need tuning to the storage layout.

### Is replication a substitute for backups?

No. Synchronous replication with automated failover protects against losing a node and helps prevent data loss during failover, but it mirrors the same logical state, so a bad migration or an accidental delete propagates too. You still need a restore point you can branch to or replay back to.

**Tags:** [Backups](https://yomu.fyi/topic/backups.md), [Direct I/O](https://yomu.fyi/topic/direct-io.md), [Disaster Recovery](https://yomu.fyi/topic/disaster-recovery.md), [Postgres](https://yomu.fyi/topic/postgres.md), [Reliability](https://yomu.fyi/topic/reliability.md), [Replication](https://yomu.fyi/topic/replication.md)

## Related reading

### [Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP](https://yomu.fyi/post/deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-for-ontap.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Satish Bhoi
- Published: Oct 2, 2026
- Type: Tutorial

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](https://yomu.fyi/post/architect-highly-available-oracle-database-on-amazon-evs-and-fsx-for-o.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Satish Bhoi
- Published: Oct 2, 2026
- Type: Tutorial

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.


### [Scale without limits: Multigres, OrioleDB, and dbarena](https://yomu.fyi/post/scale-without-limits-multigres-orioledb-and-dbarena.md)
- Company: [Supabase](https://yomu.fyi/company/supabase.md)
- Author: joe\_sciarrino, alexander\_korotkov, daniel\_mitterdorfer, aditya\_maruvada
- Published: Oct 2, 2026
- Type: Announcement

At Supabase Select, Supabase announced Multigres for high availability and connection pooling, OrioleDB for high performance storage, and dbarena for transparent benchmarking. Multigres is an open source operating system for Postgres that adds scalable connection pooling and automated multi-node failover using a consensus protocol built on synchronous replication, preventing data loss during failover. OrioleDB replaces Postgres’s heap storage with an undo log-based engine that eliminates bloat, VACUUM overhead, and transaction ID wraparound by using 64-bit transaction IDs, delivering up to 1.8x higher throughput in TPC-C-derived benchmarks. dbarena.com is an open benchmarks site that publishes reproducible performance and cost comparisons across managed Postgres providers including Supabase, Amazon RDS, and Google Cloud SQL, with full methodology and raw data. These tools aim to remove scaling limitations at every layer of Postgres, with all improvements being open source and available to the community.


### [What is direct I/O, and why does ClickHouse Managed Postgres use it for backups?](https://yomu.fyi/post/what-is-direct-i-o-and-why-does-clickhouse-managed-postgres-use-it-for.md)
- Company: [Clickhouse](https://yomu.fyi/company/clickhouse.md)
- Published: Oct 2, 2026
- Type: Explainer

A base backup reads every byte of a live database off the same NVMe drives that serve queries. Buffered reads go through the kernel page cache, evicting warm database pages and adding a kernel copy per byte. Direct I/O skips the cache, leaving Postgres’s warm data in place, but also disables kernel readahead. On a RAID0 array, small direct reads hit only one drive, so ClickHouse Managed Postgres sizes each direct read to span the whole stripe and scales the reader count to the hardware. On a 48 vCPU box with four NVMe drives and a 467 GB database, the direct I/O backup evicted nothing, cut query latency impact by about two thirds, used about 14% less CPU, and finished in 71 seconds.


### [Lakebase Postgres branch-based restores for fast recovery at scale](https://yomu.fyi/post/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Cassie Murray, Carlota Soto
- Published: Oct 1, 2026
- Type: Explainer

Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.