SATA, SAS, HBAs, Backplanes, BIOS, & >2TB HDDs

[peterblaise]

Instead, drive manufacturers put self-recovery into their firmware, even
Seagate decommissioning heads, where heads or platters become
useless, leaving the rest of the drive to continue without needing
service.

The point is to not need service.

And, as BackBlaze shows, swapping is the fastest and least expensive
service.

HOWEVER, what you are describing is exactly what SpinRite is all
about - legacy systems that can't self-heal.

THAT is SpinRite's target, as far as I can see.

Works for me.

So get yourself a legacy system, and SpinRite away!

;-)

 

[pau13z]

Cable secured! Testing will proceed upon arrival

So this will be a backplane with SAS and SATA drives installed attached directly to a server system board.

To be clear, I don't imagine that the AHCI controller will be able to handle the SAS drives, but they'll be in there as a test.

Public holidays Friday this week and Monday next week, but I'm hoping the cable arrives on Tuesday next week.

 

[cschuber]

SpinRite does not directly support RAID or HBAs. To get the best results you'll need to connect the drives to a SATA controller.

What I typically do at home is use tools like ddrescue and dd_rescue. The server can be up doing other work while the drive is being remediated. All my drives are mirrored. I run a FreeBSD shop at home.

At $JOB at the first sign of drive errors we replace the drive immediately. Again all internal drives are mirrored. The servers stay up while internal drives are replaced. Internal disks are boot disks. SAN disks are used for customer data. They're managed by our Enterprise Storage group. And, they present arbitrary LUNs to servers. I don't know what the physical geometry of the underlying disks are but it is certainly different from the LUN geometry presented to the servers.

Why do I recover disks in a mirrored configuration? I'm cheap. Once they become unstable enough they become play drives for various projects. But professionally, we are not cheap. We don't mess with drives that show any hint of errors. They're immediately replaced. Old drives are drilled on a drill press then shredded. All serial numbers are tracked to final disposition.

 

[peterblaise]

"... Old drives are drilled on a drill press then shredded ..."​

Breaks my heart.

Why not offer at least the circuit cards to data recovery centers?

Why not 'certify' the drives are wiped - more expensive, time-wise,
but resale may become a side-cash bonus, especially in a time of
drive rarity, scarcity, and rising prices?

I appreciate that a drive wipe and confirm takes time, but it's really
only start, check, and end for the operator; they go away between
steps.

Isn't there a used drive reseller who will do the cleanup, read/write
check, and resale, you just provide wiped drives?

Even selling direct on eBay as non-returnable sales at 50% of the
guaranteed refurb value that refurb places sell drives for would be a
bonus for you and for us.

- - - - -

Do the shreds at least go to materials recyclers?

You know to divide the shreds into separate containers, separated by
place and time, and the different ultimate destinations of disposal,
right, so no one can reassemble anything from only 1/2 or fewer of
the pieces.

Oy, I'm advising on how to shred when I hate shredding!

=8^o

 

[pau13z]

While waiting for the cable and out of curiosity, what do you guys recommend RE tools to wipe drives that will pass certification testing?

Also I never thought about it, but agree that those circuit boards could be invaluable for recovery efforts, as well as other internal components, providing there's nothing on them that could compromise security.

 

[peterblaise]

I have a BIOS that has a SE Secure Erase option built in, quite fast, and
there's nothing left on the drive via the IO connections.

Others may claim the platters themselves might still contain data, just
unreferenceable, yet even after repartitioning and inspecting sector
by sector, I see nothing.

The head rack might be useful, and it's parked off the disks, so it's
possible to pull just the disks and bulk-erase them and put them back
in so the drive 'runs' but doesn't even have factory spiral recordings
- frustrating for anyone who thinks, "hey, a good drive, it spins, why
does it not show up as a data storage device?"

But the platters are a terrific spare for drive rebuilders, and they can
write whatever they want to them using Seagate and other proprietary
controllers.

Has anyone demagnetized an assembled drive and then tested for
data?

Google says:

To securely wipe a modern assembled hard drive (HDD), a ​

demagnetizer (degausser) must produce a magnetic field of at ​

