Recovery objectives

Set home-backup RPO and RTO from the copy and restore windows

RPO asks how old the recovered point may be; RTO asks how long recovery may take. A copy schedule and a restore transfer window answer different questions.

Give data loss and downtime different limits

Recovery-point objective (RPO) is the maximum age of the recovered point you can accept. Recovery-time objective (RTO) is the maximum interruption before the priority service or data must be available again. They are related, but neither proves the other.

Start with plain-language decisions: how much work can be recreated, and which data or service must return first. Then turn those answers into hours.

Check the copy interval against RPO

A scheduled copy interval must be no longer than the RPO it is meant to serve. A daily copy cannot meet a four-hour recovery-point target, even if the destination has abundant capacity.

Next, check whether the changed data can actually finish within the chosen interval. The planner converts connection Mbps to MB/s and applies an efficiency allowance so an advertised line rate is not treated as sustained backup throughput.

Check the priority restore set against RTO

Recovery rarely begins with every byte. Define the smallest data set that restores the essential workflow, then calculate its transfer duration using the restore-side path. That time is a floor for data transfer, not a complete application recovery estimate.

If the priority set misses RTO, the first levers are clear: reduce the priority set, improve the measured path, or preserve a faster local recovery tier. Changing only the destination name does not remove the transfer constraint.

Make the first full copy a deliberate event

The initial offsite seed can be far longer than ongoing changed-data uploads. Model it separately and decide how it will complete without silently assuming an unlimited connection or an instant cloud upload.

Continue planning

Turn this recovery question into a visible baseline.

Use the planner to keep retained capacity, copy topology, recovery objectives, and the limiting transfer path together.

Check recovery objectives

Capacity baseline

Estimate backup capacity from retention, not only current data

Restore proof

Run a home-backup restore test that measures the recovery path

Editorial record

Maintained by Make Your Own Tools to turn “Protect and restore data” into a defined capacity, copy topology, recovery window, and restore-test baseline. The references below provide the technical context for this planning path. Its calculation rules and planning assumptions are documented in the methodology, and affected calculations pass regression checks before the review date advances.

Last reviewed
Evidence set
2 primary references
Calculation coverage
3 affected rules checked
Read methodology →View change history ↗
Planning scope
Recovery-objective and transfer-window planning before selecting a backup destination or internet tier.
Next check
Replace planning throughput with a measured copy and restore path; verify application dependencies, destination throttling, retrieval delays, and account access separately.
AWS Well-Architected: define recovery objectivesDefines recovery-point and recovery-time objectives as explicit limits for data loss and service interruption.Open source ↗NIST SP 800-34 Rev. 1 contingency planning guideGovernment guidance covering contingency planning, backup operations, restoration time periods, alternate storage, and recovery procedures.Open source ↗