A server with 2 TB of data on disk typically needs 300–500 GB of backup storage, even with a year of daily restore points kept. That is not a rounding trick or a marketing number. It is what falls out of two mechanisms that every modern backup engine, Duplicati included, applies before a single byte leaves the machine: block-level deduplication and compression.

If you are sizing backup storage for a fleet of machines, the intuition that "backup storage = source data × number of versions" will lead you to overbuy by a factor of ten or more. This article walks through what actually happens to your data, why keeping old versions costs almost nothing, and what that means when you pick a storage destination.

What is actually on a 2 TB server

Most of the bytes on a typical server are either duplicated or highly compressible. A file server holds the same PDF attached to five tickets, the same installer copied into three project folders, the same template saved under forty client names with a paragraph changed. A build server holds dozens of near-identical dependency trees. An application server holds log files that repeat the same hundred strings a million times.

The second thing worth noticing is how little changes day to day. On a server that stores 2 TB, a normal working day touches somewhere between a few hundred megabytes and a few gigabytes. The remaining 99% of the data is byte-for-byte identical to yesterday.

A naive backup ignores both facts. It copies 2 TB on day one and, if it keeps full copies, 2 TB again for every restore point. Thirty daily copies would be 60 TB. Nobody does that any more, but the mental model lingers and still drives storage decisions.

How block-level deduplication works

Deduplication means storing each unique piece of data exactly once, no matter how many files contain it or how many backup versions reference it. Duplicati does this at the block level, which is finer than the file level and is what makes the numbers work.

The process, step by step:

1. Split every file into fixed-size blocks. Duplicati reads each file and cuts it into blocks of a configurable size (1 MB by default in current versions). A 500 MB file becomes 500 blocks.

2. Hash every block. Each block is run through SHA-256, producing a 32-byte fingerprint. Two blocks with the same hash contain the same bytes; the odds of a collision are small enough to ignore for any practical purpose.

3. Look the hash up in the local database. Duplicati keeps a database on the client with every block hash it has already uploaded. If the hash is already there, the block is not uploaded again. Only a reference is recorded: "this file, at this offset, is block number 48,211."

4. Upload only new blocks. Blocks with hashes never seen before are the only ones that get compressed, encrypted and sent to storage. They are packed into volume files of about 50 MB each so the destination sees a small number of large uploads rather than millions of tiny ones.

5. Record the file as a list of block references. A file in the backup is not a copy of the file. It is a list of hashes. Restoring a file means fetching the blocks those hashes point to and concatenating them.

The consequence is that duplication is caught everywhere at once. The same installer in three folders is stored once. Forty variants of a template share every block except the ones that differ. And a file edited today shares every untouched block with the version backed up yesterday, so the second backup of a 500 MB file that had 2 MB appended uploads roughly 2 MB.

File-level deduplication, which some tools use, would treat each of those forty templates as a distinct file and store all forty in full. Block-level deduplication is the difference between a modest saving and a 5× one.

The local database is the key piece that makes this fast: the question "have I seen this block?" is answered on the client without any round-trip to storage. The database is also rebuildable from the backup data itself, so losing it is an inconvenience, not a data loss.

Compression: shrinking what is left

After deduplication has thrown away every block already in storage, the remaining new blocks are compressed before upload. Duplicati packs them into zip volumes using Deflate by default, with many options, including LZMA2 as an option that trades CPU time for a tighter result.

How much compression helps depends entirely on the data:

• Text, logs, source code, databases, office documents saved in older formats, uncompressed images: often 3–10× smaller. Log files in particular compress dramatically.

• Modern office formats (.docx, .xlsx, .pptx), PDFs with images, JPEG and PNG, video, audio, already-zipped archives: these are compressed internally and gain almost nothing. Duplicati recognizes common extensions and skips the compression step for them rather than wasting CPU.

• Encrypted files and disk images of encrypted volumes: incompressible by design.

Across a mixed server workload, a 1.5–2× reduction from compression is a reasonable planning figure. Combined with deduplication, that is where the 2 TB → 400 GB headline comes from: dedup takes the first and biggest bite, compression takes a second one from what remains.

Order matters here. Deduplication runs first, on raw blocks, because compression would otherwise turn identical input into output that depends on what was packed next to it and defeat the hash match. Encryption runs last, after compression, because encrypted data is random and cannot be compressed. Duplicati applies all three in that order, so enabling encryption costs you nothing in storage efficiency.

Why long retention is nearly free

Every backup version in a deduplicated store is a full restore point, but it only costs the blocks that did not exist in any earlier version. There is no distinction between "full" and "incremental" backups; every version is a complete list of block references, and the storage holds the union of all blocks any version needs.

