How the calculators work

Understand what each result includes—and what it leaves out—before using it in an operational plan.

Backup retention: select periods, then combine

1. Generate one simulated backup at 03:00 UTC every day or every seven days, starting on the first date. The interval can span up to 366 calendar days, inclusive.
2. For each rule, consider the most recent occupied periods. Empty periods do not consume the count.
3. Select the latest backup in each chosen day, ISO week, month or year. ISO weeks run Monday to Sunday; all boundaries use UTC.
4. Combine these selections. A backup chosen by several rules is retained once, with all matching reasons.

The latest supplied backup anchors selection; the tool does not simulate expiry at a separate future date. The current, incomplete week or month also counts if it contains a backup. A zero-valued rule selects nothing; setting all four rules to zero retains no backups.

Worked example: August 2026

Generate daily backups from 1 to 31 August 2026, with daily = 7, weekly = 4, monthly = 2 and yearly = 0.

• Daily selects 25–31 August.
• Weekly selects 16, 23, 30 and 31 August. The 31st is in the next ISO week.
• Monthly selects 31 August. There is only one occupied month, even though the rule asks for two.

The union contains 9 backups: 16, 23 and 25–31 August. Try this in the Retention Planner.

What retention does not model

There is no storage-capacity estimate or dependency analysis for full and incremental backup chains. “Excluded” means not selected by this generic policy, not safe to delete from a real repository. Product-specific rules, legal holds, immutability and application dependencies are outside the model.

Data transfer: the slowest limit wins

Network rate in decimal MB/s = link Mbps × efficiency ÷ 8, where efficiency is a fraction from greater than zero to one. If a storage limit is supplied, effective throughput is the smaller of the network rate and that limit.

Duration in seconds = data size in bytes ÷ (effective MB/s × 1,000,000).

Worked example: one terabyte

1 TB over a 100 Mbps connection at 80% efficiency gives 10 MB/s and approximately 27.78 hours. A 5 MB/s storage limit doubles that to approximately 55.56 hours. Try this in the Transfer Estimator.

Transfer time is not total recovery time

The estimate assumes constant throughput and that the entered size is the volume actually transferred. It does not separately model compression, deduplication, latency, contention, CPU work or protocol behavior. Use measured efficiency where possible, and the slower of source read and destination write rates for the storage limit.

Archive retrieval, backup discovery, application startup and validation can add time. Some work can overlap; others must happen in sequence. Test the complete recovery workflow against your recovery objective rather than treating this transfer estimate as an RTO guarantee.