least 10,000 to 20,000 Gauss (1 to 2 Tesla). ​

https://share.google/aimode/orHNZMDmXXl3MugOo​

But if you can leave a drive in a spare mule PC and let any wiping
program wipe and conform and print a receipt, then the drive will
be useful, and whoever gets it can address why it was pulled.

On the one hand, I realize data and indemnification against data loss
and law suits are paramount.

On the other hand - Oh look, SPARES!

 

[cschuber]

"... Old drives are drilled on a drill press then shredded ..."​

Breaks my heart.

Why not offer at least the circuit cards to data recovery centers?

Why not 'certify' the drives are wiped - more expensive, time-wise,
but resale may become a side-cash bonus, especially in a time of
drive rarity, scarcity, and rising prices?

It's a secure datacentre. Under typical circumstances at less secure installations hardware vendors replace dead drives and return them. Maybe to refurbish them. Maybe to dispose of them. My client pays the extra to keep the drives.

Wiping drives is expensive. That may take a part of or maybe even a full FTE (full time employee). "Wiping" may not wipe them.

I maintain the security/bcwipe port/package for FreeBSD. Yeah, it's thorough but a) the drive must still be functional and b) it takes days to week to perform the 35-pass Peter Gutmann's wiping. German BCI/VSITR 7-pass wiping, U.S. DoD 5220.22M 7-pass, and other passes are not as thorough. But, (a) above, the drive must be functional. Not all of them are. It's simpler to destroy the drive in a shredder.

I appreciate that a drive wipe and confirm takes time, but it's really
only start, check, and end for the operator; they go away between
steps.

Isn't there a used drive reseller who will do the cleanup, read/write
check, and resale, you just provide wiped drives?

No. Would you trust some random reseller to wipe drives? I certainly wouldn't.

Even selling direct on eBay as non-returnable sales at 50% of the
guaranteed refurb value that refurb places sell drives for would be a
bonus for you and for us.

- - - - -

Do the shreds at least go to materials recyclers?

You know to divide the shreds into separate containers, separated by
place and time, and the different ultimate destinations of disposal,
right, so no one can reassemble anything from only 1/2 or fewer of
the pieces.

I don't know the process except that the drives are drilled first. Then shredded.

I doubt that even the NSA could piece together any data from a shredded disk.

Oy, I'm advising on how to shred when I hate shredding!

=8^o

As Steve says, TNO: Trust No One. Trusting some random reseller to ensure drives are wiped after they leave a secure facility is utter foolishness. But remember, these drives are failing drives. Or, completely failed drives. There's nothing to save. But the risk is still a risk.

Personally, I may pop a marginal drive into a USB enclosure or into my sandbox machine in my basement to let ddrescue or dd_rescue spin through the drive while the machine is working on something else for me. If I can repurpose it for a while, fine. If not, it was already replaced by a cache of drives I have in a drawer here. But at $JOB they don't mess with anything.

While on the topic, one thing I found that does help spare disks and to a lesser extent SSDs, is lots of RAM. I can't say for Windows but UNIX (Solaris, FreeBSD, Linux) will use RAM that is not used for apps as buffer cache. Eliminating reads from external media (disks and SSDs) reduces their wear and it improves performance. Some of my large memory machines can see cache hit rates in the 98% or higher range, even hitting 100% cache hit ratios for periods of time. Fetching data from cache instead of disk/SSD will improve performance manyfold. More RAM is always a good investment.

 

[peterblaise]

"... Isn't there a used drive reseller who will do the cleanup,
read/write check, and resale, you just provide wiped drives? ..."​

​

"... No. Would you trust some random reseller to wipe drives? I
certainly wouldn't ..."​

"Clean up" is R&Ring the circuit card, cleaning the contacts, and
cleaning the housing with Windex before affixing a [ Refurb ] label.

As I wrote, "wipe" the platters via program through the IO ports
before handing off the drives, but because the sale is B2B, not retail,
no further cleanup is needed.

I presume refurb shops already buy wiped drives from server farms,
and do the connector cleanup, write/read recertification, and other
prep for resale.

No one considered at least removing the circuit cards and offering
them to the market?

I guess the value to them is not value enough.

- - - - -