That changes the economics of keeping history. In the old full-plus-incrementals model, each retention step meant another full copy and a chain that had to be replayed. With block-level dedup, a restore point from six months ago costs only the blocks that have since been overwritten or deleted. A server with a 1% daily change rate accumulates roughly 20 GB of new unique blocks per day before compression. A year of daily restore points, with compression, adds on the order of a few hundred gigabytes to the initial deduplicated snapshot, not 365 copies of 2 TB.

This is why a retention policy such as Duplicati's "smart retention" (keep on backup per day for a week, one per week for a month, one per month for a year, one per month after that) is close to free compared with keeping only the last seven days. The marginal cost of an old version is the handful of blocks unique to it.

It also means the usual reason for short retention, "we can't afford the storage", mostly evaporates. The remaining reasons are compliance and ransomware: both argue for keeping more history, not less. A restore point from before an attacker's dwell time started is worth far more than the few gigabytes it occupies.

A worked example: 2 TB, one year of daily backups

Take a general-purpose file and application server with 2 TB on disk, backed up nightly with smart retention. The figures below are an estimate for this kind of mixed workload; your own ratio will depend on your data.

The first backup is the expensive one, and it is already five to six times smaller than the source. A year of history adds less than a quarter on top of that, because most of each day's churn is either rewrites of blocks that already exist or log data that compresses by an order of magnitude.

Two things keep the year-end number from drifting upward. First, smart retention deletes intermediate versions as they age, and any block no remaining version references becomes garbage. Second, Duplicati's compaction step periodically rewrites volumes that are mostly garbage, so reclaimed space is actually freed at the destination rather than sitting inside half-empty files.

The workloads that break this pattern are predictable: a server full of video, a database that rewrites its whole data file nightly, or a disk image of an encrypted volume. For those, plan closer to 1× the source for the initial backup and size retention more carefully.

What this means for choosing storage

Once backup storage is a fifth of source size, the storage decision stops being about capacity and starts being about three other things.

Egress and API costs matter more than per-gigabyte price. Deduplicated backups are small, so the monthly storage line is small whatever provider you pick. What varies wildly is what a restore costs. Some object stores charge for every gigabyte downloaded and for every request; a full restore of 400 GB in 50 MB volumes is about 8,000 requests and 400 GB of egress. Check that line before the per-GB price.

Immutability beats raw capacity. Because long retention is cheap, the question is no longer "can we afford to keep it?" but "can an attacker with the server's credentials delete it?" Object lock, versioned buckets, or a destination the backup client can only append to is worth more than another terabyte.

Size the destination by backup size, not disk size. This is where the arithmetic reframes the budget. If you are provisioning Duplicati-provided storage through the Console, it is sold in 100 GB packs. The instinct is to count source terabytes and conclude that a 2 TB server needs twenty packs. It needs four or five, including a year of history, and that covers a realistic growth margin. Across an MSP fleet, the same logic applies per machine: a tenant with 10 TB of source data across its servers is typically a 2–3 TB storage commitment, not a 10 TB one.

The practical sizing rule: run the first backup, read the actual deduplicated-and-compressed size from the job report, add 20–30% for a year of retention, and buy that. The first backup is the measurement; everything after it is incremental cost.

The caveats worth knowing

Deduplication is not magic, and a few of its limits are worth understanding before you plan around it.

• Dedup is per backup job. Blocks are matched against the local database of that job, so two jobs backing up overlapping data to the same destination will store overlapping blocks twice. Group related data into one job where it makes sense.

• Fixed-size blocks and inserted data. Duplicati cuts blocks at fixed offsets. Appending to a file is cheap, and rewriting a region in place is cheap. Inserting bytes near the start of a large file shifts every block boundary after it, so that file is effectively re-uploaded. For most server data this is rare; for a few formats (some databases, some archive tools) it is routine, and those files dedup poorly between versions.

• Block size is a trade-off. Smaller blocks find more duplicates but produce more hashes and a larger local database. The default is a sensible middle; very large datasets (tens of terabytes) benefit from a larger block size, and the setting cannot be changed after the first backup without starting over.

• Compaction needs download bandwidth. Reclaiming space from mostly-garbage volumes means downloading those volumes, repacking the live blocks and uploading new ones. On a destination with expensive egress this is a cost to be aware of; the compaction thresholds are tunable.

• Already-compressed and encrypted data gains nothing. Media libraries, zipped archives and encrypted volumes will back up at close to 1× their size. Dedup still helps across versions if they rarely change.

None of this changes the headline. For the workloads most businesses actually run, backup storage lands at 15–30% of source size with a year of history included, and the right way to budget for it is to measure the first backup rather than count the disks.