Here is a conversation we have had more times than we can count. A client calls because a folder is gone. Not corrupted, not locked. Gone. Somebody deleted it three months ago during a cleanup and nobody noticed until the auditor asked. The client says, with total confidence, “that is fine, it is in the cloud.” Then we explain that the cloud is not a backup. It is a place where your data lives, which is a different thing entirely.

This is not a knock on Microsoft or Google. Both run infrastructure far more reliable than anything a small business could build, and their servers do not lose your files. The trouble is that most data loss has nothing to do with servers. It comes from a person, a script, or an attacker doing something perfectly valid: deleting. A provider whose job is to execute your instructions faithfully will execute that one too.

The Gap Almost Everyone Misses

Cloud providers work on what the industry calls shared responsibility. They handle infrastructure: power, hardware, redundancy, keeping the lights on. You handle what happens inside your tenant, meaning who has access, what they do, and whether the data they touch still exists tomorrow.

Think of a self storage facility. The company keeps the roof from leaking, runs the cameras, and stops the building from burning down. If you throw out the contents of your own unit, they will not have a copy. The provider protects the building. Nobody is protecting you from you.

These are the failure modes a provider’s redundancy does not cover.

  • Ordinary human deletion. Somebody cleans up a shared drive or removes a project folder they were sure nobody needed. This is the most common cause of real data loss and it never makes the news.
  • Departing employee cleanup. An account gets deleted during offboarding and the files that lived only in that person’s drive go with it. Quiet and fast.
  • A compromised account. An attacker signed in as a legitimate user can delete mail, wipe files, and empty the recycle bin. Every action looks authorized because technically it is.
  • A bad sync. Sync tools are obedient. If files disappear on one end, the tool dutifully removes them everywhere else. Ransomware on one laptop reaches your cloud storage this way.
  • A third party app with too much access. An integration you connected two years ago and forgot about can misbehave in bulk, using permissions you granted it.

What Cloud-to-Cloud Backup Actually Means

Strip the jargon and it is simple. A separate service, run by a separate company, connects to your Microsoft 365 or Google Workspace tenant, copies your data on a schedule, and stores that copy somewhere your tenant does not control. When something disappears from the original, the copy is unaffected, because it does not take orders from your tenant.

The important word is separate. Not a second folder. Not a longer recycle bin. Not a retention policy inside the same system. A genuinely different place, with different credentials and its own clock. That separation is the entire product.

And to be blunt about what it is not: this does not protect you from an outage. If Microsoft 365 is down, your backup does not make email work again. We have written separately about what a cloud outage means for a small business, because that is a different problem. Backup is about data existing, not about services being reachable.

What to Back Up, and in What Order

You do not have to solve everything at once. Work in the order that matches how much the loss would hurt.

  1. Email first. Mailboxes hold the record of what was agreed, when, and by whom. Contracts, approvals, quotes, the informal history of your business. Losing one is losing institutional memory, and it cannot be reconstructed.
  2. Files second. Shared drives, team sites, personal cloud storage. Where deletion accidents happen most, and where a bad sync does its damage.
  3. Then the systems holding records you cannot rebuild. Your CRM, accounting platform, practice management or job costing system. If it holds customer history, transaction records, or anything a regulator might ask about, it belongs here. Most have their own export options and most businesses have never turned them on.
  4. Chat last, but not never. Team chat quietly became where decisions get made. It never feels urgent until somebody needs to prove what was said.

The test we use is simple. For each system, ask whether you could recreate it tonight from something else you already have. If yes, lower priority. If no, it needs a backup.

Retention Windows Are Shorter Than You Think

This is where the surprise lives. People assume the built in safety nets are generous. They are not, and the numbers are published in plain sight.

Microsoft’s service assurance documentation states that when a user or administrator deletes data during an active subscription, Microsoft retains that customer content for at most 30 days, and that once the maximum retention period elapses the data is rendered commercially unrecoverable. The same documentation says that if a paid subscription is terminated, Microsoft keeps customer data in a limited function account for 90 days so the subscriber can extract it, and deletes all of it no more than 180 days after termination.

Google’s Workspace admin documentation is similarly direct: an administrator has up to 20 days after a user is deleted to restore that account and its data, and if files were not transferred at the time of deletion, the user’s files are deleted 20 days later.

Read those windows against how businesses actually discover problems. A quarterly review. A tax filing. An audit request. A customer asking about a job from last spring. A month is not long to notice something missing. Twenty days is shorter still. The CISA, MS-ISAC, NSA and FBI joint #StopRansomware Guide published in 2023 lists cloud-to-cloud backup among the options organizations should consider.

A Backup You Have Not Restored Is a Rumor

That same 2023 #StopRansomware Guide from CISA, the MS-ISAC, the NSA and the FBI recommends organizations “regularly test the availability and integrity of backups in a disaster recovery scenario.” That advice exists because untested backups fail, and they fail at the exact moment you need them.

  • Restore something real, not a test file. Pull back an actual mailbox folder or a project directory from last quarter. A one kilobyte file proves nothing.
  • Open what comes back. A restore that returns files you cannot open is not a restore. Check that documents render and attachments are intact.
  • Time it. Write down how long the restore took. That number is your real recovery expectation, and it is usually longer than anyone guessed.
  • Verify the coverage list. New employees, drives, and sites do not always get picked up automatically. Confirm what is actually protected.
  • Do it on a schedule. Twice a year, on the calendar, treated like a fire drill. If it is not scheduled it does not happen.

The Bottom Line

Your cloud provider protects their infrastructure and they are good at it. They do not protect your data from you, from a compromised account, or from a sync that faithfully copies a mistake everywhere. The built in recovery windows are real but short, measured in weeks rather than years. A separate backup service closes that gap for a cost that is a rounding error next to reconstructing one lost mailbox.

Start with email and files, add your record keeping systems next, then prove it works by restoring something real. If you inherited a setup nobody has verified in a couple of years, we can look at it and give you a straight answer. We work with small and mid-sized businesses across Denton County, and this is one of the cheapest problems to fix before it becomes an expensive one. Contact us today


Sources:

Comments are closed

This website uses cookies and asks your personal data to enhance your browsing experience. We are committed to protecting your privacy and ensuring your data is handled in compliance with the General Data Protection Regulation (GDPR).