Meeting SQL and Oracle RTOs Without Multiplying Full Backups
An environment has 45 SQL Server instances totaling 18 TB, eight Oracle databases totaling 6 TB, and 200 Linux file servers. The business requires a 1-hour RTO for Tier 1 SQL databases, 2 hours for Oracle, and 4 hours for files. SQL uses weekly full, daily differential, and 15-minute transaction-log backups. Oracle uses weekly RMAN full, daily incremental, and archive-log backups every 6 hours. The six-node cluster has 300 TB usable and is 72% full. The DR cluster is 600 km away over a 200 Mbps link with 60 ms latency. Only 40 of the SQL databases are Tier 1; the rest are internal reporting. A recent restore test of a 2.4 TB SQL database took 5 hours, mostly replaying logs, and missed the RTO. The team proposes taking full backups every 4 hours to speed recovery and replicating every workload to DR.
1. Why did the 2.4 TB SQL restore miss the RTO, and what restore options or policy changes should be evaluated before adding full backups every 4 hours?
Read the worked answer
The restore time was dominated by log replay, not by the size of the data files alone. A 2.4 TB database with 15-minute log backups can require a long chain of transaction logs to reach the recovery point. Replaying that chain is CPU- and I/O-intensive, and the restore target may also be undersized. Weekly fulls and daily differentials reduce the number of log backups that must be applied, but they do not eliminate the replay of logs taken since the last differential.
Before adding full backups every 4 hours, evaluate:
- Instant recovery or clone-and-mount: if the platform can present a SQL database from a snapshot quickly, use it to meet the 1-hour RTO and then migrate or switch over. Test this with the actual 2.4 TB database, not a small sample.
- Restore target performance: confirm that the target storage, CPU, and network can sustain log replay. A fast backup cannot compensate for a slow restore target.
- Recovery point choice: restoring to the latest point requires all logs. If the business can accept a slightly older point, a snapshot-based recovery may meet the RTO.
- Log backup frequency: more frequent log backups reduce potential data loss but increase the number of logs to replay. Do not increase frequency without testing restore time.
- Tiering: only 40 databases are Tier 1; apply aggressive RTO measures there. Full backups every 4 hours for all 45 instances would consume capacity and backup window for reporting databases that do not need it.
Measure the restore chain end to end, then choose the smallest change that meets the RTO.
2. Design the DR replication approach for the stated RTOs and WAN. Which workloads should replicate and on what schedule?
Read the worked answer
Replicate by RTO and business criticality, not by workload count. The 200 Mbps link with 60 ms latency cannot carry every workload without compromising recovery.
- Tier 1 SQL: replicate on a schedule that supports the 1-hour RTO. Because SQL log backups occur every 15 minutes, the replica must receive the data and logs frequently enough to reconstruct the recovery point. Use change-based replication and monitor replication lag; a replica that is two hours behind does not meet a 1-hour RTO.
- Oracle: replicate the eight databases with a schedule aligned to the 2-hour RTO. Archive-log shipping every 6 hours is not sufficient for a 2-hour RTO unless the recovery strategy relies on a different mechanism. Increase archive-log backup and replication frequency, or document a longer RPO if the business accepts it.
- Linux file servers: replicate only the file sets that require the 4-hour RTO. Static or low-change shares may need daily replication; high-change shares need more frequent replication or a local recovery strategy.
- Internal reporting SQL: do not replicate unless a DR requirement exists. They can be restored from local backups or rebuilt.
Use the initial seed carefully: replicating 18 TB of SQL and 6 TB of Oracle over 200 Mbps will take days. Seed the DR cluster through an alternate method or prioritize the most critical databases first. Test a DR restore, not just replication completion.
3. How should the team address the 72% capacity before adding more retention or full backups?
Read the worked answer
At 72% used on 300 TB usable, the cluster has about 84 TB free. Full backups every 4 hours would consume space quickly, and the DR cluster also needs capacity for replicas. Adding retention without reclaiming space is the wrong order.
First, determine what is consuming capacity: stale snapshots, expired backups that are still retained by policy, orphaned protection groups, test copies, or archive staging. Cohesity deduplication and compression reduce physical usage, but they do not make repeated full backups free. Review the retention on non-Tier-1 SQL and reporting databases; they may be keeping more history than the business requires.
Second, separate local retention from archive retention. Move long-term copies to the archive target and keep only the operational recovery window on the cluster. Confirm that archival is actually completing and not leaving staging data on the cluster.
Third, if capacity is still tight, add nodes before Crossing a safety threshold. A cluster that is rebuilding or ingesting a new full-backup workload at high utilization has little headroom for recovery. Adding a node also increases rebuild and rebalance time, so plan it before an incident, not during one.
Finally, evaluate whether full backups every 4 hours are the right tool. If instant recovery or snapshot-based recovery meets the RTO, the capacity cost is lower and the backup window is shorter. Capacity planning should follow the recovery design, not drive it.