Instant Database Cloning (Zero-Copy PITR in Seconds)

💡 What You’ll Learn

● How Instant Database Cloning works internally (zero-copy + copy-on-write)
● How to recover from a DROP TABLE disaster in seconds
● How to safely create production clones for dev/test
● Key performance + storage considerations before using it

What Is Instant Database Cloning?

Instant Database Cloning in YugabyteDB lets you create a fully writable, independent copy of a database instantly… without copying data.

It’s powered by:

● Zero-copy initialization
● Point-in-Time Recovery (PITR)
● Copy-on-write storage

👉 This means cloning works in seconds… even for terabyte-scale databases.

How It Works (Zero-Copy Magic)

⚙️ Core Architecture

● Shared Storage: Clone initially points to the same underlying SST files
● Logical Isolation: Clone is a completely separate database
● Copy-on-Write: Changes create new files… data diverges only when modified

👉 Result: Instant clone + minimal initial storage cost

Key Use Cases

1. Data Recovery (🔥 Most Powerful Use Case)

Accidentally ran:

				
					DROP TABLE important_data;

Instead of restoring backups…

👉 Clone the DB to a timestamp before the mistake

2. Dev / Test Environments

Spin up production-like environments instantly

Test:

● DDL changes
● Query tuning
● Migration scripts

👉 Zero impact on production workload

Demo: Recover a Dropped Table in Seconds

Step 1️⃣: Enable Snapshot Schedule (Required)

				
					./bin/yb-admin create_snapshot_schedule 1440 4320 ysql.my_production_db

● Snapshot every 24 hours
● Retain history for 3 days

⚠️ Prerequisite

Cloning relies on PITR history.

No snapshot schedule = no ability to go back in time.

Step 2️⃣: Capture a Safe Timestamp

				
					SELECT (EXTRACT(EPOCH FROM CURRENT_TIMESTAMP) * 1000000)::BIGINT AS safe_timestamp;

Example output:

				
					1723243720285350

Step 3️⃣: Simulate Disaster 😬

				
					DROP TABLE important_data;

Step 4️⃣: Clone Database at Safe Time

				
					CREATE DATABASE recovery_clone
TEMPLATE my_production_db
AS OF 1723243720285350;

Step 5️⃣: Verify Recovery

				
					\c recovery_clone
SELECT * FROM important_data;

✅ Data is restored instantly

🚀 Key Insight

This replaces a full restore (hours) with a clone operation (seconds).

Advanced Recovery: Copy Data Back (FDW Method)

Instead of dumping/restoring…

Use postgres_fdw to copy directly:

Step 1: Connect to Clone

				
					CREATE EXTENSION postgres_fdw;

CREATE SERVER clone_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host '127.0.0.1', port '5433', dbname 'recovery_clone');

CREATE USER MAPPING FOR current_user
SERVER clone_server
OPTIONS (user 'yugabyte', password 'yugabyte');

Step 2: Import + Restore Table

				
					IMPORT FOREIGN SCHEMA public
LIMIT TO (important_data)
FROM SERVER clone_server INTO public;

INSERT INTO important_data
SELECT * FROM important_data;

👉 Fast, direct, no intermediate files

⚠️ Note: FDW is convenient, but not always the best choice for very large tables. For bulk restores, consider using an export/import workflow instead for better performance and scalability.

How to Enable Cloning

Set the YB-Master flag:

				
					--enable_db_clone=true

Monitoring Clone Operations

				
					yb-admin list_clones

Best Practices & Gotchas

⚠️ Important Considerations

● Resource Usage: Clones create new logical tablets → increased CPU/memory
● Storage Growth: After compaction, storage increases because:
- ○ Old shared files are retained
- ○ New compacted files are created
● Cleanup Matters: Always drop clones when done:
DROP DATABASE recovery_clone;
● Limitation: Cloning before dropping Materialized Views is not supported

YCQL Equivalent

				
					yb-admin clone_namespace

Final Takeaway

🏁 TL;DR

● Instant DB Cloning = zero-copy + copy-on-write
● Enables point-in-time recovery in seconds
● Perfect for accidental deletes + dev/test cloning
● Requires snapshot schedule (PITR)

👉 This is one of the most powerful (and underused) features in YugabyteDB.

Have Fun!