NAS Drive Burn-In Testing: Catch a Bad Drive Early

Two failure modes actually lose people data on a home NAS. One is ransomware. The other is a drive that was already faulty when it arrived. Hard drive failures cluster at the very start of service life and again after roughly five years, and the early cluster is the one you can do something about, because it happens while the drive is still returnable. Burn-in testing is how you move that failure from the moment the array depends on the drive to the week the drive is still a box on your desk.

The regime below is three steps: read the SMART attributes on arrival, run the drive's own long self test, then write and verify every sector with badblocks and run the self test again. It is slow. A full four-pattern run on an 8 TB drive is about 145.8 h, and on a 24 TB drive it is about 350 h, which is 14.6 days of continuous operation. That duration is the real reason people skip it, so there is a shorter defensible version further down.

Why should you burn in a new NAS drive before trusting it?

Burn-in testing is a deliberate, destructive full-surface exercise of a new drive, performed before any real data is on it, to force a marginal drive to fail while it is still replaceable. Nothing about it repairs a drive. Its entire value is in changing when you learn the bad news.

Drive failure over time follows a bathtub shape. A population of new drives shows an elevated failure rate in the first few weeks, settles into a long flat middle where large-fleet annualised failure rates run roughly 1.0 to 1.6 percent per year, then climbs again past about five years of service. That first hump is infant mortality: a head that was misaligned at assembly, a motor bearing that was marginal, a platter defect the factory scan did not provoke, or damage taken in transit between the factory and your desk.

Now consider what happens without testing. You buy four drives, build an array, restore several terabytes onto it, and one drive dies in week three. If you built single parity, the array now has to rebuild by reading every sector of every surviving member, and it has to do that while the other three drives are the same age, from a similar manufacturing run, and have been through the same delivery van. The RAID capacity calculator shows exactly how much data that rebuild has to read for your drive set, and it is a large number. Burn-in moves that same failure to a point where the consequence is a support ticket rather than a rebuild.

Do the burn-in on all the drives at once, in parallel. Testing four drives sequentially takes four times as long as testing four drives simultaneously, and the whole point is to finish inside the return window. A modern desktop can happily run badblocks on four USB attached drives at the same time, because the bottleneck is the platters rather than the host.

Which SMART attributes actually matter on a new drive?

SMART is a set of counters the drive firmware maintains about its own health, readable over the SATA or USB link without touching your data. There are dozens of attributes and most are noise. Seven decide whether a new drive stays.

Attribute IDs are standard across vendors, but raw value encoding is not. Seagate in particular encodes attributes 1 and 7 in a way that produces enormous, meaningless-looking raw numbers on a perfectly healthy drive. Read the normalised value and the threshold column, and only panic about raw values on the four attributes marked as returns above.

Read the attributes before you write a single byte. On Linux and on most NAS platforms with shell access that is smartctl -a /dev/sdX. On Windows, CrystalDiskInfo shows the same table including power on hours. The check takes ten seconds and it is the single highest-value moment of the entire process, because power on hours in the thousands on a drive sold as new tells you the listing was wrong before you have invested any time in it.

UDMA CRC error count deserves its own note, because it causes more false alarms than any other attribute. It counts corrupted frames on the wire between the drive and the controller, not problems on the platters. A drive that accumulates CRC errors in a USB enclosure and none on a direct SATA port has a cable problem. Swap in a known-good right-angle SATA data cable or move the drive to a different bay before you conclude anything about the drive itself.

What do the short and long SMART self tests actually do?

A SMART self test is a diagnostic the drive runs on itself, in its own firmware, and reports pass or fail without the host doing any of the work. There are two you care about and they are not interchangeable.

The short test takes one to two minutes regardless of capacity. It checks the electrical and mechanical basics, exercises the servo, and reads a small sample of the surface. It is a smoke test. Passing it means the drive is not dead on arrival, and that is all it means. Run it first because it costs nothing and it occasionally saves you from starting a two-week procedure on a drive with a seized motor.

The long test, also called the extended test, reads the entire surface. The drive reports its own expected polling time, which scales with capacity, and the figures in the table below are typical. A long test that completes without error means every sector on the platter was readable at that moment. That is a genuinely strong signal and it is completely non-destructive, which makes it the right first move on a drive that already has data on it.

What the long test does not do is write. A sector can read back fine and still fail the moment something writes to it, and a weak sector on an unwritten region of a new drive has never been challenged at all. That gap is what badblocks fills.

Both tests run in the background at low priority, so the drive stays usable while the test runs and the test takes longer if the drive is busy. Start them, then check back with smartctl -l selftest /dev/sdX. Do not sit and watch the percentage.

