Data Recovery Case File · NAS & Network Storage · Two Obstacles, Not One
Undelete Tools Work on Structures, and Encryption Hides the Structures
His enquiry describes a deletion made harder by the volume it happened on. A folder removed in error from an encrypted partition on a company server, where three separate recovery tools "have found nothing." Two separate difficulties are stacked here — the filesystem's own handling of deletion, and the fact that everything beneath the mounted view is encrypted — and only one of them is about the deletion.
| Media | Hard drive holding an encrypted server partition — directory removed in error; multiple recovery utilities returning no content |
| Reported situation | Linux server in company use · directory deleted in error from an encrypted partition · three separate recovery utilities run against the volume · no content located by any of them · server remaining in service · recovery sought |
| Fault class | Deletion on an extent-based filesystem within an encrypted container — pointer structures cleared on deletion; carving requiring the decrypted view and continued service displacing content |
| Equipment used | Encryption layer and filesystem behaviour assessed as separate obstacles · volume removed from service before assessment · imaged write-blocked at the block level in encrypted form · decrypted view established with the owner's key before any search · carving performed against the decrypted image with journal remnants examined |
The decode: why the tools found nothing, and what can still be done
The first obstacle, and it is the one people know about: the filesystem. Modern Linux filesystems record where a file's content sits using extents, and deletion clears those records rather than merely marking them unused — so the map from filename to location is genuinely removed, not just flagged.
Why that defeats a conventional undelete: tools of that kind look for entries that still point at content. Where the pointers have been zeroed there is nothing to follow, which is why an undelete on this class of filesystem frequently returns nothing even on an unencrypted volume.
What still works in that situation: searching the raw content for recognisable file structures, without reference to any directory. Documents, images and archives carry identifiable openings, and they are found by pattern rather than by pointer.
The second obstacle, and it is why that fallback failed too: the partition is encrypted. Below the mounted view, every block is encrypted data indistinguishable from noise — so a search for file patterns run at the wrong level finds nothing, because the patterns only exist once decrypted.
Why that matters for how the tools were run: a search has to operate on the decrypted view. Run against the underlying device it is searching ciphertext, and no amount of capability changes that.
Why the encryption is nevertheless not the problem people assume: he has the key — the volume mounts normally. Encryption here is an obstacle to the method rather than to the data, and with the key available a decrypted image is straightforward to produce.
What that image then allows: everything a normal recovery would do. Carving across unallocated space, examination of filesystem journal remnants, and reconstruction of directory entries that may survive in the journal even where the live structures were cleared.
Why the journal is worth particular attention here: it records intended changes before they are applied. Entries describing the deleted directory may persist there after the live records are gone, and where they do, names and locations come back with the content.
What is doing the most damage right now: the server remaining in service. An active server writes continuously into space marked as free, which is exactly where the deleted content sits — and this is the only variable still under his control.
What must happen first: the volume out of service, and an image taken. Every hour of continued operation reduces what any method can return, and no technique compensates for content that has been written over.
On the bench
The encryption layer and filesystem behaviour were assessed as separate obstacles — extent-based filesystems clearing location records on deletion rather than flagging them, so conventional undelete has no pointers to follow, while carving requires recognisable file patterns which exist only in the decrypted view, every underlying block otherwise being indistinguishable from noise. A decrypted view was established with the owner's key before any search, with journal remnants examined for entries surviving the live structures.
The outcome
Encryption and filesystem behaviour assessed separately, the volume removed from service, and carving performed against a decrypted image with journal remnants examined. Free assessment, one fixed written figure including VAT. The decode: two obstacles were stacked. Deletion on that filesystem clears the location records rather than flagging them, and a pattern search run below the encryption is searching noise — so the tools were working at the wrong level.
A deletion on an encrypted Linux volume
Take the volume out of service now — an active server writes continuously into exactly the space your deleted content occupies, and that's the only variable still in your control. Two things defeated the tools you ran. Extent-based filesystems clear a file's location records on deletion rather than flagging them, so conventional undelete has nothing to follow. And pattern-based searching only works on the decrypted view, because below the encryption every block is indistinguishable from noise. With your key available, a decrypted image restores the normal options, including journal remnants.
Take it out of service — call Manchester Data Recovery on 0161 871 0788; encryption and filesystem behaviour assessed separately, imaged at the block level, carving performed against a decrypted image.
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.