Backup strategy

The Developer's 3-2-1 Backup Guide (2026)

Three copies, two media, one offsite — plus the restore drills and cost math that most guides skip.

By BackupForDevs · Updated November 7, 2026 · 15 min read

Most developers do not lose data because they never heard of backups. They lose it because the backup was on the same ransomware-reachable network, the sync client propagated the deletion, or nobody had ever restored the archive.

The 3-2-1 rule is a simple defense against those failures: three copies of the data, on two different media, with one copy offsite. This guide turns that slogan into a setup you can actually run as a developer or a small team.

1. What 3-2-1 actually means

“Three copies” means the original plus two backups. “Two media” means they should not all live on the same disk, array, or cloud account. “One offsite” means at least one copy survives fire, theft, a flood, or a compromised account at the primary location.

A useful extension is 3-2-1-1-0: three copies, two media, one offsite, one offline or immutable, and zero errors verified by restore tests. The last two are what separate a real backup plan from a folder of unverified archives.

Sync, snapshot, and RAID are not backups

• Sync mirrors changes to every device. If you delete a file or a ransomware process encrypts it, sync may copy the damage before you can stop it. Version history can help, but only if it is enabled and you can restore it.
• Snapshots are point-in-time views on the same storage system. They are excellent for accidental changes, but they usually live with the original and may be deleted with the same credentials.
• RAID is redundancy against disk failure. It is not a copy, not offsite, and not protection against deletion or encryption. RAID 1 is not “two backups”.

2. What developers need to protect

Not all data deserves the same treatment. Start with an inventory, then classify it as critical, important, or archive.

Start with the data you cannot recreate. A media archive can tolerate a slower cold copy; a production database, signing keys, and uncommitted work cannot.

3. Copy 1: local

The local copy is for speed. It is the copy you reach for when a file was deleted an hour ago or when you need to rebuild a machine without downloading terabytes.

Options

• External drive: cheapest and simplest. Keep it disconnected when not in use, because ransomware can encrypt any drive that is mounted.
• NAS: convenient for multiple machines and larger datasets. Use snapshots and a separate backup target; do not rely on RAID alone.
• Second machine: a desktop or home server with enough disk. Useful for fast restores, but it is not offsite.

Practical setup

• Use restic or Borg to write an encrypted, versioned repository to the local drive or NAS.
• Schedule it daily for code and databases; weekly for large media.
• Keep at least one local copy physically disconnected or read-only when you are not backing up.
• Do not give the backup job the same credentials as your production systems.

4. Copy 2: offsite

The offsite copy is the one that survives a lost laptop, a fire, a stolen NAS, or a ransomware event that reaches your local network. There are two broad options: raw object storage and managed backup services.

Object storage

Object storage gives you a bucket and an API. It is cheap per gigabyte and works with restic, rclone, Borg, and many backup applications. It is not a backup product by itself: you still need versioning, encryption, retention, and a restore process.

Managed backup services

Managed services bundle the client, scheduling, versioning, and support. They are easier to operate, but you trade control and sometimes pay per device or seat.

How to choose: if you want full control and already use restic or rclone, object storage is usually the cheapest and most flexible. If you want a client, scheduling, and support in one place, choose a managed service. Many small teams end up with both: managed backup for laptops and object storage for servers and NAS.

5. Copy 3: cold and immutable

The third copy exists for the scenarios where an attacker or a mistake can reach your live systems. Ransomware is the common example, but an accidental rm -rf, a bad migration, or a compromised admin account can do the same damage.

Options

• Object lock / WORM: some object storage providers support retention rules that prevent deletion or modification for a fixed period. Check the provider’s current capabilities and configure the lock before you need it.
• Offline drive: a rotating external drive kept disconnected and stored separately. Simple, cheap, and effective against network attacks.
• Tape: LTO tape is still a practical cold archive for very large datasets and long retention. It has a higher operational overhead and is overkill for most small teams.

Practical rules

• Use a separate account, credentials, and retention policy for the cold copy.
• If the backup credentials can delete the cold copy, it is not immutable.
• Keep at least one copy offline or in a different trust domain.
• Test restoring from the cold copy at least quarterly; slow restores are expected, surprises are not.

6. The tool stack

You do not need a complex platform. A small set of well-understood tools covers most developer workloads.

A minimal restic example

restic can write directly to Backblaze B2. The exact syntax depends on your version; this is the shape of the workflow:

export B2_ACCOUNT_ID="your-key-id"
export B2_ACCOUNT_KEY="your-application-key"

restic -r b2:bucket-name:backups init
restic -r b2:bucket-name:backups backup /path/to/data
restic -r b2:bucket-name:backups restore latest --target /restore

Store the repository password somewhere separate from the bucket. A backup you cannot decrypt is not a backup.

A minimal PostgreSQL example

pg_dump -Fc mydb > mydb.dump
# Encrypt and upload with restic, rclone, or your backup tool of choice.
# Restore into a new database and verify row counts before trusting it:
pg_restore -d mydb_restore mydb.dump

For critical systems, add WAL archiving for point-in-time recovery. For most small projects, a daily logical dump plus a verified restore is already a large improvement.

7. What it costs

Backup pricing is simple in principle: stored data × storage rate, plus egress, plus minimum commitments. The useful number is the total cost over a year, not the headline per-gigabyte rate.

