Backup vs sync: design a recovery plan that survives mistakes

Side by side

Start with the problem you need to solve

Imagine preparing a workshop on a laptop and editing the handout later on a desktop. Sync is useful because you want the updated document to appear in both places. Now imagine discovering that you removed three important pages last week. Having the same shortened document on both computers does not restore those pages. Recovery requires an older version that still exists somewhere.

This distinction is about behavior rather than product labels. Microsoft documents both folder backup and file synchronization in OneDrive, along with separate recovery features. A service described as backup may synchronize changes while retaining versions or deleted items. Read its actual recovery rules: which data is included, which changes propagate, what history remains, and what can permanently remove that history.

Worked example: the deleted project folder

Consider a hypothetical folder containing slides, source photographs, and attendance notes. It is synchronized between two computers and a cloud account. On Tuesday, you delete the folder from the laptop while tidying the desktop. The synchronization service interprets this as an intended change and may remove the folder from the other synchronized locations.

The immediate mistake is counting the three visible locations as three independent historical copies. They may be three views of one current state. A second laptop that has been offline is not a dependable recovery plan either: once it reconnects, synchronization may apply pending changes. Do not experiment with the only surviving files.

Instead, consult the service’s documented recycle-bin or version-recovery process and identify the deletion time. Microsoft, for example, documents different OneDrive recycle-bin retention periods for personal and work or school accounts, with administrative variation. The exact entitlement matters more than a general claim that “the cloud keeps everything”.

After recovery, verify the contents before resuming normal editing. Open a slide deck, inspect a photograph, and compare the expected folder list. A restored folder name alone does not establish that all the required files or their latest useful versions are present.

Worked example: a modest document recovery plan

Suppose you create roughly two hours of new material each weekday and would find losing more than one day of work unacceptable. One possible plan is to use sync for everyday access, a daily versioned backup for recent mistakes, and an additional copy separated from the active devices. This is an example to adapt, not a claim that one schedule suits every workload.

First, list the irreplaceable material: the handout source, original photographs, project settings, and any exports that cannot be reproduced. Exclude easily downloaded installers if storage is limited. Check whether online-only files are actually included by the chosen backup software; a placeholder visible in a folder is not necessarily a local copy of the file contents.

Second, decide how far back discovery may happen. If you often revisit a project six weeks later, a seven-day history cannot cover that pattern. Choose retention that matches the plausible delay, then check the storage cost and deletion rules. A daily snapshot with a short history and a monthly archive serve different recovery needs.

Third, separate at least one recovery copy from ordinary editing access. The NCSC advises keeping an external backup device disconnected when not in use and considering both online and storage-device copies. The practical reason is independence: a connected device can be affected by the same incident as the computer.

Turn “backup complete” into a recovery check

A successful backup notification confirms a job reported success. It does not show that you know the restore procedure, retained the necessary encryption key, or included the correct folder. Schedule a small recovery exercise while the original files are healthy.

Create a disposable document containing a short unique sentence. Let the configured backup capture it, then change the sentence and let a later backup run. Restore the earlier version into a new temporary folder, leaving the working original alone. Check the text, note which snapshot you selected, and record the steps in a place accessible if the main computer fails.

For a real project, sample more than one file type. An image opening successfully does not show that a specialist project file can be used without linked assets. A whole-device recovery can require additional preparation, such as operating-system tools, account access, and compatible replacement hardware. File recovery and full-system recovery are related but separate capabilities.

• Verify the last successful backup and the folders included.
• Keep recovery instructions and needed credentials accessible through an appropriate secure method.
• Repeat a sample restore after significant changes to your devices, folders, or backup settings.

Limits that deserve a deliberate choice

Backups consume storage and bandwidth, and longer history can make recovery choices less obvious. An external drive beside a laptop shares exposure to theft or fire. A cloud copy depends on account access and the provider’s rules. Encryption protects confidentiality, but losing the required key may also prevent recovery.

A sensible design therefore names specific failures instead of promising complete protection. For accidental edits, keep useful history. For a stolen computer, keep a copy elsewhere. For account loss, consider how an independent copy can be reached. For a tight deadline, estimate how long downloading and reopening the project would take. Match the plan to these needs and review it when the work changes.

Common questions