Data Recovery · October 25, 2026 · ComputerKing Team
Backup Restored — But the Wrong Version
Sync only copies the latest state, and old versions can be pushed out or expire; knowing each service's retention period and planning questions prevents restoring the wrong version.
Key Summary
Sync only copies the latest state, and old versions can be pushed out or expire; knowing each service's retention period and planning questions prevents restoring the wrong version.
The 3-2-1 basics, restore testing, immutable backups, mobile backup traps, NAS security and key management each have their own practices; how versions disappear is a separate question to understand on its own.
Sync Is Not Backup
A sync service is designed so every device sees the same latest state. Delete a file by mistake, overwrite a document, or encrypt a batch of files, and the sync program treats that latest state as the correct state and copies it to the cloud and to other devices. That is not a program error; it is sync working as designed.
Three things must stay separate:
- A file in the cloud only means the latest version is in the cloud.
- An old version in the cloud only means the pre-mistake version is still there.
- An independent backup only means that even if the cloud account fails or versions are cleared, another copy unaffected by sync still exists.
How Each Service Spreads One Bad Change
OneDrive: When a file is deleted, overwritten or damaged, Microsoft states it may be recoverable within 30 days, provided the file was once in OneDrive, the change or deletion is no more than 30 days old, and the recycle bin has not been emptied for permanent deletion. Version history covers many file types, including Microsoft 365 files, PDFs, photos and videos, and only one file can be restored at a time.
Google Drive: When files are synced or mirrored with Drive for Desktop, a file deleted in the computer trash syncs everywhere; it only syncs back to the computer after being restored from the online Drive trash. Note the difference: photos and videos backed up in Google Photos behave differently from Drive for Desktop synced files, and deleting on a computer does not sync-delete the Google Photos copy.
iCloud Drive: Apple states that deleting an iCloud Drive file on iCloud.com deletes it on every device with iCloud Drive turned on. After deletion, the file goes to Recently Deleted and is removed after 30 days.
Dropbox: Dropbox offers a Deleted files page and Rewind, but Rewind restores a whole account or folder to a point in time and undoes every change after that point. Back up recent files first, or restoring an old version can wipe out newer work.
Hypothetical scenario: a user overwrites a quotation on a home computer, saves it, and only notices the wrong figures later. Because sync has already sent the wrong version to the cloud and to a laptop, both copies open as the wrong version. The problem is not a failed backup; sync was never a tool for keeping old versions.
Retention Figures for Each Cloud Service
| Service and item | Retention | Key point |
|---|---|---|
| OneDrive personal: recycle bin | 30 days | Counted from deletion; emptying means permanent deletion |
| OneDrive personal: whole-drive restore (Microsoft 365 subscribers) | Changes and deletions within the past 30 days | Can only go back to a point within 30 days |
| OneDrive work/school and SharePoint: recycle bin, two stages combined | Generally 93 days, counted from the original deletion date | Moving to the second stage does not reset the clock; an admin can shorten it |
| SharePoint new libraries, manual mode default | 500 major versions, no expiry date | A version-count model, not a day-count model |
| SharePoint automatic mode | All versions for the first 30 days; hourly versions from day 30 to 60; daily versions from day 60 to 180; weekly versions after day 180; the cap remains 500 versions | Trimming old versions is default behaviour; the latest version never expires |
| Google Drive: trash | 30 days, then automatic permanent deletion | Users cannot change this period; manually emptying trash means permanent deletion |
| Google Drive: non-native file old versions | An old version may be deleted after 30 days, or after 100 versions are stored | Except versions marked Keep Forever; up to 200 versions can be marked Keep Forever; the latest version is never automatically deleted |
| Google Workspace: admin restore of permanently deleted files | An extra 25 days after permanent deletion | Admin restore is a bulk restore of data deleted in a period, not a guarantee of precise per-file recovery |
| Dropbox: Basic, Plus, Family | Deleted files and version history, 30 days | Basic accounts have no Rewind |
| Dropbox: Professional, Essentials, Standard, Business | 180 days | Retention depends on plan; never assume everyone has the same period |
| Dropbox: higher-tier team plans and the Extended Version History add-on | Longer retention; check the official plan page; pricing on individual quotation | Extending retention does not bring back already-expired files |
| iCloud Drive: Recently Deleted | 30 days | This is a deletion buffer, not long-term per-file version history; Apple does not clearly list a general file version retention period, so never assume an old version exists |
| iCloud.com Restore Files | Restorable within 30 days | A separate restore route from Recently Deleted |
Two clocks must be kept apart when reading the table. A deletion buffer runs from the moment of deletion, not from the moment of discovery. Version history follows two models: a day-count model, where versions vanish on expiry, and a count model, where the oldest version is pushed out when the cap is hit. Both clocks run together, and whichever arrives first decides how an old version disappears.
How Versions Disappear: Four "Discovered Too Late" Mechanisms
Mechanism 1: Trash auto-emptying
Google Drive trash empties automatically after 30 days, iCloud Recently Deleted removes files after 30 days, OneDrive personal after 30 days and work/school generally after 93 days. A user may only notice a missing old file months later, and may have manually emptied the trash in between to free space, instantly zeroing the clock. Prevention is direct: never empty the trash to free space; before deleting an important file, copy it separately to a location that does not sync; check the trash regularly for mistaken deletions, especially in shared folders.
Mechanism 2: Versions pushed out by newer versions
Under day-count models, Google non-native file old versions can be deleted after 30 days, Backblaze default versions leave the backup after 30 days, and SharePoint automatic mode trims old versions into hourly, daily and weekly representative versions, deleting the versions in between. Under count models, IDrive keeps at most 30 old versions, so the 31st change pushes out the oldest; SharePoint caps at 500 versions and trims the oldest when full. A frequently edited file can burn through 30 versions in a very short time; a rarely edited file can stretch 30 versions over many years. When a file is edited badly and the user keeps using and saving it, the old correct version is quietly pushed out by new wrong versions. By discovery time, every version in history may already be wrong.
Prevention: before changing an important document, save a separate date-stamped copy instead of relying only on automatic version history; apply Keep Forever or snapshot-locking marks only to genuinely important versions; spot-check an old version regularly to confirm it opens and its content is correct.
Mechanism 3: Snapshot rotation overwriting
The smaller the backup disk and the more frequent the file changes, the faster old snapshots rotate away. Having a NAS or Time Machine does not mean full history exists; history depth depends entirely on disk size and rule settings. Prevention: leave spare space on backup disks and avoid running them permanently full; write down retention rules and check periodically how old the oldest snapshot is; for milestones such as tax filing, contract signing or thesis submission, make an extra copy that does not rotate.
Mechanism 4: Dwell time longer than retention
After ransomware encrypts files, the sync program uploads the encrypted version as the latest version; a backup program that runs after encryption also backs up the encrypted version as a new version. If discovery comes late, every version inside the retention window may already be encrypted. Dwell-time figures differ across organisations because they measure different indicators, so no single figure should be treated as settled; the safe statement is only that dwell time can run to days or even weeks depending on attack method. At mechanism level, prevention is clear: retention must exceed a reasonable discovery time; at least one copy must exist that sync cannot touch and newer versions cannot push out; on discovering encryption, stop sync and backup immediately so the backup program cannot overwrite old correct versions with encrypted ones.
Backup Software Retention Rules: Frequent Snapshots Do Not Mean Long Retention
| Tool | Retention logic | Most common misunderstanding |
|---|---|---|
| Apple Time Machine | Hourly backups for the past 24 hours; daily backups for the past month; weekly backups thereafter; when the backup disk fills, the oldest backup is deleted first | A deleted file does not stay in backup forever; hourly backups older than 24 hours are removed except the daily one; daily backups older than a month are removed except the weekly one; how long a deleted file stays in backup has no fixed day count, and depends on which snapshot holds it and when that snapshot is thinned or deleted |
| Windows File History | Backs up every hour by default; default retention Forever; can be changed to until space is needed, or a fixed period | Forever is only the default option; when the disk fills or a fixed period is set, old versions are still cleared; by default it only covers user folders and libraries, not a full-machine backup; actual options depend on the Windows version in use |
| Synology Snapshot Replication | Grandfather-Father-Son retention: hourly, daily, weekly, monthly and yearly snapshot counts can be set separately; one snapshot can satisfy several rules at once; when many snapshots exist in one period, only the earliest snapshot of that period is kept | Snapshot frequency and retention length are separate settings and must be checked separately; shared-folder snapshots can run as often as every 5 minutes; system limits are 65,536 snapshots in total, 1,024 per shared folder and 256 per LUN, with actual limits varying by model; snapshots without locking are still rotated away |
| Veeam Agent for Mac | Keeps restore points for the past 7 days by default; retention is set in days, up to 9,999 days | A day count alone does not mean long protection; it matters whether backups actually ran |
| Veeam Agent for Windows | Retention counts successful backup days, not calendar days; setting N days actually retains N plus 1 days | A computer left off for a month has a retention clock that never moved; a computer turned on and backed up daily loses old versions fastest |
| Macrium Reflect | Retention rules can be set separately for full, differential and incremental backups; deleting a full backup also deletes every differential and incremental backup attached to it; incremental restore needs the whole chain intact | The cause is not version expiry but a retention rule deleting a whole chain, so a time point assumed to exist is actually gone |
| Acronis True Image / Cyber Protect Home Office | Automatic cleanup requires choosing a Custom scheme in the Backup scheme, with rules by version count or version age; cloud copy cleanup can set how many recent versions to keep and versions older than how many days to delete; manual cleanup must use the built-in tool, never deleting backup files directly in File Explorer | Manual cleanup deletes all version chains except the latest one by default; the OEM manual lists a default of 20 recent versions, deleting the oldest when the 21st version is created, and that figure applies only to the OEM manual, not to all versions |
| IDrive | Keeps at most 30 old versions; accounts opened before 7 November 2018 support at most 10 versions | This is a version-count model, not a day-count model; never write 30 versions as 30 days |
| Backblaze Personal Backup | Default version history 30 days; can be extended to one year; enabling extended version history does not bring back already-deleted data | Pricing details must be verified inside the account; pricing on individual quotation |
| Backblaze B2 | By default keeps all versions of a file until explicitly deleted; with latest-version-only retention, an old version is deleted 1 day after being hidden; days to keep old versions are user-defined | Retention is fully decided by bucket lifecycle rules; a wrong rule at bucket creation can clear old versions in 1 day, or let them accumulate |
| Wasabi | With bucket versioning on, every version of every object is kept; on overwrite or deletion, the old version can still be retrieved by version number; a default GET only returns the latest version; Object Lock can block modification, overwrite and deletion of specific object versions during a set retention period | Storage cost rises as versions accumulate when versioning is on; Object Lock must be used together with versioning |
Hypothetical scenario: a user takes a Synology snapshot every day and assumes any day from a year ago can be restored. Under a daily schedule, if a weekly retention rule is set, Grandfather-Father-Son rules keep only the earliest snapshot of each week, so a specific Wednesday version from a year ago has very likely been trimmed away. Daily snapshots do not mean daily versions survive for a year.
Five Things to Do Immediately After Deleting or Editing the Wrong File
The order below is a suggested order, not any vendor's official five-step method. Common wrong orders are saving a corrected version straight over the mistake, or emptying the trash immediately to save space; both make old versions disappear faster.
First, stop sync. Pause cloud sync so the wrong version or deletion stops spreading to other devices and the cloud. In OneDrive, the official method is to use the taskbar OneDrive icon and choose Pause syncing or Quit OneDrive; to stop fully, use Stop sync or Unlink this PC in settings. Note the trade-off: if a large-scale mistaken deletion is already under way, sometimes the safest course is to let it finish and then restore from the recycle bin, rather than forcing a stop halfway. When unsure, pause and think before touching anything, rather than saving over the file immediately.
Second, stop writing, and do not save new files in the same location. This is general advice, not vendor official guidance. The aim is to avoid new data overwriting old versions or deletion traces that can still be recovered. For important data, do not experiment blindly; seek professional help.
Third, check version history. Look in the file's own version history for the version before the mistake. In OneDrive, right-click the file in File Explorer and choose Version history; in Google Drive, right-click on the web version and choose Manage versions; in Dropbox, check Activity and Version history on the web version. Check timestamps first; never press Restore immediately. After a OneDrive restore, the replaced current version becomes the previous version in history, so restoring the wrong one makes the mess worse.
Fourth, check trash, recycle bin and Recently Deleted. If the file was deleted rather than wrongly edited, a deleted file should be checked here first. Periods differ: Google Drive trash 30 days, OneDrive personal 30 days, work/school generally 93 days, iCloud Recently Deleted 30 days, Dropbox 30 days or 180 days by plan, with longer retention on higher-tier plans.
Fifth, check the second backup. If version history and trash both come up empty, look in Time Machine, File History, NAS snapshots or an external backup disk. The goal is a time point before the incident, not the latest backup. The latest backup has very likely already synced the wrong version, so restoring it only brings back the wrong version.
Retention Planning Worksheet: Ask Questions, Do Not Assign Years
No universal retention formula exists. A worksheet works by forcing clear answers to the questions below; only then does it become clear which data needs frequent versions, which needs long retention, and which deserves manual locking.
Questions for personal users:
1. If this data went back to last month's version, would it still be useful? Work in progress and design drafts need frequent versions; finished old photos need long retention, not frequent versions.
2. Could this data be edited wrongly and discovered late? An old document opened once a year, or a tax return draft, may only be discovered after the cloud 30-day version window has passed.
3. Does any data rely on only one service for version history? Data only in Google Drive, with no Time Machine or external backup, has no second chance once the version period passes.
4. Is any version a milestone worth locking manually? This maps to features such as Google Drive Keep Forever and Synology snapshot locking. Not every version needs keeping; only key versions need deliberate protection.
5. After changing phones, computers or plans, does old version history still exist? Verify before switching, not after.
Extra questions for small offices:
1. After an employee leaves or changes accounts, what happens to the version history of files they own? Write it in the handover list; never wait until the account is deactivated to find out.
2. In shared folders, who can delete or overwrite? Is the version history period shorter than the time needed to discover an error? A quarterly accounts error may only surface months later.
3. Do financial and contract file versions rely only on a cloud service default retention period? If so, should an archive copy unaffected by version periods be added, such as regular exports or an offline disk?
4. Is each service's retention period and responsible person written down? The retention column needs regular updating, because plans and official policies change.
The only legislation period that can be stated: Hong Kong Inland Revenue Ordinance (Cap. 112), section 51C, requires a person carrying on business in Hong Kong to keep sufficient business records so assessable profits can be readily ascertained; records relating to any business transaction must be kept for at least 7 years from the date the transaction is completed. The source is the Inland Revenue Department official FAQ.
State the distinction clearly: a legislation record-retention duty is not the same as cloud version history. The Inland Revenue Department requires the transaction record itself to be kept for 7 years, not Google Drive to keep versions for 7 years. Meeting the legislation duty means keeping a separate complete record copy, not relying on a default 30-day version history. For every other data category, retention years follow individual professional advice or contract terms.
Handover Checklist Before Changing Computers or Services
Version history follows the account and service, not the file. Downloading a file from an old cloud service and uploading it to a new service yields only the latest version; old version history does not move along. Time Machine or File History backups on an old computer belong to that computer's backup set; if the old backup disk is not kept when switching to a new machine, old time points are gone. Cloud recycle-bin clocks keep running; files already inside a deletion or version window do not pause just because handling is deferred until later.
Tick each item before deactivating an old account:
1. List which files still need old versions, not just the latest version, such as contract revision history, old design drafts and financial working papers.
2. In the old service, download or mark each needed old version one by one. In Google Drive, use Manage versions to download an old version or mark Keep Forever; in OneDrive, check versions one by one in Version history; in Dropbox, preview in Version history and download a copy before using Roll back, never overwriting directly.
3. Confirm which version arrived in the new location. Open the file and check content and date; never rely on filename and file size alone.
4. Keep old backup disks and old NAS snapshots until the new machine has been fully checked.
5. Before deactivating an old cloud account, check whether shared-file ownership has been transferred. Files not owned by the user do not necessarily disappear when the user's own account is deactivated; but if the owner deactivates, everyone can be affected. Google states that a non-owner emptying their own trash does not remove access for others; owner deletion is a different case, so check carefully rather than assuming.
6. After switching services, set version retention rules again in the new service. Never assume new service defaults match old service defaults; Dropbox 30 days versus 180 days by plan is a clear example.
7. Write down which old versions were exported, where they are stored, and who is responsible. Proof of completed handover is a list, not a feeling that everything was probably moved.
8. How long an account can be recovered after deletion or deactivation depends on the provider's current account deletion policy. Before deactivation, export important files together with needed old versions, and verify the current account deletion policy with the provider.
Common Misconceptions
| Misconception | Truth |
|---|---|
| A file in the cloud means a backup exists | Sync only copies the latest state; deletion, bad edits and encryption all sync |
| The cloud keeps unlimited versions, so any day can be restored | Every mainstream service has a cap: Google 30 days or 100 versions, OneDrive personal 30-day restore window, Dropbox free and cheaper plans 30 days, Backblaze default 30 days |
| A deleted file must still be in the cloud | Trash has a deadline; after expiry, manual emptying or permanent deletion, personal accounts have basically no official restore route; work/school and Workspace accounts have extra admin windows |
| A NAS snapshot means permanent storage | Synology snapshots have count caps, Grandfather-Father-Son trimming rules and disk-space limits; unlocked snapshots are still rotated away |
| Time Machine holds all history | Time Machine thins: hourly versions only for 24 hours, daily versions only for a month, weekly versions last longer, and a full disk deletes the oldest |
| File History default Forever means never deleted | Forever is only the default option; changing to until space is needed or a fixed period still clears old versions; by default it only covers user folders |
| Upgrading a cloud plan can rescue already-expired files | Extending retention is not retroactive: Backblaze states enabling extended version history does not restore deleted data; Dropbox guidance likewise states upgrading does not bring back expired files |
| Restoring successfully means restoring correctly | Restoring the latest version is not restoring the correct version; when the correct version has been pushed out, everything left is wrong versions, technically a successful restore but practically useless |
| iCloud or Google Drive must have per-file version history | iCloud Drive general file version history has no clear official statement; Google native documents and non-native files follow different version rules and must not be lumped together |
| Buying a cloud backup service means retention is handled | Backblaze defaults to 30 days, IDrive to 30 versions, B2 and Wasabi retention is decided by user lifecycle or version policies; buying does not mean settings are correct |
Frequently Asked Questions
Does a sync folder count as backup?
No. Sync aims for the same latest state on every device, and deletion, overwriting and encryption all propagate. Backup aims to bring back an old version when something goes wrong; the design goals are fundamentally different.
After deleting a file, how long is recovery still possible?
It depends on service and plan. Google Drive trash 30 days, OneDrive personal 30 days, work/school generally 93 days, iCloud Recently Deleted 30 days, Dropbox 30 days or 180 days by plan, with longer retention on higher-tier plans. The clock runs from deletion, not from discovery.
Why does version history contain only wrong versions?
Because after a bad edit, the user kept using and saving the file, and old correct versions were pushed out by new wrong versions. Day-count models expire, count models hit their cap, and thinning models delete intermediate versions. Any one of those mechanisms running to the end leaves only wrong versions.
Can upgrading a cloud plan rescue already-expired files?
No. Extending retention is not retroactive. Backblaze states enabling extended version history does not restore deleted data, and Dropbox guidance states upgrading does not bring back expired files. Upgrading only affects versions after the upgrade; past versions do not return.
Do Time Machine or NAS snapshots mean permanent storage?
No. Time Machine thins versions and deletes the oldest when the disk fills. Synology snapshots have count caps, Grandfather-Father-Son trimming rules and disk-space limits. Frequent snapshots do not mean long retention; the two settings must be checked separately.
How should retention be calculated?
There is no universal formula. Answering the worksheet questions above shows which data needs frequent versions and which needs long retention. The only legislation period that can be stated is the 7-year tax record duty, and that is the transaction record itself kept for 7 years, not cloud version history kept for 7 years. Other categories follow individual professional advice or contract terms.
When switching cloud services, do old versions move along?
No. Version history is a feature inside a service; downloading and re-uploading yields only the latest version. Before switching, download or mark each needed old version one by one, then open the file in the new location and check content and date to confirm which version arrived.
What should be done first when files are suspected of being encrypted?
Stop sync and backup immediately so encrypted versions stop spreading and overwriting old correct versions; then look in version history and a second backup for a time point before the incident, never overwriting with the latest backup. Dwell time can run to days or even weeks, so versions inside the retention window may already all be encrypted, and a copy unaffected by sync becomes most important at that point.
Sources
- Microsoft official: Restore your OneDrive files
- Microsoft official: Restore a previous version of a OneDrive file
- Microsoft official: Cancel or stop sync in OneDrive
- Microsoft Learn official: SharePoint default version limits
- Microsoft Tech Community official: SharePoint automatic version cleanup
- Apple official: Delete iCloud Drive files
- Apple official: Restore iCloud Drive files
- Apple official: Time Machine backup
- Google Developers official: Manage Drive revisions
- Google official: Drive trash and file deletion
- Google Vault official: Restore deleted data
- Dropbox official: Recover older versions
- Dropbox official: Missing, reappearing or corrupted files
- Dropbox official: Extended Version History
- Synology official: Snapshot Replication retention
- Synology official: Snapshots guide
- Synology official: Snapshot Replication specifications
- Backblaze official: Extended version history
- Backblaze official: B2 lifecycle rules
- Wasabi official: Versioning
- IDrive official: Versioning
- Veeam official: Mac retention
- Veeam official: Windows retention days
- Macrium official: Reflect getting started and retention rules
- Acronis official: Cleanup and backup scheme
- Inland Revenue Department official: Record-keeping FAQ
- CrashPlan: Common OneDrive backup myths
- NinjaOne third-party guide: File History retention best practices
Related Articles
- How 3-2-1 backup basics work
- How to test whether a backup really restores
- How to set up a home NAS securely
Frequently Asked Questions
Does a sync folder count as backup?
No. Sync aims for the same latest state on every device, and deletion, overwriting and encryption all propagate. Backup aims to bring back an old version when something goes wrong; the design goals are fundamentally different.
After deleting a file, how long is recovery still possible?
It depends on service and plan. Google Drive trash 30 days, OneDrive personal 30 days, work/school generally 93 days, iCloud Recently Deleted 30 days, Dropbox 30 days or 180 days by plan, with longer retention on higher-tier plans. The clock runs from deletion, not from discovery.
Why does version history contain only wrong versions?
Because after a bad edit, the user kept using and saving the file, and old correct versions were pushed out by new wrong versions. Day-count models expire, count models hit their cap, and thinning models delete intermediate versions. Any one of those mechanisms running to the end leaves only wrong versions.
Can upgrading a cloud plan rescue already-expired files?
No. Extending retention is not retroactive. Backblaze states enabling extended version history does not restore deleted data, and Dropbox guidance states upgrading does not bring back expired files. Upgrading only affects versions after the upgrade; past versions do not return.
Do Time Machine or NAS snapshots mean permanent storage?
No. Time Machine thins versions and deletes the oldest when the disk fills. Synology snapshots have count caps, Grandfather-Father-Son trimming rules and disk-space limits. Frequent snapshots do not mean long retention; the two settings must be checked separately.
How should retention be calculated?
There is no universal formula. Answering the worksheet questions above shows which data needs frequent versions and which needs long retention. The only legislation period that can be stated is the 7-year tax record duty, and that is the transaction record itself kept for 7 years, not cloud version history kept for 7 years. Other categories follow individual professional advice or contract terms.
When switching cloud services, do old versions move along?
No. Version history is a feature inside a service; downloading and re-uploading yields only the latest version. Before switching, download or mark each needed old version one by one, then open the file in the new location and check content and date to confirm which version arrived.
What should be done first when files are suspected of being encrypted?
Stop sync and backup immediately so encrypted versions stop spreading and overwriting old correct versions; then look in version history and a second backup for a time point before the incident, never overwriting with the latest backup. Dwell time can run to days or even weeks, so versions inside the retention window may already all be encrypted, and a copy unaffected by sync becomes most important at that point.