Why an old restore point is expensive and a recent one is not
A restore point does not hold a copy of everything. It holds whatever differs between it and the copy you already have, and everything identical is shared. So the cost of a point is the cost of the blocks that are unique to it, and that grows with how far back it reaches.
Put a daily change rate of two percent into that. Yesterday and today differ by two percent, so a daily point costs two percent of a full copy. A week differs by rather less than fourteen percent, because some of what changed on Monday changed again on Thursday and only has to be stored once; the figure is about thirteen. A month differs by about forty-five percent rather than sixty. And a year differs by essentially everything: at two percent a day the chance that any given block has survived a full year untouched is negligible, so a yearly restore point costs about ninety-nine percent of a whole extra copy.
That is the shape of the whole subject. Retention cost is not linear in the number of points, it is a function of how far apart they are, and it flattens out completely once the span is long enough that everything has been rewritten at least once.
The policy people actually want versus the one they can afford
The default policy on this page keeps fourteen dailies, four weeklies, twelve monthlies and two yearlies, which is a common and reasonable shape. The fourteen dailies are the cheapest thing in it. The twelve monthlies are the most expensive tier by a wide margin, and the two yearlies cost roughly two extra full copies between them.
| Tier | Span it reaches back | Cost per point at 2% daily change |
|---|---|---|
| Daily | 1 day | About 2% of a full copy |
| Weekly | 7 days | About 13% |
| Monthly | 30 days | About 45% |
| Yearly | 365 days | About 99% |
Two useful consequences fall out. First, extending daily retention from fourteen days to sixty is almost free, and it covers the failure mode retention exists for, which is noticing weeks later that a file was quietly corrupted or deleted. Second, if the repository is short of space, the monthly tier is the place to look, not the daily one.
Change rate is the whole calculation
Halve the change rate and every tier gets cheaper, but not equally. The daily point halves exactly. The yearly point barely moves, because at one percent a day a year still rewrites essentially everything. Push the change rate low enough and the picture inverts: an archive that changes a tenth of a percent a day leaves a yearly point costing about thirty percent of a full copy rather than ninety-nine, and long retention becomes genuinely cheap.
This is why the change rate deserves a measurement rather than a guess, and the place to get it is the size of your own recent incremental runs. The backup window calculator uses the same number for the time side of the problem, so measuring it once answers both questions.
Compression, deduplication and the number they share
Both effects reduce bytes stored, and this page folds them into one ratio because they have the same consequence here. What differs is where they come from. Compression is a property of the data: documents, code, logs and virtual machine images give a lot, while photographs, video and audio give almost nothing because they are already compressed. Deduplication is a property of the fleet: it pays enormously when several machines share the same operating system and application files, and it does very little for one machine full of unique material.
A ratio quoted for a mixed environment does not transfer to a media library. If most of the protected size is video, plan near 1.0 and be pleasantly surprised rather than the other way round.
Copies, and what retention does not do
Every number here multiplies by the copy count, and it is worth being exact about what a second copy buys. Retention protects against a change you want to undo, whether that is a deletion, an accidental overwrite, a corruption you did not notice for a month, or an encryption event. Copies protect against losing the repository itself. They are unrelated protections and neither substitutes for the other: thirty restore points in one repository still sit behind a single failure, and two copies of a one-day retention still cannot get back a file you deleted last week.
If the protected data lives on a redundant array, note that the array is a third unrelated thing again, covered on the storage array capacity calculator. What an offsite copy has to satisfy to count as one is in the cloud backup guide, and if the repository is growing towards the capacity you have, the storage growth calculator works out when it lands there.
Questions people ask
Why does keeping backups for a year cost so much more than keeping them for a month?
Because a restore point only stores what is unique to it, and how much is unique depends on how far back it reaches. At a two percent daily change rate, a point from yesterday shares ninety-eight percent of its content with today and costs almost nothing. A point from a year ago shares almost nothing, because nearly every block has been rewritten at least once in that time, so it costs close to a whole extra copy. The cost curve is steep at first and then flat, which means the expensive decision is how many long-span points you keep, not how many recent ones.
How many daily restore points should I keep?
That is a question about how long a problem can go unnoticed, not a question about space, because dailies are the cheapest points in the policy. The failure retention exists for is not a drive dying, it is discovering that a file was corrupted, deleted or encrypted some time ago. If your answer to how long that could go unnoticed is three weeks, seven daily points do not help you. Extending the daily tier is usually inexpensive enough that the limiting factor is the repository, not the policy, and this page shows the marginal cost of one more point directly.
Does deduplication make retention free?
It makes the shared parts free, which is exactly what the arithmetic here already assumes. Deduplication is why a daily point costs two percent rather than a hundred. What it cannot do is share blocks that genuinely differ, so it does not change the fact that a year-old point holds a year-old version of nearly everything. It also helps far more across many similar machines than within one machine of unique files, so a ratio quoted for a fleet does not transfer to a single home server.
Should the second copy have the same retention as the first?
It does not have to, and treating them separately often saves a lot of space. A local repository that exists for fast recovery can hold a short, dense set of recent points, while an offsite copy that exists for the bad day can hold fewer points reaching further back. The calculator multiplies one policy across all copies, so to model an asymmetric arrangement, run it twice with different tier counts and add the results. What matters is being deliberate about it rather than discovering the offsite copy holds three days by accident.
Is the repository size here what my backup software will report?
Probably not exactly, and the gap is worth understanding rather than being surprised by. This models an even change rate applied to a fixed set, and real data changes unevenly and grows. Software differs in how it chains points, when it makes synthetic full copies, and how aggressively it merges old ones, all of which shift the totals. Drives are also sold in decimal terabytes and reported by most systems in binary units that are about nine percent smaller, so both figures appear above. Use this to compare policies against each other, then check against what your own repository actually reports after a full cycle.