What is badblocks and how long does a full run take?

badblocks in write mode writes a test pattern to every sector of the drive, reads it back, and compares. The standard invocation writes four patterns in sequence, so the surface is written and verified four times, which is eight complete passes over the platters. It destroys everything on the drive, which is exactly why it belongs before the drive joins an array and never after.

This is the test that finds sectors that read cleanly but cannot hold a write, and it is also a genuine thermal and mechanical soak: many hours of continuous head movement at full duty, which is how a marginal bearing or a weak actuator gets provoked into failing on your desk. The cost is time, and the time scales with capacity.

Sustained rate is a whole-surface average from published sequential specifications, not the peak outer-track figure on a datasheet. One full pass is a single read or write of every sector. badblocks with four patterns is eight passes. Full regime is a long self test, the four-pattern badblocks run, and a second long self test. Capacities are decimal TB as printed on the label; your NAS will report each one about 9.05 percent smaller because it counts in binary tebibytes, which is explained in the TB against TiB chart.

Two things fall out of that table. First, burn-in time scales almost linearly with capacity while sequential speed barely improves, so the practice gets more painful with every generation of larger drive. A 4 TB drive is a long weekend. A 24 TB drive is 14.6 days. Second, this is the same arithmetic that governs rebuild time on a live array, which is the argument for double parity on large drives set out in RAID 5 against RAID 6. If you find a full pass intolerable on the bench, notice that a rebuild is that same pass across every surviving member simultaneously, with your data at stake.

What is a sensible burn-in schedule if you cannot spare two weeks?

Most of the diagnostic value arrives early. A single write-and-verify pattern is two full passes rather than eight, and it still forces every sector to accept a write and give it back. Between two long self tests, that regime takes about 62.5 h on an 8 TB drive instead of 145.8 h.

• Minimum, about a day on an 8 TB drive. Read SMART on arrival, run the short test, run the long test, read SMART again. Non-destructive, and it still catches a returned unit and an already-damaged surface.
• Sensible default, two to three days on an 8 TB drive. Add a single-pattern badblocks write and verify in the middle. This is the version most people should actually run.
• Full regime, 6.1 days on an 8 TB drive. Four patterns. Worth it for drives going into an archive you rarely read, where a latent bad sector could sit undiscovered for years.
• Always, forever. Schedule a short test weekly and a long test monthly on every drive in the array once it is in service, and enable scrubs or a parity check on the same cadence. Burn-in is the beginning of monitoring, not a substitute for it.

Whatever regime you choose, read the SMART attributes before and after and compare the numbers. The comparison is the test. A drive that finished with the same zeros it started with has passed. A drive that gained a single reallocated sector has told you something important even though badblocks itself reported no errors, because the firmware quietly retired the sector and hid the failure from the host.

How should you receive and inspect a drive when it arrives?

Bare drives are shipped as delicate mechanical instruments and handled as parcels. The single most common avoidable cause of a dead-on-arrival drive is a drop, and the second is a drive packed loose in a box with nothing but air pillows.

A properly packed bare drive arrives in a moulded clamshell or a suspension pack that holds it in the middle of the carton with clear space on all six sides. If your drive was rattling inside a padded envelope, or resting against the wall of the box, treat it as suspect regardless of what SMART says on day one. Shock damage frequently shows up as a drive that tests perfectly and then develops reallocated sectors in the first month, which is precisely the failure burn-in exists to catch.

• Photograph the packaging before opening it if it looks damaged. That photograph is what makes a shipping claim straightforward rather than a negotiation.
• Let the drive reach room temperature before powering it. A drive delivered from a cold van into a warm house can condense moisture inside the enclosure. A couple of hours in the room is enough.
• Handle by the edges and never touch the exposed board. Static damage to the controller is real and it is silent.
• Check the label against the listing. Model number, capacity, and whether it says the drive was manufactured recently. A mismatch here plus high power on hours is a returned drive being resold.
• Do not stack drives on a hard surface. A drive tipping over onto a desk from standing is enough of a shock to matter.

If you are buying an external drive to shuck rather than a bare drive, the packaging problem largely goes away, because retail externals are packed to survive consumer shipping. That is one of the smaller advantages discussed in drive shucking explained, alongside the warranty trade-offs that make the practice a real decision rather than an obvious win.

What hardware do you need to burn in drives outside the NAS?

You can burn in drives inside the NAS itself if the platform gives you a shell, and TrueNAS, Unraid and most Linux-based units do. The constraint is that the drive must not yet belong to a pool, because badblocks writes over everything. That is fine for a fresh build and awkward for a live array where you want to pre-test a spare.

