Cloud sync is useful because it keeps working files available across devices. That same behavior can spread an unwanted change. Microsoft's OneDrive help puts it plainly: if you add, change, or delete a file or folder in your OneDrive folder, the same thing happens on the OneDrive website, and the reverse is also true. If a file is overwritten or encrypted, the changed version may sync too.

Version history can help in some cases, but recovery depends on the service settings, how long versions are retained, and which accounts can reach them. Sync keeps one current copy in several places. An independent backup keeps earlier copies somewhere your everyday accounts, and anyone who takes them over, cannot change.

How sync handles a mistake

A sync client keeps a folder on each computer matched to the copy in the cloud. When the change is a correction, that is exactly what you want. When the change is a mistake, the mistake is copied just as faithfully, to the cloud and to every connected device.

A 2012 paper on backup options, written for US-CERT and still published by CISA, describes rolling backups, which automatically update the backup files with the most recent versions of the originals. It warns that they can silently spread any corruption or malware in the originals to the backups. A synced folder behaves the same way, which is why it cannot serve as its own backup.

It helps to separate three kinds of trouble. A person deletes or overwrites the wrong thing. Malware encrypts files on one laptop, and the encrypted versions upload as ordinary edits. Or the business loses control of the account itself, through a stolen password, an administrator error, or a lapsed subscription. The first two change the files; the third changes who can reach them.

The safety nets you already have

Microsoft 365 and Google Workspace include recovery features that can handle the first two problems when someone notices quickly. Their documentation describes these windows:

  • Files deleted from a OneDrive work or school account can be restored from the recycle bin for 93 days unless an administrator changed the setting, and for 30 days on personal accounts.
  • In SharePoint, a deleted item stays in the site recycle bin for 93 days; if someone empties that bin, the item moves to the second-stage recycle bin for the rest of that time, and deleting it there purges it immediately.
  • In a work or school account, Restore OneDrive under Settings on the OneDrive website rolls the whole OneDrive back to a point within the past 30 days.
  • A SharePoint site admin can use Restore this library, under the library's Settings, to undo changes made to a shared library in the last 30 days.
  • Files in Google Drive stay in Trash for 30 days and are then deleted forever.
  • For PDFs, images and other uploaded files in Google Drive, an older version may be permanently deleted after 30 days or once there are 100 newer versions, unless someone marks it Keep forever.
  • A Google Workspace administrator can recover a user's Drive items within 25 days after the user empties the trash, but the restore brings back everything removed in a chosen date range, not individual files or folders.

When a synced file goes missing, check the recycle bin on the OneDrive or SharePoint website, not just the one on the computer. Microsoft notes that files deleted from the cloud, including files marked as online-only, don't appear in the computer's Recycle Bin or Trash.

Those windows are generous for a mistake someone spots the same week. Several of them close after 30 days, which matters for a problem nobody notices for six weeks. Version history also follows limits that administrators and site owners can set by count or age, and Microsoft notes that versions trimmed by those limits are permanently deleted, bypassing the recycle bin. According to Microsoft's OneDrive help, a file permanently deleted from the recycle bin can't be recovered.

For SharePoint, Microsoft keeps one more layer: backups of content for 14 days beyond its permanent deletion. If files were hard deleted, corrupted, or infected with malware and nothing above recovers them, an organization can ask Microsoft support for a full point-in-time restore of a site or subsite. After those 14 days, Microsoft says the data is no longer retained and can't be recovered.

Compare a deletion with a lockout

Suppose someone deletes a project folder and notices the same afternoon. The cloud service's recycle bin or version history may be enough. Now suppose the whole team loses access to the account that owns the files. Can someone still reach a recovery copy? Those are different scenarios, and a plan that works for one may fall short on the other.

Every safety net listed above lives inside the same service as the data it protects, and administrators of that service control its settings. Whoever takes over the right account can reach the safety net too. Microsoft's documentation adds that when an app or script deletes SharePoint files through the programming interfaces instead of recycling them, the files are purged immediately and can't be recovered from either recycle bin. CISA's ransomware guide notes that many ransomware variants look for reachable backups and delete or encrypt them, so that restoring is impossible unless the ransom is paid.

Account deletion is a quieter version of the same problem. By default, Microsoft keeps a deleted user's OneDrive for 30 days and gives the user's manager access if one is set, then moves it to a recycle bin for 93 days, where restoring it requires PowerShell. If access delegation is turned off, or no manager or secondary owner is set, Microsoft says no one gets automatic access.

Microsoft's clock starts when the account is deleted, not when sign-in is blocked, so block sign-in first, move the files, and only then delete the account. Google lets an administrator restore a deleted user for up to 20 days, after which the data is gone.

Ask about the copy you would restore

CISA's guidance calls for offline, encrypted backups of critical data, with regular tests of their availability and integrity. For a small business, start with the data you would need to reopen after an interruption. That might be customer records, finance files, or a website database. Identify where the recovery copy lives, who can access it, and whether a compromise of your everyday account would also affect that copy.

What makes a recovery copy independent

A recovery copy is independent when it passes these checks:

  • It keeps point-in-time copies, so a change to the live file adds a new backup version instead of replacing the old one.
  • It is stored outside the account it protects, in a separate service, a separate account, or offline media that is disconnected after each run.
  • It is managed through its own administrator sign-in, protected by multifactor authentication, and never used for email or daily work.
  • Ordinary user accounts cannot delete it, shorten its retention, or switch it off.
  • Its retention covers the longest time a problem could plausibly go unnoticed.
  • It covers every place the data lives, including laptops, any local server, the Microsoft 365 or Google Workspace tenant, and the website.
  • Someone has restored from it recently and written down the result.

