Data Recovery Case File · Formatted & Logical Faults · Unrecognised, Not Erased
RAW Means the System Cannot Identify a Filesystem, Which Is Not the Same as There Being None
This enquiry uses a term precisely enough to work from. Malware on a work machine that "converted the main drive filesystem to RAW", with the writer called in afterwards by a friend and uncertain whether important documents are present. RAW is not a state a drive is put into — it is what a system reports when it cannot identify what kind of filesystem it is looking at, which says nothing about whether the content is still there.
| Media | 1TB desktop hard drive from a work machine following a malware incident — volume reported as having no identifiable filesystem |
| Reported situation | Malware present on a work computer · main volume subsequently reported as unformatted or unidentifiable · assistance provided by a third party after the event · presence of required documents uncertain · professional recovery proposed by that party · content sought |
| Fault class | Filesystem identification failing — boot sector or superblock damaged, or volume encrypted by hostile software; content present in either case pending distinction |
| Equipment used | Unidentifiable volume distinguished from erased volume before any conclusion was drawn · no repair or check permitted on the drive · imaged write-blocked at the block level before any interpretation · content sampled for entropy to distinguish structural damage from encryption · filesystem structures interpreted with their duplicate copies where damage was structural |
The decode: what the word means, and the distinction that decides everything
How a system decides what a volume is: it reads a small record at the start. That record identifies the filesystem type and describes its layout, and everything else follows from it.
What happens when that record is unreadable: the system has no way to proceed. It reports the volume as having no recognised format, which is the label being described here — a statement of failure to identify rather than a finding about content.
Why that distinction is the whole case: the content sits elsewhere on the volume. A damaged identifying record leaves gigabytes of files exactly where they were written, unreachable only because nothing knows how to interpret the arrangement.
The first possibility — structural damage. Hostile software frequently overwrites the start of a volume, because it is small, fast and disproportionately damaging. A few kilobytes destroyed at the beginning makes an entire drive unreadable.
Why that version recovers well: filesystems keep duplicate copies of their key records elsewhere. Reconstruction from the duplicate frequently returns the volume complete with folders and names.
The second possibility — the content itself was encrypted. Some hostile software encrypts files rather than damaging structures. The volume then reports as unidentifiable because encrypted content resembles nothing in particular.
Why that version is far worse: the data is transformed rather than merely undescribed. Without the key it cannot be returned by anyone, and no amount of structural work changes that.
How the two are told apart, and it costs nothing: by looking at the content itself. Damaged structures leave ordinary files that still look like documents and images; encrypted content is uniformly high-variability throughout.
Why that check comes first: it determines whether there is a case at all. Establishing which situation this is should precede any discussion of cost, and it is done on an image rather than the drive.
What must not happen meanwhile: no repair, no check and no reformatting. A consistency check offered against an unidentifiable volume writes new structures over the region a reconstruction reads.
On the bench
An unidentifiable volume was distinguished from an erased volume before any conclusion was drawn — systems identifying a filesystem from a small record at the volume's start, so an unreadable record produces a report of no recognised format, which describes failure to identify rather than absence of content. Hostile software commonly overwrites that region, being small and disproportionately damaging, while some instead encrypts content. Content was sampled for entropy to distinguish structural damage from encryption.
The outcome
The unidentifiable volume distinguished from an erased one, no repair permitted on the drive, and content sampled to separate structural damage from encryption. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: that label describes the computer failing to identify a filesystem, not the drive being emptied. Which of two things happened decides everything, and it is answerable before any cost is discussed.
A volume reported as having no recognised filesystem
Don't run a repair, a check or a reformat, since a consistency check offered against an unidentifiable volume writes new structures over exactly the region a reconstruction reads. Understand the label: a system identifies a filesystem from a small record at the volume's start, so an unreadable record means it can't tell what it's looking at — not that your files are gone. Two things produce it. Hostile software overwriting that small region, which usually recovers well from the filesystem's own duplicate copies; or the content being encrypted, which does not.
Don't run a check — call Manchester Data Recovery on 0161 871 0788; unidentifiable distinguished from erased, imaged before any interpretation, content sampled to separate structural damage from encryption.
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.