There is a question almost everyone asks when ordering backups: if my server holds 200 GB and I want thirty daily copies, do I need six terabytes? The answer is no, and understanding why completely changes how you design your retention policy.
The idea, without jargon
A modern backup system does not store whole files: it splits data into small blocks, computes a fingerprint for each block, and stores only the blocks it did not already have. When a block repeats, instead of duplicating it, it points at the one that already exists.
The consequence is direct. On a typical server, only a tiny fraction of the data changes between one backup and the next: some system logs, the database, a few new files. The operating system, the libraries, the application code and most documents are identical, so they are not written again.
The real numbers
On our infrastructure, a 200 GB server with normal activity leaves around 2 to 5 GB of new blocks per daily backup. Thirty copies do not take 6 TB: they take on the order of 250 to 350 GB in total, including the full initial copy.
And there is a second effect that shows even more: deduplication works across different servers. If you run ten machines on the same Debian, the base system is stored once for all ten. In a homogeneous fleet, that multiplies the saving.
What this lets you do
Here is the practical part. Because history is cheap, you can afford long retention without the budget exploding. And long retention is exactly what saves you in the two scenarios that hurt most: the ransomware that had been inside for weeks, and the data error nobody spotted until month-end close.
With seven days of history, both cases end badly. With thirty or ninety, you have somewhere to go back to.
The honest limitations
Deduplication is not magic, and it is worth knowing when it does not help:
- Already compressed or encrypted data (video, images, zip archives) barely deduplicates, because each version is completely different at block level.
- Very active databases rewrite a lot, so their real change rate is higher than a static web server’s.
- The first backup is full and benefits from nothing. It is the only slow one.
The trade-off nobody mentions
Because blocks are shared, one corrupt block would affect every backup referencing it. That is why a serious system runs periodic integrity verification: it re-reads the stored blocks, checks the fingerprints and raises an alert if something does not add up.
If you are evaluating a backup service, ask whether it verifies store integrity and how often. That is the question separating a backup repository from a pile of files.
How we apply it
Our backup services use block-level deduplication with scheduled integrity verification. That is why we can offer long retention at reasonable prices, and why the panel shows you the new blocks per backup: it is the metric that genuinely tells you whether your data is changing and whether the system is still working.