Pablo #3: The drive that refused to die
Part 3 of the Pablo saga, in five parts. Previously: Pablo #2. Next: Pablo #4.
August-September 2026 - The drive that wouldn't quit, and the laptop that wouldn't behave.
By now the diagnosis wasn't looking good, and Pablo was still alive. Windows booted. Applications ran. And every stretch of normal behavior tempted me to believe things weren't as bad as they looked - until something else happened.
A storage device doesn't have to stop functioning before it becomes unreliable. That sounds obvious on paper. It feels different on your own machine, where each successful boot whispers that maybe the crisis passed. I started treating every boot as evidence of exactly one thing: that the machine had booted this time.
The numbers kept moving
The reallocated and pending counters, once around 39-41, kept climbing over the following weeks:
39 → 41 → 42 → 43 → 45 → 48 → 49 → 53
Offline-uncorrectable and reallocation events moved too. Not the same measurements, not universal units of damage - but the direction was unanimous, and it was happening while the laptop kept working. This was precisely why history mattered: one screenshot hides a progression.
Then came the five BIOS 301 incidents. Not one warning - five, scattered across weeks of otherwise normal use. Days of stability, then another warning out of nowhere. I couldn't trust the machine tomorrow just because it worked today, and I couldn't read the absence of warnings as recovery either.
September 11 was the worst day:
- a sudden freeze out of nowhere
- another Winlogon problem at login
- CHKDSK running on a dirty C: volume
- MonSMART catching reallocated sectors ticking 43 to 45 mid-crisis
Around it, a burst of Event ID 7 errors, seconds apart, on the 10th through the 12th. New errors, logged while I watched. Any one event alone might have meant little; stacked on months of warnings, they made it very hard to keep calling the machine healthy.
Through it all, the endurance figure sat at 98%, unbothered. I'd stopped asking which tool was right. The useful question was what each one measured - and every measurement that mattered pointed the same way.
Filesystem clean, drive dying
Somewhere in there Windows' own tools reported a filesystem that looked clean. Worth about as much as it sounds: a filesystem can be structurally consistent at check time while the hardware underneath keeps failing. Clean chkdsk, dying NAND - related questions, not the same one.
By mid-September I stopped trying to make the installation behave. Fresh Windows can go on a new drive; apps reinstall; configs rebuild from notes. What I'd actually lose were the irreplaceable files - and that distinction set the entire recovery plan: verify backups, prep install media, erase the old drive before handover, arrange the replacement.
Backups, improvised
The clean solution - full disk image, safe somewhere, restored onto the new SSD - needed one thing I didn't have: spare storage that was actually mine. No reliable external HDD on hand, only the possibility of borrowing one. So no full image. Triage instead.
My phone had ~40 GB free, my cloud account ~25 GB. My D: drive held ~31 GB used. So instead of fighting MTP transfers, I copied nearly all of D: to my phone over SSH - because apparently, when your laptop is dying, the correct response is turning your Android phone into a remote file server. It worked. A partial backup that exists beats a perfect plan that never executes.
The inventory, such as it was:
phone free: ~40 GB
cloud free: ~25 GB
D: used: ~31 GB
browsers: ~7 GB
installer USB: 9.74 of 14.3 GB free
What made the list: projects and uncommitted work (GitHub doesn't hold what you never pushed), ~7 GB of portable browsers (profiles, sessions, extensions - reinstalling is easy, re-inhabiting is not), KeePass databases, and the portable Python/Node environment - PATH, variables, scripts, the works. Losing that to a dead drive after deliberately organizing it for portability would have been embarrassing. Skipped deliberately: reinstallables, stateless apps, caches. The goal was turning recovery into a checklist instead of a memory test.
Media next: a Hasleo emergency USB (blue background, one app, no décor), later overwritten by the Windows 10 Media Creation Tool into an ESD-USB installer with 9.74 of 14.3 GB free. Less a professional recovery operation, more a student improvising with whatever was in reach.
And one principle carried through all of it: never wait for the perfect backup setup when an imperfect one can save your data today. Files copied, configs documented, databases accounted for, installer ready. Enough to stop gambling on Pablo surviving another week - which, given its track record, would have been a questionable investment.