A failed hard drive. Years of memories. One last chance.
Have you ever had that moment when your stomach suddenly drops?
The kind where you realize something precious might be gone forever?
For me, it happened when I plugged in an old portable Seagate drive.
I wasn’t doing anything special. I was simply looking for some old photos.
Photos of family.
Videos of my kids.
Documents.
Projects.
Memories.
The drive spun up.
Click. Click. Click.
And then…
Nothing.
No detection.
No mount.
No filesystem.
No data.
Just silence.
<hr>
<h2>“I’ll Deal With Backups Later”</h2>
Like many of us in tech, I thought I was being careful.
Months earlier, I had been rebuilding my aging desktop PC. The machine had been running Linux for years but had developed heating issues. I migrated data, took backups, planned a clean rebuild, and then life happened.
Work happened.
Family happened.
Priorities shifted.
The backup drive went into a drawer.
And there it stayed.
For months.
Until the day I needed it.
And discovered it had already died.
<hr>
<h1>The Search For Hope</h1>
After accepting that the Seagate drive might be beyond recovery, I remembered something.
An old 500GB hard disk.
A relic from years ago.
Maybe…
Just maybe…
Some of my data still existed there.
The problem?
I wasn’t even sure the drive still worked.
<hr>
<h2>Stage 1: The Hardware Archaeology</h2>
The old drive had not been powered on for years.
So began the scavenger hunt.
<h3>Attempt #1</h3>
Connect it to a Raspberry Pi using a PCIe adapter.
Result?
Not enough power.
The drive spun inconsistently.
No reliable detection.
<h3>Attempt #2</h3>
Purchase a powered adapter.
Success.
Sort of.
The drive spun properly, but mounting was inconsistent.
Sometimes it appeared.
Sometimes it vanished.
Sometimes Linux saw it.
Sometimes Windows did.
This was becoming one of those adventures.
<hr>
<h1>Windows Sees Partitions… But That’s Not Enough</h1>
I connected the drive to Windows.
Windows showed partitions.
Promising!
Except there was one small problem.
The partitions were Linux EXT4 filesystems.
Windows could see they existed.
Windows could not actually help me read them.
I tried multiple EXT4 tools.
No luck.
At this point I started considering increasingly desperate options.
<hr>
<h1>Enter Linux Rescue Mode</h1>
I had recently rebuilt a desktop system.
Windows was installed.
My kid was using it.
Deleting Windows and installing Linux wasn’t exactly a popular family decision.
So I chose another route.
A Fedora Live USB.
And then the real fun began.
USB HDD/ USB FDD / USB CD / USB ZIP
Different boot modes.
Different BIOS settings.
Reboots.
More reboots.
Even more reboots.
Eventually Fedora Live booted successfully.
<hr>
<h1>First Rule of Data Recovery:</h1>
<h2>Stop Trusting The Original Drive</h2>
One of the most important lessons in recovery:
If a drive might be failing, stop working directly on it.
Every read operation could be its last.
So before touching any files, I created a complete raw image of the disk.
A sector-by-sector clone.
500GB.
About five hours.
The image was stored on a newer 4TB external drive.
This single decision may have saved the entire recovery effort.
If the original hardware failed afterwards, I would still have the image.
<hr>
<h1>The VirtualBox Rabbit Hole</h1>
Now I had an image.
The next challenge was accessing it.
I thought:
“Easy. Convert image. Create virtual machine. Mount. Done.”
Famous last words.
<hr>
<h2>Converting RAW to VDI</h2>
Several commands failed.
Documentation disagreed with reality.
Eventually one conversion started working, then Windows decided to unmount the USB device halfway through.
The conversion died.
Back to square one.
<hr>
<h1>The Breakthrough</h1>
After hours of frustration, I stopped trying to be clever.
I went lower level.
Old-school Linux style.
<h3>fdisk</h3>
I ran:
<pre><code>fdisk -l disk.img
</code></pre>
And there they were.
Four partitions.
Exactly as I remembered.
<ul>
<li>Documents</li>
<li>Music</li>
<li>Movies</li>
<li>Photos &amp; Videos</li>
</ul>
My heart rate increased.
This was the first real sign that the data might still exist.
<hr>
<h1>Loopback Mounting Saved The Day</h1>
Using the partition offset information:
<pre><code>offset = start_sector × 512
</code></pre>
I mounted the partition directly:
<pre><code>losetup
mount -o loop,offset=...
</code></pre>
And suddenly…
There it was.
Directories.
Files.
Photos.
Videos.
Documents.
Years of my digital history staring back at me.
I cannot describe the relief.
Anyone who has recovered “lost forever” data will understand that feeling.
<hr>
<h1>New Problem: Where Do I Put 260GB Of Recovered Data?</h1>
Finding the data was only half the battle.
The largest folder alone was about 260GB.
My recovery VM had only a 20GB virtual disk.
My laptop SSD was already half full.
Storage had become the new bottleneck.
A classic engineering problem:
<blockquote>
Recovery succeeded.
</blockquote>
<blockquote></blockquote>
<blockquote>
Now logistics fail.
</blockquote>
<hr>
<h1>Death By Chrome Cache</h1>
During recovery I discovered something amusing.
And infuriating.
Millions of tiny Google Chrome cache files.
Gigabytes and gigabytes of useless cache data.
Copy operations crawled.
Filesystem operations became painfully slow.
Eventually I removed unnecessary hidden cache directories and focused only on valuable data.
Lesson learned:
Your browser cache probably occupies more space than your important documents.
<hr>
<h1>CrowdStrike Strikes Back</h1>
Just when things were progressing…
Another surprise.
After nearly three hours of copying, Windows security software intervened.
The USB device disappeared.
VirtualBox crashed.
Recovery stopped.
Again.
I restarted.
Checked the destination.
Thankfully many files had already copied successfully.
But I needed a more resilient strategy.
<hr>
<h1>The Network Copy Strategy</h1>
Instead of copying locally through multiple layers of virtualization and USB mounting, I decided to use the network.
The destination drive was connected to my Raspberry Pi.
The Raspberry Pi had power backup.
The laptop had battery backup.
This architecture suddenly looked much safer.
<hr>
<h2>Option 1: rsync</h2>
The reliable veteran.
<pre><code>rsync -avh --progress source/ destination/
</code></pre>
Pros:
<ul>
<li>Resumable</li>
<li>Reliable</li>
<li>Easy verification</li>
</ul>
Cons:
<ul>
<li>Extra file-level overhead</li>
</ul>
<hr>
<h2>Option 2: Tar Streaming</h2>
The speed-focused approach.
<pre><code>tar -cf - source \
| pv \
| ssh user@host \
&quot;tar -xf - -C destination&quot;
</code></pre>
Pros:
<ul>
<li>Continuous streaming</li>
<li>Less file-open/file-close overhead</li>
<li>No intermediate archive creation</li>
<li>Often faster for millions of small files</li>
</ul>
Cons:
<ul>
<li>Interrupted transfers cannot resume cleanly</li>
</ul>
<hr>
<h1>The Hybrid Solution</h1>
Why choose?
Use both.
<ol>
<li>Stream bulk data using tar.</li>
<li>Verify with rsync.</li>
<li>Use checksums where necessary.</li>
<li>Let rsync identify incomplete or corrupted files.</li>
<li>Recover only the missing pieces.</li>
</ol>
This combines performance and reliability.
Exactly what recovery operations need.
<hr>
<h1>What This Experience Taught Me</h1>
If you’ve read this far, learn from my mistakes.
<h3>1. A backup you never test is not a backup.</h3>
<h3>2. One copy is not a backup.</h3>
<h3>3. External drives fail silently.</h3>
<h3>4. Create disk images before recovery.</h3>
<h3>5. Linux remains one of the greatest recovery platforms ever created.</h3>
<h3>6. Your memories are worth more than your hardware.</h3>
<hr>
<h1>The Real Cost Of Data Loss</h1>
People often think backups are about files.
They’re not.
They’re about memories.
The photo you forgot existed.
The video of your child when they were two.
The project you spent months building.
The document you may need years later.
The cost isn’t measured in gigabytes.
It’s measured in moments.
<hr>
<h1>Your Turn</h1>
I have a question for everyone reading this:
What is the closest you’ve ever come to losing your data forever?
<ul>
<li>Failed SSD?</li>
<li>Accidental format?</li>
<li>Ransomware?</li>
<li>Cloud sync disaster?</li>
<li>Dead NAS?</li>
</ul>
Share your horror story in the comments.
And before you do…
Go check your backups.
Right now.
Not tomorrow.
Not next weekend.
Today.
Because somewhere, at this very moment, a hard drive is quietly preparing to ruin someone’s day.

Austin Cross

A personal account of recovering years of family photos, videos, and documents from a failing hard drive. The author walks through the full recovery process: hardware troubleshooting with a Raspberry Pi, booting a Fedora Live USB, creating a raw sector-by-sector disk image before touching any files, using fdisk to identify partitions, and loopback-mounting EXT4 partitions to access the data. Additional challenges included Chrome cache bloat slowing file operations, Windows security software interrupting transfers, and storage logistics for 260GB of recovered data. The solution involved a hybrid rsync and tar-over-SSH streaming strategy via a Raspberry Pi with power backup. Key lessons: always test backups, one copy is not a backup, create disk images before recovery attempts, and Linux is an excellent recovery platform.

My precious data - The Day I Lost My Digital Life