Repository Mirror Calculator
Calculate storage and bandwidth needed to host a local mirror of a package repository.
About Repository Mirror Calculator
Mirror sync time is bounded by available bandwidth divided into repository size — tools like `reposync` (yum/dnf) or `apt-mirror`/`debmirror` (Debian/Ubuntu) transfer the full repo on first sync, then only changed or newly published packages on subsequent runs, which is why incremental sync time (scaled by the fraction of the repo that actually changed) is typically far shorter than a full resync. Each additional mirror multiplies total storage requirements linearly since each holds a complete independent copy, though sync time per mirror stays the same if each has independent bandwidth.
Formula
Sync time
sync_time = repo_size / bandwidth; incremental_sync_time = full_sync_time × changed_fraction
- S
- repo size
- B
- available bandwidth
Worked example
With the default values below, Repository Mirror Calculator returns Full Sync Time (per mirror) of 11h 22m 40s. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Repository Size (GB)minimum 0.1
- 500
- Available Bandwidth (Mbps)minimum 1
- 100
- Number of Mirrors to Syncminimum 1
- 3
- Fraction Changed Since Last Sync (%)accepts 0–100
- 5
Results
- Full Sync Time (per mirror)
- 11h 22m 40s
- Incremental Sync Time (per mirror)
- 34m 8s
- Total Storage Across All Mirrors (GB)
- 1,500.0
- Storage per Mirror (GB)
- 500.0
Step by step
- 1Values used
- 2Sync time
- 3Full Sync Time (per mirror)= 11h 22m 40s
- 4Incremental Sync Time (per mirror)= 34m 8s
- 5Total Storage Across All Mirrors (GB)= 1,500.0
- 6Storage per Mirror (GB)= 500.0
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is my first mirror sync so much slower than subsequent syncs?
The initial sync must transfer the entire repository, while subsequent runs only need to download packages that changed or were added since the last sync (an incremental/delta sync) — for slowly-changing repos this can be a 90%+ reduction in transfer volume on later runs.
Should mirrors sync from the upstream source or from each other?
For multiple internal mirrors, syncing all of them from a single upstream source independently multiplies external bandwidth usage; a common pattern is one internal mirror syncing from upstream, with other internal mirrors then syncing from that first one to conserve external bandwidth and reduce load on the public repository.
How much storage headroom should a mirror have beyond the current repo size?
Most sync tools (rsync, reposync) do their work in a staging area or need room for both old and new versions of changed files during the sync itself, so allowing roughly 10-20% headroom above current repo size is a common safety margin to avoid a sync failing partway through due to a full disk.