Recovery baseline

Model the data path back, not only the copy job out.

Start with the data you must protect and the time you can lose or wait. The planner exposes the capacity floor and transfer assumptions so exact destinations can be checked on comparable requirements.

Home Backup Planner

Build the recovery boundary before choosing a destination.

Keep protected data, expected change, retention, local and offsite copies, recovery objectives, and the limiting transfer path in one inspectable baseline.

View assumptions and sources →

The values below are editable planning baselines. Change the few inputs you know; open Advanced assumptions only when they change your decision.

Advanced assumptionsAdd recovery targets and transfer assumptions when they materially change destination capacity or whether a restore can finish in time.
Minimum destination capacity——
Initial offsite seed——
Scheduled upload window——
Priority restore window——
RPO margin——
RTO margin——

Recovery map

Home or primary site unavailable

Recover independently of the primary location, device, and local network.

  1. Protected data

    2.00 TB current set with 30 days of planned history.

  2. Local recovery copy

    Selected for faster recovery; measure the priority restore path.

  3. Independent offsite copy

    Selected for recovery outside the primary site; verify separate access.

Next proof

Prove independent access

Use the offsite account and documented access path from outside the primary site.

Destination decision

Compare capabilities in the order this failure path needs.

These are capability checks for an exact destination, not a ranked product list.

  1. Independent offsite recovery

    Compare the selected independent recovery path

    ≥ 2.12 TB and ≥ 0.5 Mbps upload

    Verify 30 days of retained history and access that does not depend on the primary site.

  2. Fast local recovery

    Compare the selected local recovery path

    ≥ 2.12 TB usable capacity

    Measure whether 1.00 TB can be restored within the 48.0 h recovery-time objective.

  3. Retained version recovery

    Verify the recovery point, not only storage capacity

    30 days of retained history

    Confirm how an older version is located, what deletion behavior applies, and whether the intended recovery point can be restored without overwriting the only working copy.

Destination requirements

Compare destination paths against the recovery boundary.

Use these conditions to compare an exact destination path after capacity, retention, topology, and transfer inputs are set.

Minimum usable destination capacity
≥ 2.12 TB

2.00 TB current data + 0.12 TB retained change.

Required retained history
30 days

Check the selected destination’s version lifecycle and deletion behavior.

Copy placement
Local + independent offsite copy

Keep the offsite copy independently located, then document its access and restore procedure.

Minimum modeled upload path
≥ 0.5 Mbps

0.004 TB per 24 h interval at 70% planning efficiency.

Minimum modeled restore path
≥ 66.1 Mbps

1.00 TB priority data within 48.0 h at 70% planning efficiency.

Restore evidence
Representative timed restore

Recover selected data and an older retained version through the intended access path.

Recovery result

—

—

Planning brief

Carry the data, transfer, and recovery checks together.

Copy a destination-neutral baseline, then verify the selected product’s retention, independent access, cost, and restore workflow.

Next decision

Record a restore testPlan NAS recoveryMap Docker state

Plan tools

Keep this useful version close, shareable, and easy to revisit.

Reset inputs

Optional support

Keep practical planning tools available.

If this result made the next decision clearer, an optional contribution helps cover hosting, source reviews, and continued improvements.

Choose a small tip on Ko-fi

Capacity basis

The retained-change estimate uses current data plus a linear change window. It intentionally does not promise a compression or deduplication ratio.

Transfer basis

Mbps is converted to MB/s and reduced by the entered efficiency. Use a measured path later to replace this planning baseline.

Recovery proof

A projected restore duration is a requirement to test, not proof that applications, credentials, historic versions, and dependencies are recoverable.