NAS Hard Drive Burn-In: Destructive badblocks and SMART Checks

Burn-in for NAS hard drives screens new HDDs before the storage pool depends on them​

The idea comes from electronics manufacturing: run a new part hard for a long time before you trust it. For a home or small-office NAS, that means pushing sustained writes and reads across every sector of a new HDD and running the drive's own diagnostics, all before it joins a storage pool or stores a file you care about.

The argument is about timing. A new drive is usually covered by a retailer's return window and a manufacturer's warranty, and it holds nothing. If it fails on the bench, you lose some waiting time and file a return. If it fails after joining an array full of data, even a redundant one, you get a degraded pool and a rebuild that puts extra load on the remaining disks. How-To Geek's author argues that the benefit grows when you buy several drives at once from the same batch.

Backblaze's own experience backs up the batch concern. In its October 2025 revisit of drive reliability, the company said it mostly sees failure differences between drive models. Because it buys in bulk, a bad model bought in quantity can mean a cluster of drives failing at around the same time. A home NAS with four identical disks from one order is a small version of that setup.

Burn-in does not repair a drive, extend its life or guarantee it will survive next year. It is meant to catch drives that develop bad sectors, throw read or write errors, or show worrying SMART changes under sustained load. Most new drives pass without incident, which is the result you want.

badblocks -w turns every sector into evidence, and erases the disk​

Most of the work is done by badblocks, a utility from the e2fsprogs package. According to its Linux manual page, the -w option runs a write-mode test. It writes the patterns 0xaa, 0x55, 0xff and 0x00 to every block on the device, reads every block back and compares the contents. A mismatch means the drive cannot reliably store data at that location.

The same manual carries a plain warning: never use -w on a device that contains an existing file system, because it erases data. If you want write-mode testing on a disk that holds data, the manual points to -n, a non-destructive read-write mode. It is slower but keeps the data. -n and -w cannot be combined. badblocks also normally refuses read-write tests on a mounted device. A -f flag overrides that check, and the manual says it should almost never be used.

Four patterns, each written and then verified across the whole disk, add up to many full passes over the platters. That is our inference from the documented design, and it explains why runtimes are measured in days. How-To Geek cites forum users reporting about five days of badblocks time on 8TB drives and about 166 hours per 12TB disk, even with several drives tested in parallel. Those figures are anecdotes, not benchmarks. Actual time depends on the drive, the connection and the test options. The maintainers of the burn-in script described below make the more general point that large disks can take several days.

A few other options are worth knowing:

• The -s flag prints rough progress for each pass, which is useful on a job that runs for days.
• The -v flag writes counts of read errors, write errors and data corruptions to stderr.
• The -e flag sets how many bad blocks badblocks tolerates before it aborts, and the manual notes that the resulting bad-block list may be incomplete.
• The -o flag saves the list of bad blocks to a file instead of printing it.

SMART attributes 5, 196, 197 and 198 only mean something after the drive is exercised​

SMART is the self-monitoring system built into most SATA and SAS drives, and smartctl from smartmontools is the standard way to read it. Its manual describes SMART's purpose as monitoring the drive's reliability, predicting failures and running drive self-tests. For a baseline, smartctl -i prints the model number, serial number and firmware version. smartctl -x prints all SMART and non-SMART information. The manual says the older -a option is no longer recommended for ATA disks because it skips options that need 48-bit ATA commands.

The burn-in sequence starts with a short SMART self-test, a quick check of the basics. The badblocks pass follows, then an extended self-test in which the drive's firmware scans its own surface. After that you compare the SMART data against your baseline. How-To Geek names four attributes that should still read zero on a new drive:

The order matters because of how some of these counters work. Backblaze explains that SMART 197 and 198 that have a value of zero today will not change unless a bad sector is encountered during normal disk operations. These two SMART stats don't cause read and writes to occur, they only log aberrant behavior from those operations. A SMART check on a fresh, untouched drive tells you little about those two counters. The badblocks pass forces the drive to touch every sector, so the SMART readings taken afterwards actually reflect the whole surface.

Backblaze tracks a slightly different set of attributes. The company uses SMART 5, 187, 188, 197, and 198 for determining the failure or potential failure of a hard drive, which adds 187 (reported uncorrectable errors) and 188 (command timeouts). In an earlier post it said "when the RAW value for one of these five attributes is greater than zero, we have a reason to investigate". It also noted that one metric alone might indicate a 30 to 40 percent chance of failure, while several together raised that to about 76 percent. That makes 187 and 188 worth adding to your before-and-after comparison.

Interpreting the numbers takes some care. Backblaze warns that since different disk drive manufacturers report SMART stats differently, be careful how you use this. It also notes that its tracked stats, with the exception of SMART 197, are cumulative in nature, so how fast a counter rises matters as much as whether it is non-zero. For a brand-new drive in its return window, a sensible rule is that any new non-zero value in these fields, or any badblocks mismatch, is a reason to exchange the drive. Don't ignore a failed self-test just because the overall SMART health status still says "PASSED" or "OK".

disk-burnin.sh packages the whole run, with dry-run as the default​

