Data Recovery Case File · Formatted & Logical Faults · Two Layers, One Header
Container Encryption Keeps a Spare Copy of Its Own Header at the Other End of the Volume
This enquiry arrives via a colleague and reports both the mistake and the response. An external drive used for project work, "encrypted using a container tool", which was "accidentally formatted" — and, importantly, "he removed the drive straight away." That combination is more recoverable than it sounds, because the encryption scheme in question anticipates exactly this and keeps a duplicate of the structure that matters.
| Media | External 2.5-inch hard disk encrypted with a container scheme — volume formatted in error; drive removed from use immediately afterwards; project content held |
| Reported situation | External disk used for project work · full-volume encryption applied using a container tool · volume formatted accidentally · drive disconnected immediately on discovery · no further use since · enquiry submitted by a colleague on the owner's behalf · recovery quotation requested |
| Fault class | Encrypted volume header overwritten by formatting — backup header retained at the end of the volume; ciphertext regions substantially untouched |
| Equipment used | Backup header location established before any recovery route was chosen · drive imaged write-blocked at the block level before any interpretation · encryption scheme identified from residual structures · backup header located at the volume tail and used to derive the volume key with the owner's passphrase · decrypted volume interpreted offline and content extracted |
The decode: why the backup header changes everything, and what still has to be supplied
What container encryption places at the start of a volume: a header. A small structure holding the encrypted keys needed to unlock everything, without which the rest is uninterpretable.
Why formatting is so dangerous to it: that is exactly where a format writes. A new filesystem's own descriptors are placed at the beginning of the volume, over the header.
Why the scheme anticipated that: header loss was always the obvious failure. These tools write a second copy of the header at the far end of the volume as a matter of course.
Why a format is unlikely to have reached it: it writes at the start. A standard format creates structures near the beginning and marks the rest available, leaving the tail of the volume untouched.
What that means practically: the volume can be opened from the backup. The duplicate header is located and used to derive the keys, and the encrypted volume mounts as it did before.
Why the ciphertext itself is almost certainly intact: a format writes very little. Marking capacity available does not overwrite it, so the encrypted content occupies the drive exactly as it did.
Now the requirement that cannot be worked around: the passphrase. The backup header is encrypted too, and without the owner's passphrase neither copy can be used by anyone.
Why that is worth confirming before quoting anything: it determines feasibility entirely. With the passphrase this is straightforward; without it, nothing is possible.
Why removing the drive immediately was the decisive action: continued use would consume the tail. Any writing after the format lands in space marked available, and enough of it would reach the backup header.
What must not happen now: no repair, no reformatting and no attempt to recreate the container. Recreating one writes a fresh header and would destroy the surviving copy.
On the bench
The backup header location was established before any recovery route was chosen — container schemes placing a header of encrypted keys at the volume start, precisely where a format writes its own descriptors, and therefore writing a duplicate at the far end as standard practice. A standard format creates structures near the beginning and marks the remainder available without overwriting it, leaving both the tail and the ciphertext intact. The backup header was used to derive the volume key.
The outcome
Backup header location established first, the drive imaged before any interpretation, and the volume opened from the duplicate header. 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: the scheme anticipated this. It keeps a second copy of its header at the far end of the volume, and a format writes at the beginning — so removing the drive at once preserved it.
An encrypted volume that has been formatted
Stop using the drive at once, as was done here, and don't reformat it or recreate the container — recreating one writes a fresh header and would destroy the copy you're relying on. The good news is structural: container schemes keep a duplicate header at the far end of the volume precisely because losing the one at the start is the obvious failure, and a format writes at the beginning. Confirm the passphrase is known before anything else, because without it nothing is possible.
Leave it disconnected — call Cambridge Data Recovery on 01223 655015; backup header located at the volume tail, imaged before any interpretation, volume opened from the duplicate with your passphrase.
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.