Almost every SMB I talk to thinks they have backups. Most of them have copies. Those are different things, and the difference becomes painfully clear about four hours into a ransomware incident, when someone realizes the "backup" was a sync to OneDrive that the attacker also encrypted.
If your backup strategy can be defeated by the same credential that got you popped in the first place, it is not a backup. It is a second target.
Here are five things that actually matter, in roughly the order I would do them.
1. Make at least one copy immutable
The 3-2-1 rule is fine but incomplete in 2026. The version you want is 3-2-1-1-0: three copies, two media, one offsite, one immutable, zero errors on the last restore test. Immutability is the part most SMBs skip and the part that decides whether you pay the ransom.
Concrete options that work for small companies: Wasabi or Backblaze B2 with Object Lock enabled (compliance mode, not governance), AWS S3 with Object Lock, or a Veeam Hardened Repository on a separate Linux box that your domain admins cannot SSH into. Microsoft 365 retention policies are not immutability. They are retention.
2. Encrypt with keys you control, or at least understand
For most SMBs, provider-managed encryption at rest is fine. The line you should not cross: do not let your backup decryption keys live only inside the same identity tenant the attacker just compromised. If you use Microsoft 365 backup tooling, the recovery account should be a separate, hardware-key-protected break-glass admin in a different tenant or at minimum walled off with Conditional Access. Same idea for AWS root accounts. Treat the backup admin like the nuclear football.
3. Lock down access, then audit it
The breach pattern I have seen most often is not a clever exploit. It is a sales rep's stolen credential that happened to also have access to the shared backup folder because nobody got around to cleaning up permissions after the 2023 reorg. Least privilege is unglamorous and works.
Run an access review every quarter. Anyone with delete or modify rights on backup storage should fit on one Post-it note. If you cannot list them from memory, you have too many.
4. Know which compliance regime you are actually under
This is where I see the most expensive mistakes. A law firm I know of ate a five-figure penalty under GDPR after a breach exposed unencrypted client data in a "free tier" cloud account that had been set up by an intern. The control failure was not encryption. It was nobody asking, before the bucket got created, whether the data inside it was subject to any rules.
HIPAA wants encryption in transit and at rest, plus a signed BAA with your provider (Wasabi, AWS, Microsoft, and Google all sign these for the right SKUs). PCI DSS wants segmentation and audit trails. State privacy laws are a moving target. Pick your regime, write down what it requires, and check your backup setup against that list, not against a generic "best practices" blog post.
5. Test restores on a calendar, not a vibe
This is the one almost everyone fails. A backup that has never been restored is Schrodinger's backup: simultaneously working and broken until you open the box, usually during an actual incident.
Quarterly minimum. Restore a real file, a real mailbox, and a real VM (or container, or whatever your stack is) from cold storage to a clean environment. Time it. Document the runbook. The first time someone runs through your restore procedure should not be at 3 a.m. on the worst day of the year.
If you want a second set of eyes on your backup posture before something goes wrong, Syncritech does a paid one-week assessment that ends with an actual restore test, not a PDF.
