Data Recovery Case File · Formatted & Logical Faults · Look in Four Places

A Conflict Prompt, Answered the Wrong Way

Her enquiry describes a loss that takes one click and no failure of any kind. Uploading a document from one cloud service to another: "the machine came up with a notification about two modified versions. I clicked the most recent, but it ended up overriding my newest document with an old version. Now showing no version history. Is there a way to recover the newest document? No deleted files or anything are showing." Nothing broke. A prompt appeared, a choice was made, and the finished document was replaced by a draft. But "no version history" describes one place she has looked, and versions are kept in several independent places — most of which she has not seen yet.

The decode: the four places versions live, and why to hurry

What actually happened: two services each held a copy of the file, and they disagreed about which was current. The prompt asked her to resolve it, she selected what she reasonably believed was the newer, and the choice was applied — replacing the current file with the other copy. There was no corruption and no failure; the system did exactly what it was told, on the strength of a dialogue that gave very little information to decide with.

First place to look, and the one people miss: the cloud provider's server-side version history, viewed through the web interface rather than the desktop application. This is the important distinction. The desktop app shows what it knows locally, which after a conflict may be nothing. The service keeps its own revision history on its servers, independently, and the web interface exposes it. A document overwritten locally very often has its previous revisions sitting intact in that list, ready to restore. Both providers should be checked, because each keeps its own.

Second place — the local versions store. Some systems maintain their own document-versioning database, holding previous revisions separately from the file itself and from any cloud service. It is not visible in the folder, and an application reporting no version history is not necessarily consulting it.

Third place — autosave and temporary working copies. Applications write periodic snapshots into their own working directories, distinct from wherever the document is saved. Those frequently survive an overwrite of the original because they were never part of the sync at all.

Fourth place — any system backup. If one was configured, a snapshot taken before the overwrite holds the document as it was.

Why speed matters more than anything else here: every one of these is time-limited. Server-side revision histories are typically retained for around thirty days on personal accounts. Autosave files are cleaned up. Backup snapshots roll over. This is not a case that improves with waiting, and checking the web interfaces takes minutes.

The habit worth changing: when a system reports the same document modified in two places, the safe answer is not to choose. It is to keep both — save one under a different name first, then reconcile. A conflict prompt is a warning that information is about to be discarded.

On the bench

Server-side version history was checked through both providers' web interfaces rather than their desktop applications, since the app reflects local state — which after a conflict may show nothing — while the service retains its own revision history independently. The local document-versions store was examined independently of the application, holding previous revisions separately from the file and from any sync service. Autosave and temporary working copies were located in application working directories, and system backup snapshots checked. Recovered revisions were validated by opening.

The outcome

Both providers' server-side histories checked through their web interfaces, the local versions store and autosave copies examined, and the recovered revision validated. Free assessment, one fixed written figure including VAT, no recovery, no fee. The decode, for anyone who resolved a conflict the wrong way: "no version history" describes the desktop application's view, and versions live in four independent places — the provider's server-side history seen through the web interface, the system's own document-versions store, application autosave copies, and any system backup. Check all four today, because every one has a retention window measured in weeks. And next time a conflict appears, keep both rather than choosing.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.