DR Seeding and RPO Feasibility over a 200 Mbps Link
Region A holds 300 TB of object storage, 40 TB of Oracle database, and 12 TB of file data. Region B is the DR site, connected by a 200 Mbps dedicated link that sustains 160 Mbps. Required RPOs are: object 15 minutes, database 5 minutes, file 1 hour. Required RTO is 2 hours for all tiers. Daily change rates are: object 1.2 TB, database archive logs 300 GB, file 200 GB. The vendor proposes to seed all data over the link, then replicate continuously. A previous 10 TB test seed took 9 days and saturated the link, delaying production traffic. The business wants a tested DR switchover twice a year and a documented decision on what can be cold-started.
1. Calculate whether the initial 352 TB seed is feasible over the link. Show the math using sustained bandwidth.
Read the worked answer
Total data is 300 + 40 + 12 = 352 TB. Using decimal units, 352 TB = 352,000,000 MB. Sustained bandwidth is 160 Mbps = 20 MB/s. Time = 352,000,000 / 20 = 17,600,000 seconds = 203.7 days. Even at the theoretical 200 Mbps, 25 MB/s, it is 14,080,000 seconds = 163 days. The previous 10 TB test took 9 days, which implies an effective rate of about 10,000,000 MB / 777,600 s = 12.9 MB/s, consistent with overhead and production contention. At that effective rate the full seed would take about 316 days. Initial seeding over the link is not feasible.
2. Design the seeding, ongoing replication, and QoS plan to meet the RPOs.
Read the worked answer
Seeding: use physical transfer for the bulk. Encrypt the object and file data onto an appliance or disks, ship to Region B, import, and verify checksums and object counts. For Oracle, ship a full RMAN backup and a standby control file, restore the standby, then start redo apply from the current archive logs. Do not attempt a 300 TB object seed over a 160 Mbps link. After the baseline, enable incremental replication and reconcile before declaring the standby ready.
Ongoing rates: database 300 GB/day = 300,000 MB / 86,400 s = 3.47 MB/s average. A 5-minute RPO needs about 1.04 GB per interval, or 3.47 MB/s sustained, which fits. Object 1.2 TB/day = 1,200,000 MB / 86,400 = 13.9 MB/s average; a 15-minute RPO needs 12.5 GB per interval, or 13.9 MB/s sustained. File 200 GB/day = 2.3 MB/s; a 1-hour RPO needs 8.3 GB per hour, or 2.3 MB/s. The combined average is 19.7 MB/s against 20 MB/s usable, leaving almost no burst headroom.
QoS: prioritize database redo, then object, then file. Reserve at least 12 MB/s for database, 6 MB/s for object and 2 MB/s for file. That object allocation cannot meet a 15-minute RPO at the stated change rate; either upgrade to about 500 Mbps, reduce object RPO to about 1 hour, or add compression and deduplication. Monitor replication lag per tier and alert before RPO breach, not after.
3. Assess the 2-hour RTO claim for the database and object tiers.
Read the worked answer
The database can meet 2 hours only if Region B runs a pre-seeded standby with continuous redo apply and automated failover. Restoring a 40 TB backup at 20 MB/s would take about 23 days over the link and is irrelevant to RTO. With a warm standby, the switch is redo apply stop, role transition, connection-string or DNS change, and validation. The 5-minute RPO should be measured as apply lag. Test twice a year, including a switchback.
The object tier cannot restore 300 TB in 2 hours from the link. RTO must be met by a replicated bucket or active-passive endpoint switch, with metadata and permissions already synchronized. That covers site loss, not logical deletion or ransomware; add versioning and a separate immutable backup with a longer recovery time. The file tier needs a warm standby or replicated file service. Document that cold-start is acceptable only for non-critical reporting or archive workloads whose owners accept multi-day recovery. For every tier, write a runbook with decision authority, DNS TTL, validation checks and abort criteria.