Skip to content
Infrastructure · 4 min read

Restic to object storage is a real backup strategy

The claim A small business does not need a backup appliance, a vendor contract, or a six-figure disaster-recovery product to protect its data properly. A single open-source tool wr...

A Written by Administrator
Restic to object storage is a real backup strategy

The claim

A small business does not need a backup appliance, a vendor contract, or a six-figure disaster-recovery product to protect its data properly. A single open-source tool writing encrypted, deduplicated, verifiable snapshots to inexpensive object storage covers the requirement completely, for a few dollars a month, and it does the one thing that separates a backup from a folder of files: it can prove the backup is intact without restoring it.

What a real backup tool must do

The bar is not "copies the files somewhere". A backup you can rely on has four properties, and a plain rsync to a second disk has one of them:

  • Encrypted before it leaves the host, so the storage provider — and anyone who breaches them — holds only ciphertext.
  • Deduplicated and incremental, so a daily snapshot of a 40 GB dataset costs the space of what changed, not 40 GB, and you can keep months of history cheaply.
  • Point-in-time, so you can restore to last Tuesday, not just to the latest copy — which matters enormously when the thing you are recovering from is corruption or ransomware that your latest copy has faithfully replicated.
  • Verifiable, so you can check the backup is readable and consistent on a schedule, without a full restore.

The whole setup

export RESTIC_REPOSITORY=s3:https://s3.ca-central-1.example.com/acme-backups
export RESTIC_PASSWORD_FILE=/etc/restic/passphrase

restic init          # once

# nightly:
restic backup /srv/app/data /etc --tag nightly
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

That forget line is the retention policy in one command: fourteen daily snapshots, eight weekly, twelve monthly, and everything older removed and its space reclaimed. The deduplication means those thirty-four retained snapshots of a slowly-changing dataset occupy a small multiple of one full copy, not thirty-four times it.

The verification that makes it a strategy rather than a hope

This is the step that separates restic from a cron job full of good intentions:

# cheap, run nightly: structural integrity of the repository
restic check

# thorough, run weekly: actually read and verify a sample of the data
restic check --read-data-subset=5%

check verifies that the repository's internal structure is consistent. --read-data-subset goes further and actually downloads and re-hashes a percentage of the real data, catching silent corruption in the storage backend that a structural check would miss. A weekly 5% subset reads the entire dataset over about five months without ever paying for a full verification at once.

The rule that defeats ransomware

A backup that the compromised host can delete is not a backup against ransomware, because modern ransomware specifically hunts for and encrypts backups first. The defence is append-only credentials: the key your server uses can write new snapshots and read them, but cannot delete anything. Deletion — the forget --prune step — runs from a separate context with separate credentials, or you use the object store's own retention lock so that objects are immutable for a defined window regardless of what any key requests.

# server's key: PutObject, GetObject, ListBucket   (no DeleteObject)
# object-lock: retain 30 days, governance or compliance mode

With this in place, an attacker who fully owns your server can encrypt your live data but cannot touch the thirty days of history sitting in the bucket, which is exactly the position you want to be in.

The 3-2-1 rule, satisfied honestly

The old guidance — three copies, two media, one off-site — is satisfied by this setup: the live data, a local restic repository for fast restores, and the object-storage repository off-site. Keep the local copy for the common case, which is restoring a file someone deleted this morning, and rely on the remote copy for the rare case, which is losing the whole host. Restoring 40 GB from local disk is minutes; from object storage it is bounded by your download bandwidth, which is worth measuring before you need it.

What this costs

Object storage in a Canadian region runs on the order of a few cents per gigabyte per month, so a 40 GB dataset with several months of deduplicated history is a few dollars monthly, plus egress charges you only pay during an actual restore. Against a managed backup product's per-server monthly fee, the open-source path is dramatically cheaper — and because you can read exactly how it works, verify it yourself, and restore without a vendor, it is also more trustworthy on the day it matters. The cost is that you own the setup. For most small businesses, an afternoon of setup against a real recovery capability is the best trade on this list.

#backups #restic #object storage #ransomware

Keep reading