Data Recovery Case File · Formatted & Logical Faults · Check the Account First
A Sync Client Keeps Its Copy Inside the Profile, and the Service Keeps Another
This enquiry concerns institutional research data and a deletion that took a container rather than files. A machine where "the data was transferred to a cloud service at one point and we suspect it was in the user's local cache. But the user's profile appears to have been corrupted or deleted." The local cache lives inside the profile, so removing one takes the other — but the service holds the authoritative copy, and that is where to look before touching the machine.
| Media | Desktop machine system volume — user profile corrupted or removed, taking the synchronisation client's local store with it; content believed synchronised to a cloud service |
| Reported situation | Research data held on a desktop machine · data transferred to a cloud synchronisation service at some point · local copy believed held in the client cache within the user profile · profile subsequently corrupted or deleted · content required |
| Fault class | Profile-level loss with service-side copy potentially authoritative — synchronisation completion and profile detachment both to be established before recovery |
| Equipment used | Service-side account contents established before any local work · profile deletion distinguished from profile detachment · machine taken out of service pending assessment · volume imaged write-blocked · profile directory recovered from surviving structures |
The decode: three questions, in order, and two of them are free
The first, and it may end this entirely: what is in the account? A synchronisation service holds the authoritative copy — the local cache is a convenience, not the master. If the data reached the service, it is there regardless of what happened to the machine, and signing in settles it in minutes.
Why "transferred at one point" needs qualifying: synchronisation takes time, and a large research dataset may not have completed. The client reports progress and completion, and a transfer interrupted by the profile problem may have uploaded part of it. The account shows what actually arrived.
The complication worth knowing about: these clients offer a mode where files appear in the folder while existing only in the service until opened. Under that arrangement the local cache never held most of the content — which is good news here, because it means the service copy is the only one that ever mattered.
The second question, also free: was the profile deleted or detached? Those look identical to a user and are entirely different on disk. A detached profile — where the account no longer resolves to it — leaves the folder intact and merely unreferenced, and reconnecting it restores everything. A deleted profile is a directory tree removed.
How to tell: look for the profile folder under the users directory with hidden items shown. If it is present, this is an access problem rather than a loss, and taking ownership of it makes the contents readable.
Why that distinction is so often missed: a profile that no longer loads presents as a machine that has forgotten everything, and the natural conclusion is that it is gone. Frequently it is sitting there under a slightly different name.
The third question, if both of the above fail: what has been written since. A deleted profile on a system volume is exposed to continuous writing — logging, indexing, updates — so the machine must come out of service immediately if a local recovery is needed.
What must not happen: no attempt to recreate the profile, and no reinstallation. Recreating writes a fresh profile tree into the space the old one occupied.
On the bench
Service-side account contents were established before any local work — a synchronisation service holding the authoritative copy while the local store is a cache, and clients offering modes in which content exists only in the service until opened. Profile deletion was distinguished from profile detachment, a detached profile leaving its directory tree intact and merely unreferenced, which presents identically to the user. The machine was taken out of service pending assessment.
The outcome
The account established before any local work, deletion distinguished from detachment, and the machine removed from service pending assessment. Free assessment, and no charge where the answer is a login or a folder already present. The decode: the service holds the authoritative copy and the local store is a cache — so check the account first. Then check whether the profile is deleted or merely detached, because those look identical and only one is a loss.
Data in a sync folder on a profile that has gone
Sign into the service before touching the machine — it holds the authoritative copy, and the local folder is a cache rather than the master, so if the data reached the account it's there regardless of what happened to the profile. Check whether synchronisation actually completed, since a large dataset may have been partway. Then look under the users directory with hidden items shown: a profile that no longer loads is often detached rather than deleted, sitting intact under a slightly different name, and those two look identical to you. Don't recreate the profile or reinstall, and take the machine out of service.
Check the account first — then call Oxford Data Recovery on 01865 593000; service contents established before any local work, deletion distinguished from detachment, profile directory recovered from surviving structures.
Request a quote online →
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.