What a backup window is and why jobs overrun
The backup window is the period during which a backup can run without competing with production work — typically the hours between the end of the business day and the start of the next one, or a maintenance slot at a weekend. It is a scheduling constraint, not a technical one, and it is set by the business rather than by the storage.
Jobs overrun for three reasons, and they are worth separating because the fixes differ. The protected data grew, so there is more to move. The change rate rose, usually because a database or a set of virtual machine images started rewriting more blocks each day. Or the throughput fell — a busier network, a target appliance with more clients, a source now full of small files whose metadata costs more than their contents. The first two increase the numerator, the third reduces the denominator, and the calculation above separates them so you can see which one is moving.
The arithmetic itself is simple division, and that is exactly why it gets skipped. The value in doing it explicitly is that it forces two honest numbers out of you: the change rate you actually observe rather than the one you assume, and the throughput the pipeline sustains rather than the interface speed. Those two are where every estimate goes wrong. If you need the transfer time for a one-off copy rather than a recurring job, the data transfer time calculator is the more direct tool.
The formula and the four numbers it needs
Duration = data to move ÷ effective throughput. Everything else is preparing those two quantities.
Data to move is the full protected size for a full backup, and the protected size multiplied by the daily change rate for an incremental. The change rate is the input people guess at most freely and should measure most carefully: your backup software already reports the size of every incremental it has run, and dividing that by the front-end size gives the real figure. Rates vary enormously by workload — a file server of documents may change well under 1% a day, while a busy transactional database or a set of thick-provisioned virtual machines can rewrite tens of percent.
Effective throughput is the nominal rate of the binding component multiplied by the fraction you actually achieve. The binding component is whichever of source disk, network path and target appliance is slowest, and it is not always the one you expect: a 10 Gbps link is 1,250 MB/s in theory, which few backup targets can absorb, so the network is rarely the constraint on a modern LAN. The efficiency factor covers protocol overhead, per-file metadata operations, encryption, and the simple fact that a stream of millions of small files runs at a fraction of the rate a few large ones do.
Deduplication needs care about where it happens. Source-side deduplication and client compression reduce the data before it leaves the client, so they divide the transfer time as well as the storage. Target-side deduplication happens on the appliance after the data has crossed the network, so it saves storage and nothing else. Setting a reduction ratio for a target-side design produces an estimate that is optimistic by exactly that ratio, which is one of the most common ways a backup plan is wrong on paper.
Restore is the other direction and does not get the same discounts. A restore reads the full protected set, rehydrated, so the data volume is the front-end size regardless of how well it deduplicated. Restores also tend to run slower than backups on deduplicating targets, because reassembling a file from scattered unique blocks is a random-read workload rather than a sequential one. Treat the restore figure here as an optimistic bound.
Worked example: 20 TB with an 8-hour window
A mid-sized environment protects 20 TB. The backup team measures a 3% daily change rate and a backup pipeline that is nominally 300 MB/s but sustains about 80% of that. The window runs from 22:00 to 06:00.
- Convert the protected set. 20 TB × 1,000,000 = 20,000,000 MB.
- Find tonight's data. 20,000,000 × 3% = 600,000 MB, which is 600 GB.
- Find the effective rate. 300 MB/s × 80% = 240 MB/s.
- Divide. 600,000 ÷ 240 = 2,500 seconds, which is 2,500 ÷ 3,600 = 0.694 hours, about 42 minutes.
- Check the window. 8 − 0.694 = 7.31 hours spare. The nightly job has a great deal of room.
- Check a full. 20,000,000 ÷ 240 = 83,333 seconds = 23.15 hours. A full backup does not fit an 8-hour window and never will at this rate — it needs a weekend, a synthetic full assembled on the target, or a forever-incremental schedule.
- Find the minimum rate for the window. 600,000 MB ÷ (8 × 3,600 s) = 20.83 MB/s effective, which is 20.83 ÷ 0.8 = 26.04 MB/s nominal. The pipeline is more than eleven times faster than the window requires.
- Check the restore. Recovering all 20 TB at 240 MB/s takes the same 23.15 hours as a full backup. If the agreed recovery time objective is four hours, no amount of backup tuning meets it — that is a replication or snapshot problem, not a backup problem.
Step 8 is the point of the exercise. The nightly job has eleven times the headroom it needs, and the design still fails its most important requirement. Backup windows are the easy constraint; recovery time is the hard one.
How to read the result
Spare time is your growth budget. A job that finishes with fifteen minutes to spare will overrun within a year, because the protected set grows and the change rate is not constant. Treat spare time below about an hour as a job that already needs attention, and remember the margin is consumed by whichever of growth and change-rate variation moves first.
The required throughput figure tells you what to buy. If it is close to what you have, look for efficiency rather than capacity — more parallel streams, changed-block tracking instead of file scanning, or excluding data that does not need protecting. If it is several times what you have, the schedule has to change: synthetic fulls, longer incremental chains, or splitting the set across multiple nights.
A full backup that does not fit is normal, not a fault. Almost every environment above a few terabytes stopped running weekly fulls years ago. Incremental-forever with periodic synthetic fulls assembled on the target moves the cost from the window to the appliance, which is where it belongs. The number that matters is whether the incremental fits and whether the chain can be restored from.
Compare restore duration against the recovery time objective, not the window. Backup duration governs whether last night's job finished; restore duration governs how long the business is down. They are different numbers with different constraints, and it is entirely possible to have a comfortable backup window and an unacceptable recovery time. When they diverge, the fix is architectural — replication, snapshots, or instant recovery that runs a workload directly from the backup target while the real restore proceeds in the background.
Typical daily change rates by workload
| Workload | Typical daily change | Why |
|---|---|---|
| Archive and reference file shares | Well under 1% | Written once, then read; most files never change again |
| General office file server | Around 1–3% | A minority of documents are edited on any given day |
| Virtual machine images, file-level backup | High, often 10%+ | A whole image looks changed if any block inside it is |
| Virtual machine images, changed-block tracking | Much lower | Only the modified blocks are read and sent |
| Transactional database, full file backup | Very high | The data file's timestamp changes constantly |
| Transactional database, log shipping | Low per run, frequent | Only the transaction log moves, many times a day |
| Mail and collaboration platforms | Moderate | Continuous small writes across a large store |
| Encrypted or compressed archives | All or nothing | Re-encrypting a container rewrites every block |
Where a row says a rate is high, the fix is usually the backup method rather than the schedule — block-level and changed-block approaches move a fraction of what file-level backup does on the same data.
Assumptions this calculation makes
- Throughput is treated as constant. Real jobs ramp up, stall on large-file boundaries and slow when many clients start at once. The efficiency factor is a blunt instrument for all of that.
- Changed data is assumed to be moved once. Backup software that rescans a whole file when one block changes moves far more than the change rate suggests, which is exactly why virtual machine images behave so badly under file-level backup.
- Concurrency is not modelled. Ten clients sharing a 300 MB/s target do not each get 300 MB/s. Use the aggregate rate of the binding component, not the per-client rate.
- Verification, catalogue and copy jobs are excluded. Post-backup verification and copies to a second site take their own time and often share the window.
- Restore is modelled at the same rate as backup, which is optimistic. Rehydrating deduplicated data is a random-read workload and commonly runs slower than the sequential write path used to ingest it.
- Retention and target capacity are separate questions. A schedule that fits the window can still exhaust the appliance; size storage from retention and reduction ratio, not from run time.
Where the window sits among backup design decisions
The window is one of four constraints, and it is usually the least binding. The others are the recovery point objective, which sets how often backups must run; the recovery time objective, which sets how fast a restore must complete; and target capacity, which follows from retention and the reduction ratio you actually achieve. A design that satisfies the window and fails any of the other three is not a working design.
Modern schedules exist largely to keep the window small. Incremental-forever runs one full at the start and nothing but incrementals afterwards, with the target assembling synthetic fulls internally so restores stay quick. Changed-block tracking removes the scan cost entirely for virtual machines by asking the hypervisor which blocks moved. Snapshots on the primary array shift the recovery point to minutes without touching the backup window at all. Each of these changes the numerator in the calculation above rather than the denominator.
On the storage side, the reduction ratio you plan with drives everything about the target. The data compression ratio calculator converts between ratios, space savings percentages and effective capacity, which is the arithmetic behind an appliance's headline capacity claim. Watch out for the units too: appliances are sold in decimal terabytes and operating systems report binary tebibytes, a 9.95% difference that the TB to TiB storage capacity calculator makes explicit. For the network side of an offsite copy, the bandwidth-delay product calculator explains why a long-haul replication link often runs far below its rated speed until the TCP buffers are sized for it.
One habit is worth more than any of this arithmetic: test the restore. A backup job that completes inside its window every night and cannot be restored from is the most expensive kind of success, and the only way to know is to actually recover something, on a schedule, and time it.