"... divide the shreds into separate containers, separated by place
and time, and the different ultimate destinations of disposal, right,
so no one can reassemble anything from only 1/2 or fewer of the
pieces ..."​

"... I doubt that even the NSA could piece together any data from
a shredded disk ..."​

That begs the question: has anyone scientifically investigated wipe
results or shredded results, especially non-wiped shreds?

How small are the pieces versus how small is the data?

"... A 2mm fragment can hold roughly 22.49 GB of data, which is ​

potentially retrievable using microscopes ... advanced degaussing, ​

is considered irreversible ..."​

https://share.google/aimode/AW3FOVfhjoukz80Hs​

- - - - -

I am familiar with retention policies, especially for proprietary data.

My primary goal is repurposing, especially with the increasing rarity
( there's a phrase ! ) of drives.

Essentially saying, "We're aware that our policy of denying
repurposing is wasteful, but we have a superior priority".

All things in balance.

Good side-discussion while we wait ...

- - - - -

I await the report on making SATA drives accessible to Spinrite.

I hope we helped.

 

[pau13z]

I just hope that the part is delivered early enough in the day for me to fit it before the end of the day, because while I can remote in from home to check the status as it trots along, I'm on leave after that for a week and a half, and I don't want to be left hanging, or leave anyone else hanging haha.

RE the HDD circuit boards, we'd need to look into the statement of volatility for those devices to make sure nothing sensitive could be stored in memory on the boards.

There are some cases where data destruction literally means... "Data Destruction". In those cases, I'm not going to question it, because you're normally talking about police, federal, or military applications. I can also worry about businesses worrying about their data getting out there, but they can do wipes internally first, or use encryption.

But for critical data recovery, I have no doubt that businesses out there would love cheap, readily available access to motors, heads, circuit boards, housings, etc. from drives that were in a good state but posed no risk data leakage.

 

[peterblaise]

Q: Google, do hard drive vendors or tha ATA specification have their ​

own drive data wipe routines that are 100% verified and verifiable?​

​

A: [ in part ] ... ATA Secure Erase is the standard for secure ​

sanitization, but for critical data ... perform a post-erasure audit ​

scan ... ​

​

https://share.google/aimode/AzmdtRcS3hSb5heGo​

- - - - -

... and if the drive is unable to function, pull the platters.

Q: Google, do hard drive controller circuit cards contain user data ​

after power cycling?​

​

A: [ in part ] ... No ...​

​

https://share.google/aimode/YYi3QNUTP2ctmBg0o​

​

Get a written "no" from each vendor.

- - - - -

Let us know what you do.

Thanks.

 

[jlee]

Ambitious, I know... However, I thought I'd ask...

I've got access to servers that have RAID controllers in HBA mode that are connected to backplanes with up to 12 x 3.5" or 24 x 2.5" HDD's which could be SAS, SATA, or NVMe, and with capacities that can exceed 20TB.

If this is a redundant RAID configuration, I wouldn't run SpinRite on the drives at all. The RAID controllers should take care of fixing any bad sectors they find by generating the correct data from the redundancy and then writing it to the drive with the bad sector. This forces a reassign of the bad sector, which is all SpinRite does when it discovers a bad sector. But make sure the drives are being used in a redundant configuration.

Many RAID controllers also have a background utility which scans all the drive surfaces in the background and fixes any bad sectors it finds. This would be the same as SpinRite running a level 2. If your primary goal is to find and fix any bad sectors, there's no need to use something like SpinRite level 5.

 

[pau13z]

If this is a redundant RAID configuration, I wouldn't run ,SpinRite on the drives at all. The RAID controllers should take care of fixing any bad sectors they find by generating the correct data from the redundancy and then writing it to the drive with the bad sector. This forces a reassign of the bad sector, which is all SpinRite does when it discovers a bad sector. But make sure the drives are being used in a redundant configuration.

Many RAID controllers also have a background utility which scans all the drive surfaces in the background and fixes any bad sectors it finds. This would be the same as SpinRite running a level 2. If your primary goal is to find and fix any bad sectors, there's no need to use something like SpinRite level 5.

The drives aren't part of a RAID array, though I'd imagine that if they were, SpinRite would work harder than the LSI Patrol Read function at trying to recover data.

I don't know (because I've never tested it), but I'd also imagine that if you changed the config of the controller from RAID to HBA, without destroying the RAID configuration DDF data stored on each of the RAID drives, that you could then run SpinRite on the drives, before reverting back to the RAID configuration and importing the config from the drives, bringing the array and VDs back online. At that point you can run a consistency check that would attempt to rewrite any inconsistent data caused by SpinRite determining that a block may not have been recoverable. But again, never tested, not advice.

 

