Cloud synchronisation is useful, but is it your backup?

Ask what you can recover, not what the feature is called

Synchronisation keeps selected locations aligned. A backup provides recoverable copies according to a defined policy. Some services combine synchronisation, version history, recycle bins and restoration features, so the boundary is not simply cloud versus local. The useful question is whether you can recover the required data after the failures that matter to your business, within the time you can tolerate.

Microsoft documents restoration features for OneDrive, including options that depend on the subscription and retention period. Check the current settings and terms for your exact service. Do not assume a product's use of the word backup proves indefinite history, independent protection or recovery after account compromise.

List the failure scenarios

Consider an accidental deletion, a corrupted file, a stolen laptop, a compromised administrator, a lost cloud account and a provider outage. Then identify which copy remains accessible in each case. If the same administrator can delete the source and every backup, the copies may share a serious weakness.

A second synchronised computer is convenient but may receive the same unwanted change. A local copy might also be incomplete because files are stored as online-only placeholders. Test a disconnected device if you expect it to provide an offline fallback. Do not infer that a folder icon means all its contents exist locally and can be opened without the service.

Define recovery requirements

For each important dataset, decide the acceptable loss of recent changes and acceptable time to restore. These are often called recovery point and recovery time objectives. Plain-language targets work: for example, lose no more than a working day's updates and restore essential order processing within four hours. Treat these as business requirements to test, not guarantees supplied by a subscription.

Include mail, shared files, accounting data, cloud application exports and configuration where relevant. A backup of laptops may not include a cloud-only system. Record the owner of each dataset, the source, the copy method, retention and recovery procedure. A clear inventory prevents a successful backup dashboard from hiding an unprotected application.

Calculate storage realistically

Separate current source size, growth, change rate, retained versions and additional copies. Full daily copies can require much more storage than incremental methods, but deduplication and compression depend on the actual data and software. Already compressed video and images may behave differently from office documents. Use measured backup reports when available.

As a simple illustration, 500 GB growing by 20% over a year becomes 600 GB of source data. Keeping two complete additional copies of that final dataset needs 1,200 GB before version history and overhead. That is not a prediction for an incremental backup product. Use the backup storage planner to keep the assumptions visible and then validate them against the proposed service.

Protect and test the copies

Use suitable access controls, encryption where appropriate and recovery material held by the business. Consider a copy protected from ordinary administrator deletion, using the product's supported design and specialist advice. Australian small-business cyber guidance recommends regular backup and practical recovery preparation.

Restore a sample into a separate safe location and ask the business user to open and verify it. Include an older version and a deleted item. For a database or application, a file opening is not enough; test that the application can use the restored information consistently. Record duration, missing prerequisites and whether the person performing the test needed access that would be unavailable during a real incident.

Keep a practical decision record

Ask the proposed provider to demonstrate the recovery scenario you care about using a safe sample. Request the time taken, the credentials used and any exclusions. If the demonstration relies on the original administrator account, ask how recovery works when that account is unavailable or compromised. Keep the answer in the backup plan with the owner and next test date. Product terminology changes, but this scenario-based question stays useful: which independent usable copy survives, and who can restore it under the conditions the business has actually planned for?

Next step and common mistakes

Avoid treating an emailed backup success report as proof of recoverability. Do not leave the only recovery instructions inside the account you may lose. Do not keep an external drive permanently connected and assume it is isolated from every incident. A copy needs a defined role and protection appropriate to the scenario.

Start with your three most important datasets. Write the failure scenario, required restore point, method and next test date. Then read the recovery testing guide. The goal is a recovery process that works when needed, with synchronisation used for its strengths and backup protection assessed on evidence.