A dual-bay USB dock lets you test two drives at once on a desktop while the array carries on serving files, which is the practical answer for anyone keeping a cold spare. Two caveats apply. First, some USB bridge chips do not pass SMART commands through to the drive, so check that smartctl -d sat -a returns a real attribute table before you rely on the dock for anything. Second, USB attachment adds its own error sources, so a UDMA CRC error count that rises on the dock and stays flat on a SATA port is the dock talking, not the drive.

For testing inside a desktop, a spare SATA port and a three pack of right-angle SATA cables is cheaper and more reliable than any USB path, and it removes the bridge chip question entirely. A pack of anti-static bags is worth having for the drives that pass and go into storage as spares, and a small fan pointed at drives sitting on open air during a multi-day badblocks run keeps them well clear of the 50 C mark that attribute 194 is watching.

What should you do when a single sector reallocates?

A reallocated sector is one the drive has retired and replaced with a spare from a reserve pool set aside at the factory. The data that was in it is gone unless parity or a backup can supply it. Every drive ships with a few thousand spares, and the factory has already mapped out everything it found defective before the drive left the line.

That last fact is the whole argument. On a new drive, a reallocation during burn-in means the surface produced a defect the factory scan did not find, under its first real workload, within days of manufacture. That is a drive on the steep part of the infant mortality curve. Return it. One sector is enough. You are not being fussy: you are exercising a right that expires.

On a drive with two or three years of service the calculus is different. A handful of reallocations that appeared once and then stopped is ordinary wear, and swapping the drive costs real money for no benefit. What matters is the trend.

Reallocated is SMART attribute 5, pending is 197. These thresholds come from published vendor guidance and large-fleet reliability statistics rather than from any testing of our own. Put your own drive count and service age through the drive failure probability calculator to see how the odds change across an array.

Why does testing on arrival matter for the RMA window?

Warranty and return are two different clocks and the shorter one is the valuable one.

The retailer return window is typically 30 days, sometimes less. Inside it, a drive that misbehaves goes back for a refund or a straight replacement, usually with a prepaid label and no argument. The manufacturer warranty is longer, three years on most NAS drives and five on the pro tiers, but a warranty claim is a different experience: you ship the drive at your cost, wait, and receive a recertified drive rather than a new one. That recertified unit is fine for most uses, but it is not what you paid for, and it arrives weeks later while your array runs degraded.

So the value of burn-in is not only that it finds bad drives. It is that it finds them in week one instead of week six. The entire regime is engineered to fit inside the return window, which is why the duration table above matters so much: if a 24 TB drive needs 14.6 days of testing and your window is 30 days, you have to start the day the box arrives, and you have to test all the drives in parallel.

Do not put a drive into service and burn it in afterwards. Once real data is on it, badblocks is off the table, you are down to non-destructive tests, and every day that passes burns return window on a drive you now cannot easily send back. Test first, build second.

One buying consequence follows from all of this, and it is the same one that comes up in how to choose NAS drives: split a multi-drive order across two retailers or two order dates. Drives from one order tend to come from one manufacturing run and one pallet, so they share whatever went wrong at the factory and whatever happened in transit. Splitting the order decorrelates both, and it means a batch problem shows up in half your drives rather than all of them.

Does any of this replace a backup?

No, and it is worth being blunt about the limit. Burn-in reduces the chance that a drive fails in the first month. It does nothing about the drive that fails in year four, nothing about the controller that corrupts writes, nothing about a deleted directory, and nothing about ransomware, which is the other failure mode that genuinely loses people data and is covered in hardening a home NAS against ransomware.

Parity is not a backup either. An array with double parity survives two dead drives and does not survive a mistake. The three protections are independent: burn-in and monitoring reduce hardware surprise, parity keeps the array serving through a failure, and a real copy on separate media covers everything else. Size that copy with the 3-2-1 sizing calculator.

The honest summary is that burn-in buys you one specific thing: the failures that were going to happen anyway happen while the drive is a returnable object rather than a member of your array. For a few days of a desktop running unattended, that is a good trade on a purchase where the drives are two thirds to four fifths of what you spend.

Related reading

• How to choose NAS drives for which drive to burn in before it goes in the bay
• Best NAS hard drives with current prices per terabyte
• Drive reliability chart for what large-fleet failure statistics actually show
• RAID 5 against RAID 6 for why rebuild reads dictate parity choice
• 3-2-1 backup rule guide because a tested drive is still not a backup