That answer contains a specific and expensive misunderstanding. Every major platform operates on what is called a shared responsibility model, and it is written into the terms of service you agreed to. The provider is responsible for keeping the service running. You are responsible for your data.

Google does not back up your Google Workspace. Salesforce does not back up your CRM. Microsoft does not back up your Microsoft 365. The platforms stay up. What is inside them is yours to protect.

Availability is not recoverability

This is the confusion in a sentence. Because you can always reach your data, it feels safe. Those are different properties.

Availability means the service is running and you can log in. Recoverability means you can get back to how things were on a particular day before something went wrong.

Cloud platforms deliver the first one exceptionally well. They do not, by default, deliver the second.

If somebody deletes the wrong folder in March and you notice in July, availability does not help you. The folder is available and it is empty.

Sync is not backup either

The second misunderstanding, and it causes more actual loss than the first.

File sync services copy changes between your devices and the cloud. That is genuinely useful and it is not protection, because sync is obedient. Delete a file and it deletes everywhere. Overwrite a document with a worse version and the worse version propagates. Get hit with ransomware that encrypts your folder and the encrypted files sync cheerfully to every device you own.

Replication copies whatever state exists, including a bad one. Backup keeps earlier states you can return to.

Most platforms offer some recovery window. Deleted email is typically retained around thirty days. Files in cloud storage often around a hundred eighty. Those windows help with the mistake you notice on Tuesday. They do nothing for the one you notice in a different quarter, and they can be cleared by somebody with access to your account.

Worth noting that Microsoft launched a separate paid backup product for its own platform in 2024. A company does not build that if its service was already a backup.

What actually needs protecting

Broader than most people assume, because the important things are rarely files.

The last one is not data, and it belongs on the list because losing control of a domain is the fastest way to lose a business identity permanently.

The rule worth knowing

Three copies of anything that matters. On two different kinds of storage. One of them somewhere else entirely.

For a small business that translates to something unremarkable. The working copy in the service you use daily. An automated backup to a separate service that keeps history. And a periodic copy somewhere disconnected, which can be an external drive you plug in monthly and put back in a drawer.

The disconnected copy is the one that survives ransomware, because anything connected when the attack runs is a candidate for encryption.

What to actually set up

In order, and none of this takes long.

  1. 01Export your customer list today, manually, and put it somewhere outside the system it came from. Ten minutes, and it covers the single most damaging loss
  2. 02Turn on whatever backup your accounting software offers, and verify where those files go
  3. 03Add a backup service for your email and cloud files. Expect somewhere around two to six dollars per user monthly
  4. 04Set your website host to take automated backups, and confirm they are stored off the server rather than on it
  5. 05Buy an external drive, copy everything critical to it once a month, and keep it somewhere other than your office
  6. 06Write down which accounts hold what, and store that list with your passwords

Step four catches people out. A backup stored on the same server as the site is not a backup. If the server fails or is compromised, both copies go together.

The test that turns a hypothesis into a backup

Pick one file you can identify from three months ago. Try to restore it. Time yourself. Most people discover one of three things: they do not know how, the backup was not actually running, or it only covers a fraction of what they assumed. A backup you have never restored from is not a backup. It is a belief about a backup, and the difference only becomes apparent on the worst possible day.

How often, and for how long

Frequency should match how much work you can afford to lose.

If losing a day of work would be survivable but annoying, daily is enough. If losing an hour of transactions would be a serious problem, you need something continuous, which most accounting and payment platforms already do.

Retention matters as much as frequency, and gets less attention. Keeping only the last seven days means an error introduced eight days ago is now in every copy you hold. Ninety days is a reasonable floor for a small business. A year is better for anything financial.

The related question

Data continuity is half the problem. The other half is access.

If the data survives but nobody can reach the accounts holding it, the outcome is identical. That is a separate piece of work and it takes about ten minutes to set up, covered here.

Both matter, and they fail independently.

Why the first of January is a reasonable day for this

Backups get postponed because nothing bad has happened yet, which is the only condition under which they can be set up.

Ransomware appears in roughly half of all investigated breaches, and small businesses are disproportionately affected because they are easier to reach and less likely to recover. But the more common cause of loss is duller than that. Somebody deletes the wrong thing. A drive fails. An account gets closed. A contractor leaves with access nobody revoked.

None of those are dramatic and all of them are survivable with an hour of preparation and unsurvivable without it.

An hour, once, this week. Then test it in March to find out whether it was real.