Cloud Backup Strategy: A Comprehensive Guide

A working cloud backup strategy follows the 3-2-1 rule: three copies of your data, on two different media types, with one copy off-site — in practice that means a primary (production storage), a local backup (NAS or external drive), and at least one cloud tier (Backblaze B2, AWS S3 Glacier Deep Archive, or Wasabi). Add immutability via object lock, encrypt client-side with AES-256 before upload, automate nightly via restic or Borg, and — this is the step most teams skip — test a full restore every quarter. Without a tested restore, you have hope, not a backup.

Why 3-2-1 Still Holds Up in 2026

3-2-1 dates back to film photography, but the math hasn't changed. Three copies give you enough redundancy that any single failure (drive crash, ransomware, accidental rm -rf) leaves two copies intact. Two media types hedge against systematic failure — a bad firmware version bricking a whole SSD model, or a cloud provider region outage. Off-site protects against the building-level event: fire, flood, theft, or the moving truck hitting your rack.

Modernized variants exist. 3-2-1-1-0 adds an immutable copy and requires zero errors in restore tests. 4-3-2 (used by many MSPs) keeps four copies and two cloud vendors. Pick one, document it, and stick to it. The specific number matters less than the discipline.

Picking Storage Tiers for Cost vs. Recovery Speed

Cloud providers offer storage classes at dramatically different price points:

| Tier | Cost per GB/month | First-byte latency | Egress fee | |------|-------------------|---------------------|-------------| | S3 Standard | $0.023 | milliseconds | $0.09/GB | | S3 Glacier Instant | $0.004 | milliseconds | $0.03/GB | | S3 Glacier Flexible | $0.0036 | 3-5 minutes | $0.02/GB | | S3 Glacier Deep Archive | $0.00099 | 12 hours | $0.02/GB | | Backblaze B2 | $0.006 | milliseconds | $0.01/GB | | Wasabi | $0.0069 | milliseconds | free (up to 1x stored/month) | | Cloudflare R2 | $0.015 | milliseconds | free |

For backup specifically, Glacier Deep Archive hits roughly $1 per TB per month, but restore latency means you can't use it for "oh no I deleted yesterday's file." A two-tier approach works best: recent backups in a hot tier (B2 or R2), older than 30 days lifecycled to Glacier Deep Archive.

The 3-2-1 Rule in Concrete Terms

A sample stack for a 2 TB working set:

Production: laptops, servers, SaaS data (primary copy)
Local: NAS running ZFS with snapshots, 4 TB usable, weekly mirrored to an external USB drive that lives in a fireproof safe
Cloud hot: Backblaze B2 bucket with restic, nightly incremental, 90-day retention at ~$12/month for 2 TB
Cloud cold: S3 Glacier Deep Archive via lifecycle policy, annual snapshots, 7-year retention at ~$24/year for 2 TB

Total monthly cost: under $20 for full 3-2-1 coverage with a seven-year history. That's cheaper than a single replacement laptop.

Automating Backups With Tools That Won't Bite You

Restic is the de facto choice for encrypted incremental backups to object storage. It deduplicates, compresses, encrypts with AES-256-CTR plus Poly1305, and supports B2, S3, Azure, GCS, and SFTP natively:

restic -r b2:hexa-backups:production init
restic -r b2:hexa-backups:production backup /var/data \
  --exclude-file=/etc/restic/exclude.txt \
  --tag nightly
restic -r b2:hexa-backups:production forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Run it nightly via systemd timer or cron, with the repository password in a file readable only by root. Borg Backup is an excellent alternative, particularly if you need local repository support; Kopia is newer and has a friendlier UI if you want one.

For Windows workstations, Duplicati or the built-in Windows File History plus a cloud target covers the basics. For Macs, Time Machine to a local NAS plus Arq Backup to Backblaze B2 is a battle-tested combo.

Making Backups Immutable Against Ransomware

Ransomware that encrypts your production data will try to encrypt your backups too. Object lock prevents that. Both AWS S3 and Backblaze B2 support "compliance mode" where even the root account can't delete objects until the retention period expires:

aws s3api put-object-lock-configuration \
  --bucket backup-immutable \
  --object-lock-configuration '{
    "ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}
  }'

For 30 days after upload, nobody — including a compromised admin — can delete the backup. Combine this with versioning, MFA-delete, and an IAM role that can write but not overwrite, and you've closed the dominant ransomware path.

Encrypting Client-Side Before Upload

Even with provider-side encryption (SSE-KMS), your cloud vendor holds the keys, which means subpoena requests can compel decryption. For sensitive data, encrypt before the bytes leave your network. Restic does this automatically; for ad-hoc files, age is a good fit:

age -r age1xyz... -o archive.tar.gz.age archive.tar.gz
aws s3 cp archive.tar.gz.age s3://backups/

Store the age private key in 1Password or a hardware security key like YubiKey. Back up the key itself on paper, encrypted with a passphrase, in a safe deposit box. A lost encryption key is as catastrophic as lost data.

Recovery Testing Is the Backup

Every quarter, pick a random file or server and restore it end-to-end to a clean environment. Measure:

RTO (recovery time objective): from decision to restored
RPO (recovery point objective): how much data was lost (hours, days)
Integrity: do the restored bytes match the original hash?

A real example: a team running nightly backups to S3 Glacier Deep Archive discovered during their first restore test that provisioning the restore permissions plus waiting for the 12-hour retrieval made RTO 18 hours when their business needed 4. They moved active retention to Glacier Flexible (3-5 minute retrieval) and kept Deep Archive only for compliance history. That test saved them from learning the lesson during an actual incident.

Document the runbook as you go: commands, credentials, decryption passphrases, who can authorize a restore. Test it on a fresh laptop so you know the runbook works without your local environment.

Regulatory Retention Requirements

Many frameworks specify minimum retention:

GDPR: no fixed number; retain only as long as necessary for stated purposes
HIPAA: 6 years for audit logs and policies
SOX: 7 years for financial records
PCI DSS 4.0: 1 year for audit trails, 3 months "immediately available"
FINRA 17a-4: 3-6 years, WORM-compliant storage required

Tag backups with retention metadata and enforce via lifecycle policies so you neither keep data longer than needed (a GDPR problem) nor shorter than required (a SOX problem).

Monitoring and Alerting

Backups that silently fail are worse than no backups. Every restic or Borg job should emit metrics: duration, bytes transferred, files changed, success/failure. Ship to Prometheus, Datadog, or a plain cron log monitored by a Dead Man's Snitch-style tool that alerts when the expected heartbeat doesn't arrive. The failure mode you're trying to catch is "backups have been broken for 90 days and nobody noticed."

Alert on: job failure, job skipped, repository corruption (restic check), unusual size change (data loss or unexpected growth), and failed restore test.

HexaTransfer is not a backup tool — it's for one-shot encrypted transfers — but the same end-to-end encryption principles apply when you're sending a backup archive to a colleague. Try it at hexatransfer.com — free, no account, 10 GB max.

From Strategy to Discipline

A cloud backup strategy lives or dies on discipline more than architecture. Nightly runs, quarterly restore tests, annual runbook reviews, immutable retention, and client-side encryption are not glamorous, but they're the difference between "we had a backup" and "we had a recovery." Write down what you do, automate what you can, test what you can't automate, and keep the total monthly cost low enough that nobody in finance ever asks you to scale it back. Cheap plus boring beats expensive plus clever every time.