[PHolder]

SpinRite would work harder than the LSI Patrol Read function at trying to recover data.

If it's parity based RAID (and there are few other choices that are common, except maybe something like file based which I think UnRAID might use) then it's not going to try hard to read a failed sector at all. Where you'd be screwed, is if there was the same bad LBA on multiple drives at once. RAID-5 can correct for one failed copy of the LBA, RAID-6 can correct for two failed copies. So literally the second the drive hesitates to do its thing, the RAID should immediately go "ouch, activate recover mode now" and do the parity calculations and try to rewrite the data in place and re-read it. If that worked, it will likely up a counter somewhere, and log the event, but that should be the end of it. If it doesn't work, then some NAS type systems might have the ability to relocate data in the file system, and then you're still recovered, but you're going to hear a loud and clear signal from the NAS that it's not happy, and you should order replacement drives post haste.

TL;DR: SpinRite is basically incompatible with NAS/RAID. You shouldn't ever rely on it for HDD device management, you should use the in-built NAS features in every case. If the NAS gives up, then MAYBE you could try SpinRite, but as NAS/RAID IS NOT A BACKUP, you would generally recover from your backups and install new drive(s) in your NAS.

 

[pau13z]

I can't speak to all RAID controllers, but in the case of something that's LSI based and has a Patrol Read or similar function, as I understand it, SpinRite could be useful in certain cases.

The primary limiting factors would be the drives being behind the RAID controller, possibly being SAS, and the system possibly only supporting UEFI boot. If those hurdles can be overcome by means of software or physical changes to the hardware, use cases in which I can see that SpinRite might be useful include:

1. If you don't have a backup, and if your RAID array lacks redundancy and data can't be read from the primary or redundant location, as determined by the drive and/or controller algorithms and recovery mechanisms. In that case, the array would fail. While the most recently failed drive could be forced online to try to recover some data, you may have lost access to at least some data.

In that case, SpinRite could be utilised to read and recover the data that previously couldn't be read. If that data could be recovered, then while the array may still end up in a degraded state, the remaining data on the drives might be that much more resilient, especially if the magnetic readability of that data has been made more robust, and is more likely to survive a backup attempt or redundant drive rebuild.

2. If drives are reporting unrecoverable medium errors, particularly 3/11/00 and 3/11/01, and data is regularly being restored from redundant locations, if the cause of those medium errors relates to degradation of magnetic readability, then the array speed, reliability, and resiliency could be renewed by running SpinRite on those drives.

 

[pau13z]

OK, so, update!

Cable installed, SAS HDD's connected to the backplane aren't seen, but SATA drives are. This is a limitation of the system, they're not seen at a system level.

The drives that are showing up are reporting speeds of up to approx. 280MB/s. Time's still a factor, but I accept that it may be a limitation of the drive. Any insight based off drive details, protocols, and features below would be appreciated.

I'm curious about this ECC corrected margin under the SMART page, I've seen it fluctuate up and down a little. If anyone can explain that to me I'd appreciate it, though I'll look into it more myself when I get a chance.

An old system I was made aware of includes a software controller that can handle both SAS and SATA drives, I'm curious as to how the drives might show up connected to one of those, but I don't have access to one of those, they're too old. I'd Imagine though that it might be similar to HBA's, in that they get passed to BIOS as a BIOS drive, and if SpinRite can see anything, it would be the "BIOS" drive. But I'll keep my eye out and see what else I can find/figure out!

 

[DanR]

The drives that are showing up are reporting speeds of up to approx. 280MB/s. Time's still a factor, but I accept that it may be a limitation of the drive

