Back up your NAS without Backblaze-sized bills — measured

Disclosure: this article contains affiliate links. If you buy through them, Rack at Home may earn a commission at no extra cost to you. We test everything we recommend. No affiliate links are present in this article today — the storage providers named here are mentioned in plain text only.

Tested on 2026-10-28, end-to-end, on our own hardware.

Everyone who searches for NAS backup advice lands in the same fistfight: "cloud backup is a rip-off" versus "local backup isn't a real backup." Both are half right, and neither side shows receipts. So we got receipts. We ran a real backup tool — restic — against a real dataset on a modest home-lab VM (4 vCPU, 7.2 GB RAM), timed every phase including a proper restore, and then priced the exact same data against the live public pricing pages of two cloud storage providers. No sponsorships, no accounts, no guesswork. Here is what the showdown actually looks like.

Why the local-versus-cloud question is the wrong question

The honest framing: you need both, and the interesting part is how cheap "both" can be. A local backup protects you from ordinary disasters — a dead drive, a fat-fingered delete, ransomware that hasn't reached the shares. An offsite copy covers the house-fire class. The fight is never whether to have the offsite copy; it's what it costs. That cost is almost entirely one thing most tutorials wave away: how much smaller your backup ends up than your raw data.

The bench: what we backed up and with what

We picked restic — open source, single binary, runs in a container, deduplicates and encrypts by default. (Borg is the other credible option; similar idea, different plumbing. We stayed with one tool so the numbers mean something.)

The dataset: 12,412 files, 1,543,464,677 bytes — about 1.44 GiB. It's built to behave like the messy middle of a real NAS: roughly 900 MB of ordinary system and document files, plus about 600 MB of exact-duplicate copies scattered through the tree, the way people actually keep "final," "final-v2," and "FINAL-really" folders. Before every timed phase we dropped the page cache, so the operating system couldn't hand us fake speed from memory.

Full backup: four seconds and a 5× surprise

The cold full backup of all 1.44 GiB took 4 seconds of wall time on this VM. But the interesting number isn't the time — it's what landed on disk. restic reported adding 525 MiB of unique content and storing 295 MiB after compression. The repository itself ended up at 310,051,784 bytes.

Do that division: 1.44 GiB in, 310 MB out — a 4.98:1 ratio. Two thirds of that reduction is deduplication catching the duplicate copies; the rest is zstd compression on top. Now, a fairness note before you paste that ratio into your planning sheet: our dataset was deliberately duplicate-heavy. Photos, videos and already-compressed media dedupe far less than documents do. On a typical home NAS we'd expect something nearer 2:1 once you account for media, and we'll use the conservative figure in the money section. But the point survives the haircut: your backup is not your data size, and the tutorials quoting "2 TB NAS = 2 TB of cloud storage" are the ones scaring you into overpaying.

During the run the container used about 150 MB of RAM and sampled at 295% CPU — roughly three of the four cores busy hashing content. On a NAS-grade CPU that translates to a noticeably slower backup, but note where the time actually went: reading the files, not the tool thinking.

The hostname trap: why your "incremental" backup keeps rescanning

Here's the pitfall worth the price of the article. We re-ran the backup with nothing changed, expecting a no-op — and the log kept printing "no parent snapshot found, will read all files." Every single run. A full rescan, every time.

The cause: restic identifies which snapshot to compare against by hostname. A fresh docker run --rm container gets a random hostname on every start, so restic never sees its own previous work. If you run restic in containers the way most guides show — bare --rm one-liners — your "incremental" nightly backup has secretly been a full backup forever. The fix is one flag: pass restic a fixed hostname with --host, or give the container a fixed name. After that, the unchanged re-run did what it should: 3 seconds, repository grew by 349 bytes.

We also checked the real increment: append 45 MB of new data to three files, run again — 3 seconds, repository grew by exactly the 45-odd MB it needed to. Incrementals are as cheap as advertised, if the parent snapshot actually matches.

