HDD Burn-In Testing: Vet a New Drive Before RAID
· Last verified July 2026
You just bought a shiny new NAS drive (or three) and the temptation is to slot them in, build the array, and start copying your photos over the same afternoon. It's worth pausing for a couple of days first, because a small but real fraction of drives arrive with defects from the factory or take a beating in shipping, and the cheapest moment to discover that is before any data lives on the disk. This guide walks through a burn-in that a first-time NAS owner can actually follow: what the tools do, how long they take, and exactly which numbers tell you whether the drive is good.
Why burn-in matters even for a brand-new drive
Hard drives don't fail at a steady rate over their life; they follow what reliability engineers call the bathtub curve: a relatively high failure rate in the first few weeks, a long flat plateau through the middle years, and a rising rate again once the drive is old. That early bump has a name, infant mortality, and it comes from the same handful of causes every time: a marginal head or platter that slipped through factory testing, a solder joint cracked by a rough courier, or a controller flaw that only shows up under sustained load. Because those defects have nothing to do with brand prestige, a burn-in matters just as much on a premium WD Red Pro as on a bargain drive.
Backblaze, which runs hundreds of thousands of drives and publishes the numbers, has written about exactly this pattern in its analysis of how long disk drives last, where a noticeable share of lifetime failures cluster in a drive's first year rather than being spread evenly across it. The practical reading for a home builder is simple: a drive that survives a hard couple of days of writing and reading has effectively skipped past the riskiest part of its life, and you can trust it with data far more confidently than one straight out of the anti-static bag. If it's going to die young, you want it to die during the test, while the disk is empty and still inside the return window.
The tools: badblocks and smartctl, in plain terms
Two free Linux tools do almost all of the work, and you don't need to be a sysadmin to run them. The first is badblocks, which reads and writes every single sector on the drive looking for blocks that won't hold data reliably, so it stresses the whole platter surface the way months of normal use eventually would. The second is smartctl, part of the smartmontools package, which talks to the drive's own SMART system, the built-in self-monitoring that every modern drive keeps, to trigger the firmware's own self-tests and read back its internal health counters.
You can run both from almost any Linux environment: a spare desktop with the drive connected over SATA, a live Ubuntu USB stick booted on any PC, or the shell of a NAS OS. On Debian or Ubuntu the packages install with apt install smartmontools e2fsprogs, and badblocks ships inside e2fsprogs. The one habit worth building from the start is to identify the drive by its serial number, not just its /dev/sdX letter, because those letters can reshuffle between reboots and you never want to run a destructive test against the wrong disk; smartctl -i /dev/sdX prints the model and serial so you can confirm you're pointed at the new drive and not the one holding your data.
Step 1: run badblocks in destructive write mode
The strongest single test is a full destructive write-read pass, which you launch with badblocks -wsv /dev/sdX. The -w flag is write-mode: it writes four different bit patterns across the entire device and reads each one back to confirm it survived, so every sector is exercised for both writing and reading. The -s flag shows progress and -v prints any bad blocks it finds. The badblocks documentation spells out that the write-mode test lays down four separate patterns over the whole drive, which is why it's such a thorough surface exercise.
There is one warning that cannot be overstated, and it's the reason people get burned: the -w mode erases the drive completely. It's designed for a brand-new empty disk or one you've already backed up elsewhere; run it against a drive that holds data and that data is gone with no undo. If the disk you want to test already contains files you can't lose, use the non-destructive read-write mode instead, badblocks -nsv /dev/sdX, which backs up each block's contents, tests it, and restores it, at the cost of running considerably slower. For a fresh drive going into a new array, though, the destructive -w pass is the one you want, because it's the closest thing to a factory-grade surface test you can run at home.
How long badblocks actually takes
This is where people panic and assume something is broken, so it helps to do the arithmetic up front rather than guess. A modern 7200 RPM NAS drive sustains somewhere around 200 MB/s on sequential transfers, and badblocks -w has to write the whole drive four times and read it back four times: eight full surface passes in total. One pass over a 16 TB drive is 16,000,000 MB ÷ 200 MB/s ≈ 80,000 seconds, or about 22 hours, so the full eight-pass run lands near 7 days. A 4 TB drive is roughly a quarter of that, so plan on closer to a day and a half; an 8 TB drive sits in the middle at three to four days.
Those are back-of-envelope figures; real throughput sags toward the inner tracks of the platter, so the second half of every pass runs slower than the first, and the true total often stretches 10-20% beyond the simple calculation. The takeaway is that a multi-day badblocks run is completely normal and not a sign of a slow or failing drive. If you don't want to babysit a terminal for a week, run it inside a tmux or screen session, or on a NAS OS use the built-in extended surface test, which does the same job through the web UI without an open SSH connection.
Step 2: run a SMART long self-test
Once the surface pass is done, hand the drive its own internal exam. Every modern drive can run three built-in self-tests, and each has a different scope: the short test takes a couple of minutes and checks the electronics and a small sample of the surface, the conveyance test is a quick check aimed specifically at damage from shipping and handling, and the long (extended) test reads the entire surface and is the one that matters for burn-in. You start it with smartctl -t long /dev/sdX, and the command immediately tells you the estimated completion time, usually a number of hours in the same ballpark as a single badblocks pass, since it too has to scan the whole platter.
The self-test runs inside the drive's own firmware, so you can check on it with smartctl -a /dev/sdX and look at the self-test log at the bottom of the output. What you want to see is a line reading "Completed without error" at 100%; anything that reports a read failure at a specific LBA means the firmware found a sector it couldn't read cleanly, which on a new drive is a clear return signal. Running the long test after badblocks is a useful belt-and-suspenders step because the two tools catch slightly different problems: badblocks stresses writes and the filesystem-visible surface, while the SMART long test is the drive's own view of its media and mechanics.
Step 3: read the SMART attributes that actually matter
The final step is the one that separates a confident "this drive is good" from a hopeful guess, and it takes about thirty seconds. Run smartctl -A /dev/sdX to dump the attribute table, then ignore the dozens of vendor-specific rows and focus on four counters that carry almost all of the signal. These are the numbers to check on a freshly burned-in drive:
- Reallocated_Sector_Ct (ID 05): sectors the drive found bad and swapped out for spares. On a brand-new drive this should be zero; any reallocations that appeared during your write pass mean the surface is already shedding sectors.
- Current_Pending_Sector (ID C5 / 197): sectors the drive suspects are bad and is waiting to reallocate. Should be zero; a pending count that shows up during burn-in and doesn't clear is a bad sign.
- Reported_Uncorrect / Offline_Uncorrectable (ID C7 / 198): read errors the drive's own error correction could not recover. Should be zero on a healthy new drive.
- UDMA_CRC_Error_Count (ID 199): interface errors between the drive and the controller, almost always a loose or bad SATA cable rather than the drive itself. A rising count here means reseat or replace the cable before you blame the disk.
The mental model that keeps you from overreacting is straightforward: the media counters (05, C5, C7) should read a flat zero on a new drive after a full write pass, and any movement is a reason to return it, while a CRC count (199) points at cabling and is usually fixed with a new SATA lead. The full SMART attribute reference lists what every ID means, but for a burn-in decision these four are the whole story. If all four are zero after badblocks and a clean long test, the drive has earned a spot in your array.
Doing this on a NAS or a live USB (the advanced route)
For the more technical crowd: you don't need a separate PC at all. If you run TrueNAS, you can drop into the shell and run the exact same badblocks and smartctl commands against an unassigned disk before you add it to a pool, and TrueNAS also schedules recurring SMART long tests through its UI once the drive is in service. On Synology and QNAP the equivalent is the extended S.M.A.R.T. test and a full "bad sector" surface scan in Storage Manager, which run the same firmware self-test under a friendlier button. The cleanest option for a drive not yet attached to anything is to boot a live Ubuntu USB on any spare machine, install smartmontools and e2fsprogs into the live session, and burn the drive in there; nothing touches your real system, and you can test several drives in sequence before they ever meet your NAS.
Direct-buy: what to grab if a drive fails burn-in
Recommendation
For a new drive going into a home NAS, the sensible routine is a full badblocks -wsv destructive pass, then smartctl -t long, then a look at attributes 05, C5, C7 and 199, and only if all four read zero do you add the drive to the array. Budget your time realistically: one to two days for a 4 TB drive, three to four for 8 TB, up to a week for 16 TB and above, and run several drives in parallel on different SATA ports if you're building a multi-bay box. If any drive trips a media counter, don't argue with it; return or RMA it while it's empty and in warranty, and drop in a proven replacement like a Seagate IronWolf, WD Red Plus, or WD Red Pro. Burning in a spare drive ahead of time is also the honest argument for keeping a cold spare on the shelf, since a pre-tested drive is one you can trust the moment the array needs it. The two days you spend now are the cheapest insurance your data will ever get.
Related articles
Disk Failure Statistics 2026: What the Data Actually Shows
Refurbished NAS Drives: Bargain or Trap?
Best NAS Hard Drives 2026: Top Picks for Every Budget
SMR vs CMR Drives: Which Is Actually Safe for Your NAS?