Rescuing data from a failing NVMe with bad MFT sectors

My C: drive started throwing bad block events. I ran read-only diagnostics and rescued 12.6 GB of irreplaceable data before the damage spread.

The damage

chkdsk found four consecutive unreadable MFT file-record segments. Reading them during the scan emitted 133 fresh bad-block events. Four user files had CRC errors. Windows would not expose Available Spare or Media-and-Data-Integrity-Errors from the NVMe SMART log.

Rescue

I copied 105,310 files to Google Drive, then another 1,700 loose files from the Projects root. Zero read failures on either pass. I skipped three credential files and one 4.62 GB log that exceeded the FAT32 4 GB limit on the Google Drive mount.

The verify step needed a 60-second pause for Google Drive sync latency. Without it, 508 files falsely reported missing.

SMART data

After the rescue I ran CrystalDiskInfo. It read the log pages Windows could not.

Available Spare was 100%. Media and Data Integrity Errors was 23 lifetime. Percentage Used was 3%. The drive is healthy and unworn. The bad sectors are fixed historical damage, not progressive failure.

Cleanup

I reclaimed 60.16 GB by deleting npm cache, pip cache, node_modules, build artifacts, temp files, and the recycle bin. Free space went from 54.52 GB to 114.69 GB.

I verified that EpsteinScan had zero dependencies on the EpsteinFiles directory. All 45 hardcoded paths were resolvable. Production deploys from GitHub, not local disk. I copied 46 gitignored scripts to Google Drive, exported the stash and working diff as patches, and deleted EpsteinFiles. That removed 675.66 GB in 10.7 minutes. Free space jumped to 791.32 GB.

EpsteinScan remained intact. The database was unchanged at 8.7 GB and the stash survived.

Outstanding

The EpsteinScan stash hardcodes a live Cloudflare R2 secret. I need to rotate it and check whether it is already on the public GitHub repo.