Two more silent failures we hit so you don't have to

First: our very first "backup" completed in 0 seconds and moved nothing. We had forgotten to set the repository location. A tool that doesn't know where to write can technically exit without an error you happened to notice, and a 0-second backup looks identical to a fast one in a hurried terminal scroll. From then on we verified every run two ways: the repository directory actually grew, and the summary numbers moved. If a benchmark reports a suspiciously instant backup, your first question should be whether it backed anything up at all.

Second: we initially kept the test scratch data in /tmp — which on this VM is tmpfs, a RAM filesystem. Every timing measured memory speed, not disk. If your benchmark numbers look superhero-grade, check what filesystem the test data actually lives on.

The restore: the number that actually matters

A backup you've never restored is a rumor. We timed a full restore of the latest snapshot — 1.44 GiB back out to disk — with the filesystem flush inside the timer, not after it: 3 seconds, CPU sampled at 188%.

Two caveats we'll say plainly. This VM is NVMe-backed, and real NAS hard drives are much slower readers — a spinning-disk restore of the same data will take minutes, not seconds. And we deliberately didn't measure what you'd want next: a restore over the network to different hardware. The lesson from the numbers we do have: the tool's overhead is not your bottleneck. The disk is. Whatever your hardware can read, that's your restore speed — restic stays out of the way.

The cloud half: what storage actually costs in 2026

We pulled pricing from the public pages on 2026-10-28, no accounts needed. Prices change, so treat the date as part of the data.

Backblaze B2: $6.95 per TB per month (first 10 GB free), and the boring fees that used to ambush people are gone: API calls in all classes are free. Download ("egress") is free up to three times your average monthly stored volume, then $0.01 per GB — and it's unlimited and free if you pull through partner CDNs or compute (Cloudflare and friends). Their B2 Overdrive tier starts at $15/TB/month with unlimited egress, which most home NAS users won't need.

Wasabi: $7.99 per TB per month, zero egress and zero API fees, but with a floor: a minimum monthly charge tied to 1 TB of active storage. Under a terabyte you pay for a terabyte regardless. They offer a 100 GB / 30-day trial on a company email.

The math for your actual NAS

Take a 2 TB NAS — the size that triggers most people's backup panic. Assume the conservative 2:1 dedup-and-compress ratio instead of our duplicate-heavy 4.98:1: the cloud copy is about 1 TB.

• Backblaze B2: about $6.95/month, roughly $85/year.
• Wasabi: $7.99/month, $96/year — and the 1 TB minimum stops mattering at exactly this size, so it becomes competitive by accident.
• Two USB disks in a drawer: a pair of decent 2 TB drives is a one-time cost in the ballpark of a year of B2 — but with no versioning offsite, no protection against the drawer, and no fireproofing unless you buy into that too.
• A second NAS offsite: thousands, plus power, plus the same drawer problem two towns over.

At our measured bench data — 1.44 GiB, repo 310 MB — the cloud bill is effectively $0: it fits in B2's free ten gigabytes. The scary "Backblaze-sized bill" story applies to people paying to store raw data that never deduplicates. For a restic-style repo of home data, the offsite copy costs on the order of a coffee a month per terabyte.

What we did not measure

Staying honest about the gaps: no spinning-disk timings, no network restore, no multi-year cost curves, and no hands-on accounts at either provider — the cloud half is arithmetic against public prices, not a support review.

The verdict

Local first, restic-style, because it's free, instant on our bench, and the deduplication happens on your hardware where it costs nothing. Then one cloud bucket as the second copy, because the corrected number — single digits per month per terabyte, before the dedup discount most people forget to apply — is not a reason to skip it. The real traps are operational, not financial: the hostname that breaks your incrementals, the environment variable that makes a backup do nothing, the /tmp that flatters your benchmarks. Fix those, and "properly backed up" becomes a boring Tuesday. That's the whole goal.