Estimates exclude taxes, request charges, minimums, and any retrieval fees. B2 assumes egress stays within the 3× stored allowance. Verify current prices before committing.

For managed backup, Backblaze Computer Backup is roughly $99 per computer per year. IDrive, Proton Drive, and Tresorit use plan-based pricing that depends on seats and storage, so compare the plan that covers your devices rather than the lowest advertised tier.

Budget for versioning and growth

If your source data is 1 TB and you keep 20% overhead for versions and retention, budget for roughly 1.2 TB. If the data grows 20% per year, the second-year bill is based on a larger footprint. A backup plan that ignores growth looks cheap in month one and expensive in year three.

Hidden costs

• Egress: restores and frequent test downloads can cost more than storage.
• Minimums: some providers bill a minimum capacity or a minimum storage duration.
• Operations: monitoring, failed jobs, key rotation, and restore drills take time.
• Taxes and payment fees: especially for international publishers and small teams.

8. Restore drills

A backup job that reports success only proves that bytes were written. It does not prove that you can decrypt the archive, find the right version, or restore it to a working system.

A practical drill

1. Pick a file you did not create today.
2. Restore it to a temporary directory, not over the original.
3. Compare a checksum or open the file and verify the contents.
4. Record how long the restore took and what you had to look up.
5. Once a quarter, restore a database to a new instance and run a query against it.
6. Store the recovery steps somewhere you can reach without the primary system.

9. A 30-minute checklist for a small team

• List the data you cannot recreate: code, databases, secrets, configs, customer files.
• Classify each item as critical, important, or archive.
• Choose one local copy, one offsite copy, and one cold or immutable copy.
• Enable client-side encryption before data leaves your machine.
• Use separate credentials for backups and production.
• Schedule daily backups for code and databases; weekly for large media.
• Turn on job monitoring so a failed backup is visible.
• Run a single-file restore this week.
• Schedule a quarterly full restore drill.
• Document the recovery steps and store them offline.
• Review retention and costs every quarter.

10. Common mistakes

• Treating RAID as a backup. Redundancy is not recovery.
• Treating sync as a backup. Deletions and encryption propagate.
• Using the same credentials everywhere. One compromised admin account can delete every copy.
• Keeping every copy online and reachable. Ransomware can find and encrypt them.
• Never testing a restore. The most common failure is discovering the archive is unusable when you need it.
• Backing up secrets unencrypted. A backup can become a credential leak.
• No monitoring. A backup that silently stopped three weeks ago is not a backup.
• Retention too short. If the problem is discovered after the retention window, the backup is gone.
• Ignoring SaaS data. Issues, docs, and tickets also need an export path.
• Backing up data but not configuration. A restored database without its environment is only half a recovery.

11. FAQ

Is the 3-2-1 rule still relevant in 2026?

Yes. The media and providers have changed, but the principle has not: keep multiple copies, on different systems, with at least one outside your primary location. Cloud storage makes the offsite copy easier; it does not remove the need for it.

Do I need three copies of everything?

No. Apply 3-2-1 to data you cannot recreate. A large media archive can use a slower cold copy; critical code, databases, and secrets deserve the full treatment. The point is to make the decision deliberately, not to apply the same policy to every byte.

Is RAID a backup?

No. RAID protects against some disk failures. It does not protect against accidental deletion, ransomware, fire, theft, or a corrupted filesystem. Keep an independent copy.

Is cloud sync a backup?

Usually not. Sync mirrors changes, including deletions. Unless the service keeps version history and you have tested restoring an older version, do not count it as a backup.

How much does a 3-2-1 setup cost?

For object storage, list prices in late 2026 are roughly $0.006/GB/month for Backblaze B2, $0.015/GB/month for Cloudflare R2, and $0.023/GB/month for AWS S3, plus egress where applicable. Managed backup plans are priced per device or seat. The scenarios above give a starting point.

What about ransomware?

Assume the attacker can reach every drive and account your normal user can reach. Keep at least one copy offline or under an object-lock retention rule, use separate credentials, and test that the retention rule actually blocks deletion.

Do I need tape?

For very large archives and long retention, LTO tape can be cost-effective. For most developers and small teams, a cloud copy plus an offline drive is enough. Tape adds operational overhead and slower restores.

How often should I back up?

Base it on your RPO: how much data can you afford to lose? Daily is a reasonable default for code and databases; hourly if the database is critical. Large media can be weekly.

Can I use Backblaze B2 with restic?

Yes. B2 is S3-compatible and restic has a native B2 backend. You need a bucket, an application key, and the repository password stored separately.

Is Backblaze Computer Backup enough for a server or NAS?

No. Computer Backup is designed for personal computers. Servers and NAS systems need a server-grade tool and a storage target, such as restic or Borg writing to object storage.

Do affiliate links affect your recommendations?

No. We include non-affiliate options where relevant, and commissions do not determine rankings. See the affiliate disclosure.

Start small, then make it boring

The best backup setup is the one that runs without you and that you have actually restored from. Start with one local copy, one offsite copy, and one immutable or offline copy. Automate the schedule, monitor the jobs, and put a restore drill on the calendar.

If you are building this for a small team, the order matters: inventory the data, assign an owner, choose the copies, then write down the recovery steps. The tools are replaceable; the discipline is not.