Chapter 6 — Key Takeaways
The big idea
Logical recovery solves the most common data-loss scenario there is: the storage device works perfectly, but the logical structures that organize the data — partition table, file system, directory entries — are deleted, formatted, or corrupted. The data itself is almost always still on the platters or in the flash, because deletion and quick formatting change bookkeeping, not content. Recovery is the disciplined work of rebuilding or bypassing that bookkeeping — and the single habit that makes it safe is to image first, verify with a hash, and touch only the copy, even when no court will ever see the job.
What "delete" leaves behind — it depends entirely on the file system
The technical heart of the chapter, in one table. The method never changes (find the surviving metadata, follow it to the data); the specifics decide how much help you get.
| NTFS (MFT) | FAT (dir entry) | ext4 (inode) | |
|---|---|---|---|
| File name | full | all but 1st char (→ 0xE5) |
not in inode |
| Size | yes | yes | yes |
| Timestamps | yes ($SI` + `$FN) |
yes | yes (+ dtime) |
| Map to data | YES (data runs survive) | start cluster only (chain zeroed) | NO (extents zeroed) |
| Data clusters | intact | intact | intact (freed) |
| Practical result | near-perfect undelete | perfect if contiguous; carve if fragmented | journal/extundelete for recent; else carve |
The deleted state on NTFS is just the in-use bit cleared at record offset 0x16. On FAT the start cluster and size remain but the chain is gone. On ext4 the size and a deletion time remain but the extent tree is wiped.
The non-negotiables
- The original is sacred. Image it once, verify the hash, work on the copy — for recovery (it is irreplaceable and your tools write) and for forensics (admissibility and chain of custody). Same action, two purposes.
- Stop using the affected volume. Continued use is the number-one destroyer of recoverable data; every new write may land on the clusters you want.
- Recover to a different device than you recover from, or you overwrite the files you have not reached yet.
- Never run
chkdsk/fsck/"repair" tools or a read-write mount on the original — they fix file systems by writing to them.
When it will not work (know your limits)
- Overwritten clusters — the absolute limit; one pass is, for recovery, the end.
- Reused metadata — if the MFT record was recycled, the map is gone; carve instead.
- SSD with TRIM — deleted blocks are erased by the controller within seconds; recovery often returns zeros (Chapter 9).
- Completed Vista+ full format,
diskpart clean all, secure erase — deliberate overwrites. - Strong encryption without the key — recovered ciphertext is useless (Chapter 29).
You can now…
- ☐ Explain exactly what deletion changes — and leaves intact — on NTFS, FAT/exFAT, and ext4, and predict how recoverable a deleted file is on each.
- ☐ Image a drive before recovery, verify it with a hash, and conduct all work on the copy.
- ☐ Recover deleted files from surviving metadata using both GUI tools (TestDisk, DMDE, R-Studio, UFS Explorer) and the read-only, reproducible Sleuth Kit workflow (
fls/icat/tsk_recover). - ☐ Distinguish quick from full formats, recover from a reformatted drive via residual structures and backups, and rebuild a lost partition table from file-system signatures.
- ☐ State honestly when data is unrecoverable — overwritten, reused metadata, TRIM, or encryption — and document that finding professionally.
Looking ahead
Chapter 7 — File Carving. When the MFT is overwritten, the FAT chain is gone, or ext4 has zeroed its extents, you recover files directly from raw data by their signatures — headers, footers, and internal structure — with no metadata at all. It is how we rescued the carved portion of the wedding drive, and the tool you reach for when undelete has nothing left to read.
One sentence to carry forward: Deletion removes the pointer, not the data — so recovery is rarely about retrieving bytes, and almost always about rebuilding the signposts that point to bytes that never left.