## TL;DR
Measure the real numbers first: nightly change in gigabytes, sustained throughput of the slowest leg, and the closing work each job adds, then compare the total with the window. Stagger starts, move merges and copy jobs out of the window, raise parallelism only where the bottleneck allows, and protect the highest value systems with the earliest slots. Guessing at settings without the throughput maths just moves the queue.

```text
backup window overruns and jobs queue into production hours
```

## Use this when
- Backups finish but run into production hours and affect application performance.
- Jobs queue waiting for proxies, repository slots or tape drives and start hours late.
- Change rate grew after a new application, migration or retention change and the old schedule no longer fits.

## Not for this skill when
- One job errors out quickly. A failing job is a product error problem, not a window planning problem.
- The business can extend the window freely. Scheduling alone may solve it without technical changes.
- Restore testing is what overruns. Restore drills should be scheduled separately from production backup windows.

## Steps
1. Build the window budget from evidence: for each job record data read, change size, start and end times, and where it waited, using job history for a normal week rather than one bad night. Sum the change data that must move and compare it with the window length to find the required sustained throughput. Verify: you have a per job table and a required throughput figure in megabytes per second that the current design either meets or misses
2. Find the actual bottleneck by checking throughput and latency at each leg during a run: source disk read, proxy CPU, network link, repository write and any WAN segment. The slowest leg sets the ceiling, and adding proxies or jobs in parallel will not help a repository or link that is already saturated. Verify: one leg is identified as saturated with measurements from during the window, while the other legs show headroom
3. Remove work that does not need the window: schedule merges, synthetic fulls, backup copy jobs, health checks and catalog indexing outside the core backup hours where the product allows, and separate tape out copies to their own period. Many overruns are closing and secondary work, not the primary backup itself. Verify: the core window contains only primary backups, and the moved tasks have their own scheduled slots that do not overlap production hours
4. Stagger job starts so high change systems begin at window open and small jobs fill gaps, instead of every job starting at the same hour and queueing for the same proxies and repository slots. Set concurrency limits per repository and per proxy to match the bottleneck measurement rather than product defaults. Verify: the schedule shows staggered starts, concurrency caps match the measured bottleneck, and queue waiting time in the next run drops visibly
5. Reduce the data that must move where the maths still fails: confirm changed block tracking is healthy so incrementals are truly incremental, review exclusions for caches and temporary data that should never be backed up, and check for jobs accidentally running fulls more often than policy requires. Verify: nightly moved data falls toward the true change rate, with tracking reports and job types confirming incrementals are running as designed
6. Protect the outcome for two weeks of monitoring: chart finish times against the production start, alert when any critical job passes its slot, and review change rate growth monthly so the schedule is adjusted before it breaks again. Present the measured gap if the only remaining fix is faster repository storage or a longer window, with numbers for the business decision. Verify: finish times stay inside the window for the monitoring period and a monthly change rate review is in the operations calendar

## Why it happens
A backup window is a throughput budget. The estate changes rate grows with data and application change, while proxy, network and repository throughput stay fixed until someone upgrades them, so a schedule that fitted last year silently stops fitting. Simultaneous starts hide the problem as queueing, and closing work such as merges and copy jobs consumes window nobody budgeted. Because every individual job reports success, teams often miss that the system as a whole failed its timing requirement until production users complain. Measuring change, bottleneck and closing work turns an argument about slowness into arithmetic with clear levers.

## Variants and edge cases
Synthetic operations deserve special attention in window planning: a synthetic full reads and rewrites the whole chain on the repository, so its cost is repository throughput, not network, and it can starve primary jobs sharing that repository. Also watch month end and patch cycles, when change rate spikes predictably; a schedule with no headroom fails on exactly the nights the data matters most.

### backup window too short jobs still running in morning
The classic phrasing. Start with the window budget and bottleneck measurement, then stagger and move secondary work.

### veeam jobs queued waiting for repository slots overnight
Use when waiting, not running, dominates. Concurrency per repository and simultaneous starts are the first levers.

### backup overrun after data growth change rate doubled
The growth variant. If measured change now exceeds what the slowest leg can move in the window, the honest fix includes infrastructure or policy change, presented with the numbers.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dMLpaFcDmCLJHbQr-MsYSg