Your SaaS Vendor Is Not Your Backup, and 3-2-1 Does Not Mean What You Think

The 3-2-1 rule was written for hard drives: three copies of the data, on two different media, one of them offsite. It survives translation to SaaS only if you are honest about what counts as a copy. A sync client is not a copy. A vendor's replication is not a copy. A second tab open on the same document is definitely not a copy.

Most small teams believe they are covered because the vendor is large, and the belief survives right up to the first deletion that nobody notices for thirty-one days.

Durability is not backup

A cloud provider's durability number describes the probability that a stored object disappears because hardware failed. It says nothing about the probability that the object is deleted, overwritten, encrypted, or made unreachable by an account problem — and for a small team, those are the four ways data actually goes missing.

The vendor's backup exists so the vendor can restore the service. It is not a time machine pointed at your account. It generally does not let you restore one file to how it looked on a Tuesday of your choosing, and the retention window is designed for their recovery objectives, not your regret.

Ask a different question: if this account were deleted right now, how would I get the data back, and how long would it take? If the answer involves a support ticket and an unspecified number of days, you do not have a backup. You have a hope with a status page.

The five ways small teams actually lose data

The list is short and none of it is hardware failure.

Someone deletes a folder, and the sync client faithfully deletes it everywhere within seconds, including on the laptop that had the only other copy. A shared account gets compromised and the attacker deletes or encrypts what they can reach. A billing failure suspends the workspace and read-only access arrives before anyone notices the card expired. A departing contractor's account is deactivated and the files in their personal drive go with it. Someone leaves, and the only person who knew the recovery codes leaves too.

Every one of those is an access or a deletion event. None is caught by replication, and all of them are caught by an offline copy with a retention window longer than the time it takes you to notice.

What is actually covered, per service

The email row deserves attention because it is the most common total loss and the least dramatic. Losing a mailbox does not feel like a disaster until you need a six-month-old thread for a tax question or a contract dispute.

3-2-1, translated properly

Three copies means three independent failure domains, not three folders. The working copy in the SaaS app is one. A versioned copy in a different provider is two. An offline or immutable copy that a compromised account cannot reach is three.

Two media, in practice, means not both copies behind the same login. If an attacker or a bad sync can reach both, you have one copy with extra steps.

One offsite, in modern terms, means outside the blast radius of your account: a different vendor, ideally with object lock or immutability so that nothing with your credentials can delete it for thirty days.

The part of the rule that gets dropped is the restore test, and it is the only part that distinguishes a backup from a hypothesis.

The arithmetic, which is not the obstacle

Take a small studio with 400 GB of project files, documents, and archives.

An external drive large enough to hold it twice is a one-time purchase in the low hundreds of dollars. Cold object storage at an illustrative six dollars per terabyte-month puts 400 GB under three dollars a month, and versioning multiplies that by a small factor, not by ten. Egress is the number to check before you commit, because restoring 400 GB is a download and some providers charge for it while uploads are free.

So the annual cost of doing this properly is roughly the price of a working lunch, plus a few hours of setup. Cost is almost never the reason a small team has no backup. The reason is that nobody has been given the job, and the job has no deadline.

Compare that with the alternative. A lost client folder is not measured in gigabytes; it is measured in the days of rework, the apology, and occasionally the contract. The asymmetry is large enough that the decision does not need a business case, only an afternoon.

The restore drill

Once a quarter, pick one file at random from a service you claim is backed up. Restore it. Time it. Write the time and the date somewhere a colleague can see.

If it takes more than half an hour, or the credentials are in the account you are trying to recover from, or the archive turns out to be a folder of shortcuts, the drill has done its job by failing cheaply.

Two failure modes show up almost every time. The backup runs but the credentials to restore live inside the thing being backed up — a password vault whose recovery kit was never printed, an object storage key stored only in the account that owns the bucket. And the backup exists but is not versioned, so the corrupted or encrypted file has already been copied over the good one.

The things people forget entirely

Secrets: a password manager is the right place for credentials and the wrong place for the only copy of the key to itself. Print the recovery kit, seal it, and put it somewhere that is not the office.

Email: register the domain in your own name, keep the registrar login in the vault, and export the mailbox periodically. A provider like Proton Mail with a custom domain is a reasonable choice precisely because the address is portable; the export is what makes it recoverable.

DNS and domains: a lapsed domain takes the email, the site, and every password reset with it. Put the renewal on a card that does not expire quietly, and turn on registrar lock.

Rule of thumb: if you have not restored from it in the last ninety days, you do not have a backup, you have a belief. Schedule the drill, pick the file at random, and let the failure happen on a Tuesday when nothing is on fire.