Rescue to the softraid

Introduction

So I had this USB Disk attached to my OpenBSD Router used as storage, one saturday when I was walking by I noticed the weird clicking sounds from the disk. So I knew my time was running before the disc would fail.

Curiously, when I plugged the same drive into a Linux box, it was detected — and even showed a valid OpenBSD partition table. That gave me a glimmer of hope: maybe the hardware wasn’t completely dead yet.

So, for fun (and a little bit of stubborn curiosity), I decided to spend the weekend seeing how much I could rescue from it.

This post documents the process — part forensic experiment, part recovery attempt, and part “let’s see what happens if I do this.”

Phase 1: Identifying the Disk under Linux

Before doing anything risky, I wanted to be sure I was imaging the right disk. The idea was to identify the OpenBSD partition and dump it to an image file.

Listing block devices

lsblk -o NAME,SIZE,FSTYPE,TYPE,LABEL,UUID

That gives a good overview — which disks are present, how large they are, and what filesystems they contain. Sure enough, my external USB drive showed up as `/dev/sda`.

Inspecting partition table

sudo fdisk -l /dev/sda

Example output:

Disk /dev/sda: 931.5 GiB, 1000204883968 bytes, 1953525164 sectors
Disk model: External USB 3.0
Sector size: 512 bytes
Disklabel type: dos
Device     Boot Start        End    Sectors   Size Id Type
/dev/sda4  *       64 1953525163 1953525100 931.5G a6 OpenBSD

Perfect. The OpenBSD partition was still there (`/dev/sda4`), and it even reported the correct size.

The Start sector (64) is important later for offset calculations.
Type a6 OpenBSD confirmed the filesystem was OpenBSD-specific (likely softraid).
Knowing the sector size (512 bytes) ensured that later tools like `dd` or `ddrescue` wouldn’t misalign reads.

At this point, the goal was to make a bit-for-bit copy of that partition, compress it, and work on the image rather than risk further damage to the actual disk.

Phase 2: Creating a Compressed Disk Image

For imaging, I decided to use GNU ddrescue — it’s great for flaky disks and can retry sectors intelligently.

Installing ddrescue

On Fedora, installation was trivial:

sudo dnf install ddrescue

First Attempt (Quick and Dirty)

I tried a fast, one-shot dump — not ideal for a failing disk, but I wanted to see if it would work at all:

sudo ddrescue -d -r3 /dev/sda4 - - | xz -T0 -c > openbsd_sda4.img.xz

That command streams data directly from the device, compresses it with xz, and writes the result. It works — if the disk is healthy. Mine wasn’t, so it failed partway through.

Second Attempt (Proper Forensic Mode)

So I switched to the safer, resumable method:

sudo ddrescue -d -r3 /dev/sda4 openbsd_sda4.img openbsd_sda4.log
xz -T0 openbsd_sda4.img
sha256sum openbsd_sda4.img > openbsd_sda4.img.sha256

This time, ddrescue created a detailed log file so I could resume later if the system froze or the disk disconnected. It took most of the night, but eventually I had a clean (or mostly clean) image.

Explanation of parameters

-r3 retries each bad block 3 times
-d enables direct disk I/O
The `.log` file lets you stop and restart without losing progress
xz -T0 uses all CPU cores for compression

After the dump, I verified the output:

ls -lh openbsd_sda4.img.xz
xz -t openbsd_sda4.img.xz   # test integrity
sha256sum openbsd_sda4.img.xz > openbsd_sda4.img.xz.sha256

Everything checked out — a ~450 GB compressed image file safely sitting on my main system.

Phase 3: Simulating Disk Damage (For Fun and Testing)

Since the real disk was unstable, I wanted a safe way to experiment. So I created a copy of the image and simulated damage to practice recovery techniques.

Creating the test image

sudo dd if=/dev/sda4 of=openbsd_sda4.img bs=4M status=progress

Simulating corruption

To emulate bad sectors:

dd if=/dev/zero of=openbsd_sda4.img bs=512 count=10 seek=1000 conv=notrunc

Now the image contained 10 intentionally corrupted sectors — perfect for testing.

Recovering from the damaged image

ddrescue -d -r3 openbsd_sda4.img openbsd_sda4_recovered.img openbsd_sda4_recovery.log

And just like that, I could practice recovery without touching the actual hardware again.

Optional Compression

xz -T0 openbsd_sda4.img

It’s amazing how much you can still do with raw disk images and a few classic Unix tools.

Phase 4: Performance Tuning and System Stability

During the rescue, I learned (the hard way) that ddrescue can saturate I/O and make your system lag like crazy. So I ended up using this combination for a gentler approach:

sudo ionice -c2 -n7 nice -n19 ddrescue -b 4096 -B 4096 /dev/sda4 openbsd_sda4.img

And, for long operations, running it inside tmux:

tmux new-session -s rescue
sudo ddrescue -d -r3 /dev/sda4 openbsd_sda4.img openbsd_sda4.log
# Detach with Ctrl-B D

Later, I could simply:

tmux attach -t rescue

That setup saved me more than once when I accidentally closed an SSH session.

Phase 5: Next Steps — Future Analysis

Once I had a full image, the plan was to:

Decompress it (unxz openbsd_sda4.img.xz)
Attach it as a loopback device under Linux, or use vnconfig under OpenBSD
Attempt to reassemble the softraid volume using bioctl
If all goes well — mount the decrypted filesystem and access my old data

That’s a topic for another weekend. But getting to this point already felt like a small victory.

Conclusion

What started as a “let’s see if I can still read this disk” experiment turned into a proper mini-forensics exercise. Even though the original USB drive was dying, I managed to preserve most of its data and learned a ton in the process.

Allover it was quite fun to do something forensics related on a OpenBSD target, I guess it is something you don’t come across everyday but when you do its good to be prepared I think.

Key takeaways:

ddrescue is your friend for unstable media
Always work on images, not the original device
Compression and checksums are cheap insurance
And most importantly: never underestimate what you can recover with a bit of patience and Unix philosophy

Not a bad way to spend a weekend.

Appendix

Device summary

Device: /dev/sda
Partition: /dev/sda4
Size: ~931 GiB
Partition type: a6 (OpenBSD)
Start sector: 64
Sector size: 512 bytes

Estimated time and storage

Depending on USB speed:

Imaging took about 2–3 hours
Compressed image size: ~40–60% of original

Tools used

dd, ddrescue, xz
fdisk, lsblk, sha256sum
tmux, ionice, dstat, iotop