How long do hard drives last? The better question is whether you would find out in time.

Ask how long a hard drive lasts and you get a number back: three years, five, eight if you are lucky. The number is not wrong so much as unusable. Drives fail on a distribution and yours is a sample of one, so the average describes a warehouse, not the disk under your desk. The answerable version of the question, and the one that decides what a failure costs you, is how long it would take you to notice something had gone wrong.

What SMART is good at, and what it is not

Every modern drive keeps counters on itself: sectors it had to reallocate, sectors it is not sure about yet, errors it could not correct, surface scans that came back wrong. That is SMART, and on Linux you read it with smartctl. It earns its place. Google published a study of its own drive fleet in 2007 and found that after a drive's first scan error it was 39 times more likely to fail within 60 days than a drive with none. A SMART warning is a real warning. Act on it.

The same study is the reason not to read silence as health. Over 56 percent of the drives that failed had no count at all in the four strongest signals, and over 36 percent had zero counts on every variable Google tracked. Backblaze, reporting on 67,814 drives in 2016, found that 76.7 percent of failed drives had a non-zero value on at least one of the five attributes it watches, which leaves roughly a quarter that showed nothing. Both are data centre fleets on data centre duty cycles, so do not read household lifespans or brand rankings out of them. Read the shape instead. The warning light works, and it is not wired to every failure.

Reading the counters is also not the same as running a check. Attributes move as the drive gets used, so the regions you have not touched since 2019 report nothing, because nothing has been near them. The extended self test, smartctl -t long, walks the whole surface, and it is the only routine item on the list with an opinion about the sectors under your old photos. It takes hours, and nobody runs it by accident.

The monitor fails the same way the drive does

Say you did this properly. smartd polls the disk and mails you if an attribute goes bad. Eighteen months later the mail provider retires an authentication method, or a container is rebuilt without its config, or an upgrade drops a cron entry. Nothing announces any of that. The machine keeps running and the inbox stays clean.

That is the part worth sitting with. An alerting setup has two states that look identical from outside: healthy and quiet, or broken and quiet. The drive fails silently, and so does the thing watching the drive, so the two do not cover for each other. They compound. Plenty of people who lose files to a dead disk were not unmonitored; they were monitored by something that had stopped monitoring.

The fix is not a better alerter. It is inverting which condition produces the message. A weekly note saying the surface scan finished on Tuesday and the reallocated sector count is still zero beats an alerts-only rig, because once healthy is noisy, silence becomes evidence of a fault rather than evidence of health. It is the same reason you press the test button on a smoke alarm instead of waiting for it to mention the battery.

One trap is specific to drives in enclosures: SMART only crosses a USB bridge if the bridge chip supports SCSI-to-ATA translation. Plenty have to be told explicitly (smartctl -d sat), and some do not pass the commands at all, so the drive reports nothing. Find that out on setup day, not on the day it matters.

The drive in the drawer is the least examined thing you own

A cold copy on a shelf is usually the copy people are proudest of, and it is the one nothing has looked at. It runs no self tests and increments no counters, because it is not plugged into anything. Its condition is not good. It is unknown, and unknown is where the off-site copy of most households sits.

What you care about there is not whether the hardware is nominal but whether the bytes are still the bytes, and most filesystems will not volunteer that. ext4 checksums its own metadata, not your file contents, so a photo that has quietly rotted still opens, with a grey band across it, and the next backup job copies the damage over faithfully. The check that answers this is boring: keep a list of checksums beside the files, read everything back occasionally, and compare. That is one full read, which is also the only way to learn that the drive can still be read end to end.

Which changes the number worth tracking. Not the drive's age, which you cannot act on, but the age of your most recent proof: the last date on which every file came back. If you cannot name that date, the lifespan question was never the one holding the risk.

The honest tradeoffs

Verification is not free. A full-surface read on a large disk takes hours, and if a drive is already reporting pending or reallocated sectors, a long scan is the wrong first move; copy the data off, then diagnose the hardware. All of this is manual work on a schedule you have to keep, which is the sort of chore that lapses, so the realistic household minimum is two things: one heartbeat message that arrives when nothing is wrong, and one real restore a year where you open the files.

And nothing here predicts failure, including anything we build. A meaningful share of drives die with no warning at all, which is the point of the numbers above; the reason to keep a second copy is that detection is imperfect, not that it is unnecessary. Harbor Dock is one drive by design, so it inherits this squarely. What it offers is not durability. It is that the drive holds ordinary files on an ordinary filesystem, so checking it means plugging it into any computer and reading them, with none of our software in the path.

So the answer to how long a drive lasts is still: longer than you expect, until it is not. The part you control is the distance between the failure and the moment you hear about it, and that distance is set by a scheduled read and a message that shows up when everything is fine.