Every admin has said it: 'keep a month of backups, maybe two.' Then the repository fills in week three, jobs start failing, and the oldest backups — the ones someone suddenly needs — were never really there.
Retention is the rule that decides how many backups are kept before old ones are deleted, and it is the single setting where good intentions meet hard arithmetic. An image chain is not one file: it is a full backup plus every incremental that hangs off it, and deleting the full orphans the chain. This guide does the maths in the open, with example numbers, so the retention you promise the office is the retention the disk can actually hold.
An incremental backup stores only the blocks that changed since the previous backup — but it is useless without every backup before it back to the full. So storage is always counted in chains, not files. Retention in Site Manager is set in the backup definition — how many full backups (chains) to keep, and the rules for the incrementals and differentials inside them. When a chain ages out, the whole chain goes. This is why a repository can look fine for weeks and then free a huge chunk in one night: a chain expired.
If your measured numbers produce a repository you cannot afford, the honest levers are fewer chains, longer gaps between fulls, or excluding machines that do not need imaging at all — not pretending the disk is bigger.
How far back must you be able to reach? An accounts office may genuinely need last quarter's PC state for an audit query. A design studio may only need two weeks because project files live on the server too. Two practical truths help the conversation: most restore requests are for yesterday or last week — ransomware and slow corruption are the cases that reach further back, which is why one older chain kept offline beats ten recent chains kept online. Set retention per group in the console: servers longer, ordinary desktops shorter, and say the numbers out loud to whoever owns the data.
After go-live, check repository usage weekly for the first two months. Growth should flatten once the first full set of chains exists and retention starts deleting as fast as backups add. If the line still climbs, one of three things is true: a PC's change rate is bigger than your pilot suggested, retention is set looser than you think, or a machine is producing giant incrementals — a database or mail store on a desktop is the usual suspect. The dashboard's repository view plus per-computer backup sizes in the console will show you which, while there is still disk left to act.
Server install, agent push, backup definitions and schedules — the whole Macrium Site Manager deployment, live and step by step.
▶️ Watch Full VideoYou can buy a big NAS, but forever is a moving target — every chain you keep is joined by a new one each week, so storage grows without limit while the value of year-old desktop images falls to near zero. Keep history where history matters: archive one monthly image of key machines to separate storage, and let the working repository run a sane rolling retention.
When retention deletes an expired chain, that space returns to the repository. Incremental merging can take a little time, which is another reason to keep headroom. If you manually delete image files outside the console, do it through the Site Manager interface where possible — the console tracks the chains and manual file deletion can leave it describing backups that no longer exist.
A common working pattern is a weekly full with daily incrementals, keeping four to five full chains — roughly a month of restore points — for desktops, and longer for servers. Treat that as a starting point for the maths, not a recommendation: your measured image sizes and your audit needs decide the real numbers.