Repository Mirror Calculator
Calculate sync time for a package repository mirror from repo size and bandwidth, plus storage per mirror.
Inputs
Incremental syncs only transfer changed/new packages
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
Values used
Repository Size (GB) = 500; Available Bandwidth (Mbps) = 100; Number of Mirrors to Sync = 3; Fraction Changed Since Last Sync (%) = 5
Sync time
sync_time = repo_size / bandwidth; incremental_sync_time = full_sync_time × changed_fraction
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
How it works
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
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.