How it is calculated
| Initial copy | GB × 8 × 109 ÷ (Mbit/s × 106 × efficiency) |
|---|---|
| Changed meanwhile | daily change × initial copy hours ÷ 24 |
| Final sync | change in the last gap hours, at the same link speed |
| Daily capacity | link × efficiency × 86,400 s ÷ 8 × 109 |
Worked example
Worked example
5,000 GB at 500 Mbit/s and 80% efficiency takes 100,000 seconds, or 27.8 hours. At 48 GB of change a day, 55.6 GB changes during the copy. With hourly catch-up syncs, the final sync carries 2 GB and takes about 40 seconds, well inside a 2-hour window.
Assumptions and limits
- Rsync-style tools re-read files to find changes; very large file counts add time that bandwidth alone does not show.
- Databases should move by replication or a consistent dump, not by copying live files. See the migration guide.
- Lower DNS TTLs at least one full TTL before cutover.
How we test this tool
Unit tests pin the example above (27.78 h initial copy, 55.6 GB delta, 4,320 GB of daily capacity, final sync inside the window).
Frequently asked questions
When should I ship disks instead?
When the initial copy takes more than about a week, or the link cannot keep up with the daily change rate. Seed with a physical transfer, then sync the changes over the network.
Related
Inputs stay in your browser. Tool maths last reviewed ; the unit tests that pin these formulas are listed in the evidence hub.