Cloud backup plans often fail on arithmetic, not technology. The first full upload takes three weeks instead of a weekend, or the restore everyone assumed would take an afternoon needs more than a day on the office connection. This calculator does the sums first. Enter the amount of data, your upload and download speeds and your recovery time objective, and it returns the time for the first full backup, the daily incremental and a full restore, with a plain check against the RTO. It is meant for small-office IT, managed service providers and continuity managers checking a recovery assumption.
How the calculator works
Every result comes from one transfer formula, in decimal units the way drive makers and cloud bills count (1 TB = 1,000 GB, and 1 GB = 8,000 megabits):
Hours = gigabytes × 8,000 ÷ (link speed in Mbps × efficiency) ÷ 3,600
As a check, 1 GB over a perfect 8 Mbps link takes 1,000 seconds.
The tool applies it three times:
- Full upload: the data left after compression and deduplication, over the upload speed.
- Daily incremental: that amount × the daily change rate, over the upload speed.
- Full restore: the data after savings, pulled back over the download speed. A restore at or under the RTO passes.
The inputs, and how to fill them in:
- Data size. Decimal gigabytes. Operating systems often report binary units, so a volume Windows shows as 1.82 TB holds about 2 TB in decimal terms.
- Upload and download speed. Megabits per second, as providers quote them. Measure where you will restore, which after a disaster may be a home office.
- Link efficiency. The share of the line rate a long transfer really achieves after protocol overhead, other traffic and provider throttling. The 80 percent default suits a quiet wired line; use less for shared, busy or wireless links.
- Compression and deduplication savings. Take this from a real job report, not a brochure. Photos, video and encrypted files save little; office documents and virtual machine images often save more.
- Daily change rate. The share of data that changes each day, from your backup software's job history. The 2 percent default is a placeholder.
- RTO. Your recovery time objective.
Worked example
The tool opens with 2 TB (2,000 GB), a 20 Mbps upload, a 200 Mbps download, 80 percent link efficiency, no compression or deduplication savings, a 2 percent daily change rate and a 24-hour RTO.
- Full upload: 2,000 GB × 8,000 = 16,000,000 megabits. The effective upload is 20 Mbps × 80 percent = 16 Mbps (2 megabytes per second), so that is 1,000,000 seconds, about 277.8 hours. The tool shows 11 d 14 h.
- Daily incremental: 2 percent of 2,000 GB is 40 GB, which takes 20,000 seconds, or 5 h 33 min. That fits an overnight window, though not by much.
- Full restore: the effective download is 200 Mbps × 80 percent = 160 Mbps, so 16,000,000 megabits take 100,000 seconds, about 27.8 hours (1 d 4 h in the summary).
- RTO check: 27.8 hours against 24 misses by about 3.8 hours.
Now set the savings to 25 percent. Only 1,500 GB moves, the restore drops to about 20.8 hours (20 h 50 min) and the plan fits with about 3.2 hours to spare. Without savings, only a nominal download of about 231 Mbps would finish the transfer inside 24 hours.
What the transfer time leaves out
An RTO covers far more than moving bytes. Detection, declaration, rebuilding servers and identity services, and checking the data all run on the same clock. A 20.8-hour restore against a 24-hour RTO leaves about three hours for all of that, rarely enough. Our guide to setting RTO and RPO without guesswork covers budgeting the whole recovery.
Other limits:
- First full backup: when the upload runs past a week, ask whether your provider accepts a seeded first copy on an encrypted drive sent by courier. Some also restore onto a shipped drive, which can beat a slow download.
- Bottlenecks beyond the link: the target disk's write speed, decryption and decompression on the restoring machine, rehydration of deduplicated data, per-stream limits at the provider, and millions of small files, which restore far slower than one large image. Restoring several machines at once splits the link between them.
- Immutable copies: after ransomware you may need an older, locked recovery point, with more change to replay. See immutable backups and clean-room recovery.
- Testing: CISA's ransomware guide calls for regularly testing the availability and integrity of backups. Time a restore of realistic size and use measured throughput ÷ line rate as the efficiency figure.
Keeping a local copy so the restore does not wait on the internet
The quickest fix for a failed RTO check is often a first restore that does not need the internet. The same 2,000 GB over gigabit Ethernet at 80 percent efficiency takes about 5 h 33 min, provided the disks at each end keep up. A small network storage box holds the on-site copy. A portable SSD, rotated off-site and unplugged between runs, gives you an offline copy that malware on the network cannot reach. With the cloud backup, that is the familiar 3-2-1 pattern: three copies, on two kinds of media, one of them off-site. Put the storage box on a small battery backup unit so a power cut does not interrupt a write.
Readiness kit
| Category | Pick | Why it is on the list | Link |
|---|---|---|---|
| Local backup (NAS) | Synology DS223 2-bay NAS | Mirrored local copies plus built-in cloud sync: the on-site leg of a 3-2-1 plan for a small office. | Shop on Amazon |
| Offline backup drive | SanDisk Extreme 2TB portable SSD | Fast, rugged drive for an offline copy that ransomware on the network cannot reach. | Shop on Amazon |
Both suggestions rest on manufacturer specification sheets and published reviews; we have not tested either device. Note that the storage box ships without drives.
If your restore still overshoots the RTO, the downtime cost calculator prices each extra hour for the budget case.
Sources
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems.
- CISA, #StopRansomware Guide: offline, encrypted and regularly tested backups.
- NIST SP 800-209, Security Guidelines for Storage Infrastructure.
Frequently asked questions
How long does it take to upload 1 TB to the cloud?
At 20 Mbps with 80 percent efficiency, 1 TB takes about 138.9 hours, or 5 d 18 h: a little over 8 minutes per gigabyte. Doubling the upload speed halves the time.
Why is my backup slower than my internet speed?
Providers quote speeds in megabits while files are measured in bytes, so 200 Mbps is at most 25 megabytes per second. Protocol overhead, other traffic and provider throttling take a further share, which is what the efficiency setting accounts for.
Will a faster connection guarantee a fast restore?
No. Once the link is fast enough, the bottleneck moves to the disks, to decryption and decompression, or to limits on the provider's side. Only a timed test restore shows the throughput you will really get.
How can I meet my RTO if the cloud restore is too slow?
Keep a local copy, restore the most critical data first, raise the download speed at the recovery site, or arrange a restore by shipped drive. In the default example, 25 percent compression and deduplication savings bring the restore from about 27.8 to about 20.8 hours.