Correct. The controller is indicated as SATA 3. The drives are operating at their full speed. 20 TB is a lot of space to scan.

I'm curious about this ECC corrected margin under the SMART page

This is not a problem. This is a Seagate drive. Seagate uses the SMART attribute ECC Corrected for something else entirely. What that is, is proprietary to Seagate. It is normal for Seagate drives to generate large numbers for this attribute. You may ignore them. SpinRite seems to.

 

[peterblaise]

All's going well EXCEPT you are not verifying writes, which only Level 4
and 5 do, nor are you testing with a known pattern, which only Level 5
does.

Level 3 'trusts' the drive when the drive says, "OK, I wrote that. Next?",
and then SpinRite moves on without verifying anything on it's own.

Level 4 verifies.

Level 5 writes a test, reads it back, and compares, then rewrites the
original data and compares.

If we're gonna test a drive for what it has to do FOR US, then verifying
outside the drive seems essential.

The drive verifying for itself inside the drive seems useless,
considering the data is only useful to us when the data is actually
confirmable for accuracy and use outside the drive.

Just saying.

I run SpinRite Level 5 or equivalent on all storage, even my Kindles.

- - - - -

Yes, SMART outside the drive is STUPID, always has been.

I've got dying and dead drives with no SMART errors, and I've got live,
long-lived, reliable drives with SMART "drop dead" errors broadcast
to the boot screen - go figure.

- - - - -

What did you use to capture and share the SpinRite screen grabs?

Many of us use PS Print Screen from our own @Paul F - the 'final'
version 1.0.3 attached below, unzip it and run with /? for instructions
and options - thank you, Paul, it's an absolute treasure and delight
to use.

Note, in free IrfanView, with no loss in SpinRite's original colors or
clarity, we can drop the colors to 256, 128, 64, 32, or even 16 colors,
depending on the image ( compare and undo if information gets
lost ) and resize to 640 x 400 pixels, and save as PNG, especially
using IrfanView's OptiPNG PlugIn to create the smallest, most easily
shareable and uploadable images.

- - - - -

Thanks for following up with the initial success of connecting your
drives to SpinRite.

Now to see the final results.

Wanna have SpinRite check those SAS drives via BIOS? ;-)

I'll check my own and see what I can muster and get back to you all.

.

 

[JimB]

Already got several of each! Most of the time for enterprise though we'll use remote management facilities built into the systems to connect, like the iDRAC.

So if I can get one system configured to run up to 8 drives say over a weekend, that'd be great, set and forget, but if I needed to do one individually, I'd need to see if I can reconfigure a 2nd system so I don't need to cancel any existing tests.

Or how about a bunch of SBCs....gets expensive tho. My AI suggested this....


[Moderator note: Most AI's don't understand whether a device supports legacy booting or not. SpinRite requires legacy booting as 6.1 CANNOT boot via UEFI. Please confirm any device you contemplate using with SpinRite has a CSM and can perform a legacy boot.]


The ZimaBlade (also known as the current ZimaBoard variant) at ~$69 for the base Blade 3760 model is the cheapest current x86 SBC that directly meets your exact needs: native SATA connector(s) + FreeDOS + SpinRite for disk checking.

Why This Fits PerfectlyNative SATA (exactly what you asked for): It has 2x SATA 6 Gb/s ports (with power delivery via a simple included/cheap Y-cable in bundles). You only need one for your test drive—plug in any 2.5"/3.5" SATA HDD/SSD directly. No adapters, USB bridges, or M.2 hacks required. SpinRite gets full low-level hardware access in AHCI mode (which these boards support).

Pure x86 for bare-metal FreeDOS/SpinRite: Intel Celeron N3760 (quad-core, low-power) or the step-up 7700 model. Full legacy BIOS/CSM boot support, so FreeDOS boots from USB exactly like on any old PC. SpinRite 6.x runs flawlessly on modern SATA controllers like this (confirmed across similar N-series boards).

Cheap and current (2026 pricing): Base board is $69. Add ~$15 for an 8GB DDR3L SODIMM (required, not soldered) + ~$10 for a 12V USB-C power adapter = under $100 total for a complete working unit. Bundles (RAM + adapter + SATA Y-cable + case options) are ~$115–$165 and often discounted.