You don't have to build this sequence by hand. disk-burnin.sh, an open-source POSIX shell script by Keith Nash, runs a SMART short test, then badblocks, then a SMART extended test. It pulls full SMART information after each self-test and writes all output to both the screen and a log file named burnin-[model]_[serial number].log. According to its README, it was inspired by a FreeNAS forum thread on burn-in testing and is meant only for disks that hold no data.

The README documents several behaviors worth knowing before you run it:

• The script runs in dry-run mode by default, showing the planned commands and sleep durations without running any tests. You add -f to start the full, destructive test.
• By default, badblocks runs with -w, an 8192-byte block size and -e 1, so the test stops at the first error it finds. The -x option forces a full pass with -e 0.
• Any bad blocks found are written to a companion file named burnin-[model]_[serial number].bb, and the -o option sets the directory for log files.
• The script must run as root and needs smartmontools installed. It uses grep, awk, sed, sleep, badblocks and smartctl.
• On FreeBSD systems, including FreeNAS, you must run sysctl kern.geom.debugflags=0x10 first so badblocks can write to the whole disk.
• For drives in unusual enclosures, you may need to edit the script to pass an explicit smartctl device type. One user reported success with -d sat on a Western Digital MyBook 8TB external enclosure.

The README lists testing under FreeNAS 9.10 through 11.2, Ubuntu Server 16.04.2 LTS, CentOS 7.0, Tiny Core Linux 11.1 and Fedora 33 Workstation. Tested drives include Seagate IronWolf 8TB and 12TB NAS models, HGST Ultrastar He10 and He12, and several Western Digital lines. Windows is not on that list, and badblocks is a Linux e2fsprogs tool. In practice, then, a Windows user would do this burn-in from a Linux environment, or from a NAS operating system that exposes a shell, rather than from Windows itself. The last listed modification to the script is from February 2021, so read its current help text (-h and -e) before relying on these defaults.

Two operating habits matter more than any flag. How-To Geek recommends running the job inside tmux or screen so a dropped SSH session doesn't kill a multi-day test, and the script's README makes the same recommendation for parallel runs. The more important habit is to confirm the target disk's identity immediately before adding -f. A name like /dev/sdb can refer to a different disk after a reboot or a re-cable, and a destructive test aimed at the wrong device erases it, including a disk that is already in your pool. Match the serial number from smartctl -i to the label on the physical drive.

Backblaze's 2025 bathtub data weakens the odds but not the logic​

The traditional case for burn-in rests on the bathtub curve: a spike of early "infant mortality" failures, a long stable middle period, then rising failures as parts wear out. Burn-in targets the left edge of that curve. Backblaze's October 2025 analysis, based on 13 years of data-center telemetry, says the curve no longer describes its fleet well.

The numbers show why. In Backblaze's 2013 data, failure rates peaked at 13.73 percent at about three years and three months. In 2021 the peak was 14.24 percent at seven years and nine months. In the 2025 data, covering about 317,230 drives at the end of Q2 2025, the peak fell to 4.25 percent at ten years and three months. Drives between zero and one year old had an annualized failure rate of about 1.30 percent. Backblaze's summary is that drives are getting better and lasting longer.

That lowers the odds that any given new drive is a dud. Backblaze adds its usual caveats: its workloads and purchasing differ from consumers', and it now retires some healthy drives before they fail, which changes the shape of the curve. Retail drives also reach a home user through different shipping and handling. How-To Geek also points out that manufacturers test drives before they ship.

The trade-off is still reasonable. A lower failure rate means most burn-ins end with nothing found. The cost of a failure after deployment, though, has not changed: a degraded array, a stressful rebuild and a return process that is harder once the drive holds data. If you have the spare time and a spare machine, a week of testing is worth it. If the burn-in would take your only NAS offline for days, the trade is closer.

What this means for you​

Whether you do a full burn-in depends on what the days of testing cost you, not on whether the drive is "probably fine". If you are building a new array, adding several same-batch disks, or have a spare Linux box or free drive bays, run the full badblocks sequence. If testing would take your only NAS offline for most of a week, a lighter routine still catches a lot. Run the SMART short and extended self-tests, which many NAS operating systems can start from their web interface, and compare the SMART attributes before and after. Heat and noise are real during a long run, so give the drives decent airflow.

• Record the model, serial number and baseline SMART output (smartctl -i and smartctl -x) for each new drive before any testing.
• Use badblocks -w or disk-burnin.sh -f only on empty drives, and confirm the serial number against the physical label just before starting.
• After testing, check SMART attributes 5, 196, 197 and 198, plus 187 and 188 as Backblaze does, and treat any new non-zero value on a new drive as grounds for an exchange.
• Run long jobs inside tmux or screen, and expect several days per large drive rather than hours.
• If you use FreeBSD or FreeNAS, set kern.geom.debugflags=0x10 before badblocks, and expect USB enclosures to need an explicit smartctl -d device type.
• Keep a real backup whether or not a drive passes, because RAID and burn-in only deal with drive failure, not deletion, ransomware or a failure years later.

Burn-in costs electricity and days of waiting, and Backblaze's latest numbers suggest most tests will find nothing. What it buys is the chance to discover a bad drive while it is empty, returnable and not yet part of your pool. For anyone building or expanding a NAS, especially with drives from one batch, a full badblocks pass plus a before-and-after SMART comparison is worth the time. Have the backup plan in place before the first file lands on the new array.