The 3-2-1 rule in the US-CERT paper is still useful shorthand: keep three copies of any important file, one primary and two backups, on two different types of media, with one copy stored offsite. For a cloud-first office, the offsite copy can be a separate cloud service. CISA's guide suggests considering more than one cloud provider for cloud-to-cloud backups, in case every account with the same vendor is affected at once, and says a managed service provider that maintains your backups should follow the same practices.

CISA also notes that some cloud vendors offer immutable storage, which can protect stored data without a separate environment. It adds a caution: immutable storage does not meet the compliance criteria of certain regulations, and a misconfiguration can be costly. Before relying on a locked copy, ask how it is configured and how long each copy stays locked.

NIST's Cybersecurity Framework 2.0 lists "Backups of data are created, protected, maintained, and tested" among its protections. Its recovery section adds two steps that are easy to skip under pressure: verify the integrity of a backup before restoring from it, and afterward verify what was restored and confirm normal operation.

Decide what a recovery copy needs to do

Ask how far back you need to go and how long the team can operate without the data. NIST's glossary calls these the recovery point objective, the point in time to which data must be recovered after an outage, and the recovery time objective, how long a system can stay in recovery before the organization's mission or business processes are harmed. A copy from yesterday might be fine for a static set of forms, but too old for a shared record that changes throughout the day.

Write both answers down for each item on your list. The first tells you how often the backup must run. The second tells you how quickly a restore has to finish, which shapes where the copy lives and who must be available to start it.

Run a small restore test

A useful recovery plan tells someone which version to restore and where to restore it without overwriting live work. A first test can be small:

  • Pick one file the business depends on and note what it should contain and when it last changed.
  • Restore an older version of it from the isolated backup copy, not from the sync service's own version history.
  • Send the restored copy to a separate test folder so the live file is not overwritten.
  • Open it in the application that normally uses it and confirm it is complete and readable.
  • Record who ran the restore, which sign-in they used, which copy they chose, and how long it took.
  • Note anything that slowed the work down, such as a missing password or an unclear folder name.

Once the team can restore one file, move on to a folder or application the business depends on, such as an accounting database or the website, and document what would change if an entire service had to be restored. Then test the lockout case: could someone reach the backup and start a restore without the everyday administrator account? If the answer depends on one person's phone or password, write down a second path.

A worked example

Imagine a ten-person accounting office that keeps client folders in a SharePoint library synced to every laptop, plus a practice-management database on a small server in the back room. On a Thursday, someone opens a malicious attachment on one laptop, and files in the synced library start turning into encrypted copies. The sync client uploads each one as an ordinary edit.

If someone notices that afternoon, the laptop is disconnected and a site admin uses Restore this library to roll the library back to Thursday morning, at the cost of a few hours of work. If the encryption reaches only an archive folder that nobody opens for six weeks, the 30-day rollback window has passed, and file-by-file version history is the best remaining option, if the older versions are still there. If the attacker also held the office manager's administrator sign-in, deleted the library and emptied both recycle bins, the self-service tools have nothing left to restore. The office is left asking Microsoft support for a whole-site restore within 14 days, and the database on the back-room server was never in Microsoft 365 at all.

With an independent backup, each case has the same way out. Once the infected laptop is isolated, the office restores the library and the database from copies made before the infection, held in a backup the stolen sign-in could not reach, and checks a sample of files before people go back to work. CISA's guide recommends identifying and prioritizing critical systems for restoration on a clean network. The decision that made the recovery possible was made months earlier, when the office chose how far back its backup went and who could sign in to it.

Common mistakes to look for

  • Treating the synced folder as the backup.
  • Leaving an external backup drive connected all the time, where anything that reaches the computer can reach it.
  • Keeping the only copy of the backup's password or encryption key inside the system being backed up.
  • Restoring before the infected computer is cleaned or disconnected, where the restored files can be encrypted again.
  • Restoring straight over the live folder and overwriting work done since the backup.
  • Trusting a backup job's success message without ever restoring from it.
  • Assuming the provider's support team can bring back any file, at any age.

What to do this week

  • List the data the business would need to reopen and where each set lives today.
  • For each one, write down where its recovery copy is, how far back it goes, and which accounts can delete it.
  • Ask whoever administers Microsoft 365 whether version history limits are set to Automatic or Manual, and whether the recycle bin retention was changed from the default.
  • In the SharePoint admin center, open More features, then User profiles, then Setup My Sites, and confirm that Enable access delegation is selected and a secondary owner is named.
  • If you use Google Workspace, note the 30-day Trash and 25-day admin recovery windows, and make sure the independent backup reaches further back.
  • Give the backup system its own administrator sign-in, separate from any account that receives email.
  • Restore one file from the independent copy to a test folder and record the result.
  • Add a line to your offboarding checklist that moves a departing person's files before their account is deleted.

Where ALCO can help

ALCO's backup and disaster recovery service covers servers, laptops and desktops, Microsoft 365 and Google Workspace, with mail, OneDrive, SharePoint, Drive and shared drives backed up outside the provider. Copies are kept off the source machine, and where ransomware is the concern, one copy is locked so that no one, including someone holding your password, can change or delete it. Restores are tested on a schedule agreed for each system, timed, and written down. If a recovery cannot wait, the ALCO help desk is staffed 24 hours a day, including holidays, and calls are answered by a person.

Sources