Compact & low-power: True single-board form factor, fanless-capable, ~6W TDP idle. Ideal for dedicated “SpinRite box” duty—leave it running 24/7 checking drives without much electricity or heat.

(The Radxa X4 I mentioned earlier is cheaper overall but has no native SATA—only M.2 NVMe + optional add-on adapters with power complications—so it doesn’t meet your “one SATA connector” requirement.)Headless Operation (The “Something Else” Part)SpinRite is an interactive, full-screen text-mode DOS tool with menus and real-time progress maps—you can’t easily script or fully automate it over a network in pure FreeDOS. There’s no built-in SSH/VNC/etc.Serial console route: Not practical here. The ZimaBlade has no native COM/serial port (common on these modern low-cost x86 SBCs). You could add a PCIe or USB serial card, but FreeDOS redirection (CTTY COM1) works only for basic command-line stuff—SpinRite’s UI doesn’t translate cleanly over serial.
KVM route (the reliable, recommended solution): Exactly as you noted. Add a cheap HDMI/USB KVM-over-IP device (~$30–$80, e.g., generic USB-C/HDMI capture units or a PiKVM-style setup). Plug the ZimaBlade’s Mini DisplayPort (use cheap HDMI adapter) into the KVM’s video input.
Plug one USB port into the KVM’s keyboard/mouse emulation.
Access the entire SpinRite session remotely from any browser/computer on your network (full screen, keyboard control, even mouse if you want).
This keeps the whole setup truly headless after initial BIOS/FreeDOS USB boot—no monitor or keyboard ever attached during normal use.
Total added cost for headless is low, and it’s far simpler than trying to hack serial or run SpinRite in a VM (which defeats the bare-metal disk-testing purpose).Quick Setup for Exclusive SpinRite UseAssemble (board + RAM + power).
Boot FreeDOS from a USB stick (Rufus + official FreeDOS image; enable legacy/CSM in BIOS if needed).
Set SATA mode to AHCI in BIOS.
Attach your target drive to one SATA port.
Run SpinRite (copy it to the FreeDOS USB or the drive itself).
Control everything via the KVM-over-IP from another machine.

This gives you a dedicated, low-cost, reliable SpinRite disk-checker that’s purpose-built for the job without any extra OS overhead. The ZimaBlade 3760 at $69 is the clear winner right now for price + native SATA + x86 compatibility. If you want the slightly faster 7700 model or a pre-bundled kit, it’s still very affordable.

 

[Tazz]

The ZimaBlade (also known as the current ZimaBoard variant) at ~$69 for the base Blade 3760 model is the cheapest current x86 SBC that directly meets your exact needs: native SATA connector(s) + FreeDOS + SpinRite for disk checking.

Why This Fits PerfectlyNative SATA (exactly what you asked for): It has 2x SATA 6 Gb/s ports (with power delivery via a simple included/cheap Y-cable in bundles). You only need one for your test drive—plug in any 2.5"/3.5" SATA HDD/SSD directly. No adapters, USB bridges, or M.2 hacks required. SpinRite gets full low-level hardware access in AHCI mode (which these boards support).

One thing to note, the ZimaBlade only has one USB port. To be able to boot from USB and attach a USB keyboard you will need either:
1) A PCIe adapter, that they happen to sell. I found the same thing on Amazon for a little cheaper.
or
2) A USB-C multiport adapter/dock. Like this one.

Also to note, the included USB wall wart plug in charger is non-standard and only supplies 12v. There's no device negotiating, whatever you plug in to it will get 12v.

 

[pau13z]

@DanR thanks for confirming! And that's interesting about how Seagate utilise SMART... And frustrating haha!

@peterblaise good point about testing the drives and levels, I should change that!

RE screenshots, I'm using a virtual console built into the server, a lot of enterprise solutions have these virtual KVMs. For HP it's called iLo, for Dell it's called iDRAC. From the virtual console there's a screenshot button, so you get a nice crisp image.

@JimB thanks for the suggestions! At the moment I'm trying to work within the enterprise framework and infrastructure I have, but for sure that sounds like a good backup alternative!