---
title: The Day the Home Server's SSD Died
description: A reboot exposed a failing SSD in my Home Assistant box, and the rebuild found 29.7 GB of stale databases inside the backup. What I'd check first.
image: https://willcurran.com/hubfs/will-curran-brand/home-server-ssd-died-cover-nolane.png
---

[Skip to content](https://willcurran.com/blog/home-server-ssd-died#main)

[Will Curran](https://willcurran.com/)

[Home](https://willcurran.com/) [Portfolio](https://willcurran.com/portfolio) [Press](https://willcurran.com/media) [Blog](https://willcurran.com/blog) [Favorites](https://willcurran.com/favorites) [Speaking](https://willcurran.com/speaking) [Consulting](https://willcurran.com/consult) 

[Hire Will](https://willcurran.com/hire)

[Writing](https://willcurran.com/blog) Builds — The Day the Home Server's SSD Died [Subscribe](https://willcurran.com/blog/subscribe)

Builds

# The Day the Home Server's SSD Died

![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=44&height=44&name=will-curran-avatar.jpg)

Will Curran Jul 27, 2026 · 6 min read

<https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwillcurran.com%2Fblog%2Fhome-server-ssd-died>

On this page

![An abstract dark scene: a long row of small blocks representing a drive, glowing steadily until one marigold-outlined block breaks the row, next to the title The day the home server's SSD died.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/home-server-ssd-died-cover-nolane.png?width=1600&height=900&name=home-server-ssd-died-cover-nolane.png)

In late July 2026 the mini PC that ran Home Assistant for my house got a reboot in the middle of a config session and never came back. My question was whether that reboot had broken it. The answer was half yes. The reboot pulled the trigger, and the SSD was already failing. Then the rebuild turned up a bigger surprise: of the 33.94 GB my newest backup restored into the config folder, 29.7 GB was two stale copies of the history database.

## The reboot was the trigger, and the drive was the cause

A reboot makes the machine read its boot path again, and that path now ran into a region of the drive that could not be read. A drive in that state stays up only until something forces that read. It would have died at the next power cycle no matter who caused one.

So the reboot spent the machine's last good boot on a drive that was already failing. In hindsight it was still a bad trade, because the newest backup that had actually finished was a week old.

## SMART said healthy the whole afternoon

The afternoon went through four wrong theories. The drive's own SMART report helped every one of them along. It said healthy the entire time the drive was failing.

It was a cheap no-name drive without DRAM, and its SMART table simply didn't include the counters that would have shown this failure. There was no pending-sector count and no uncorrectable-error count, and it never reallocated a sector. A counter that can't move will always read zero. I had been scoring a clean report as evidence against the drive, when it was no evidence at all.

What settled it was low-tech. I pulled the SSD, put it in a USB adapter and read it from a different machine, with a different controller, cable, power supply and operating system. Reads worked up to about 49.7 GB into the drive, then failed at the same spot, the same way, both times. The fault traveled with the drive. A full sequential read is one command and needs no trust in the firmware. Run earlier, it would have saved about ninety minutes.

## The backup was mostly old databases

The newest backup that had finished was from seven days before the failure. Backups had been attempted every day that week. None had finished since that one.

That backup's config folder restored to 33.94 GB:

- **17.74 GB:** an orphaned copy of the recorder database, Home Assistant's history store. Nothing read it.
- **11.95 GB:** the live recorder database.
- **About 2 GB:** git history of the config.
- **Under 0.3 GB:** the actual configuration.

![Bar chart of what was inside the backup's 33.94 GB config folder: an orphaned copy of the history database at 17.74 GB, the live history database at 11.95 GB, git history at about 2 GB, and the actual configuration at under 0.3 GB.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/home-server-ssd-died-backup-contents.png?width=1440&height=656&name=home-server-ssd-died-backup-contents.png)

None of that shows in the backup's metadata.

My best guess, and it is only a guess, is that the bloat is why the nightly backup stopped finishing: every night it had to build an archive of about 34 GB. A config folder that size may also have pushed writes toward the part of the drive where the bad region sat. I can't prove either one.

So the plan for rebuild day was to delete the orphaned copy right after the restore, and fix the bloat rather than buy a bigger disk.

## There is no installer

This is the step that surprises people. The Home Assistant OS image for x86 machines was a disk image, written straight onto the target drive, either with that drive in a USB enclosure on another computer, or from a live Linux USB stick booted on the box itself. The download was well under a gigabyte compressed, 6 GiB once written, and it grew to fill the drive on first boot. That first boot sat on a preparing screen for several minutes while it expanded. It wasn't hung.

The live-Linux route has one way to make everything worse: writing the image to the wrong disk. The rule was to confirm the target's model string before pressing enter, and not to wipe or reuse the old drive at all.

One thing the backup didn't hold was the host's network settings. Those had to be re-entered by hand.

## Running again on an interim drive

The rebuilt machine first booted about 20 hours after it went down, on an interim 1 TB drive, restored from the week-old backup. The permanent drives hadn't arrived yet.

## If you are about to try this

- **Open a backup and list its biggest files.** The file size won't tell you what is inside.
- **Watch the last completed backup, not the last attempted one.** Alert when the newest good backup gets too old. A failure alert that never fires looks exactly like success.
- **Put a size alarm on the config folder and the history database.** A threshold of a few GB would likely have caught this weeks early.
- **Know your install path before you need it.** On x86, plan to flash the image. Have a USB enclosure or a live Linux stick, and a monitor and keyboard for the BIOS, ready.
- **Check that SMART can report the failure before you believe it.** If the pending-sector and uncorrectable counters are missing, a full sequential read is the real test.
- **Reboot the fresh install once on purpose before you restore anything.** A box that boots once hasn't proven it boots.

## Build it yourself

**What it does:** a rebuild kit and runbook for a Home Assistant box, written before the bad day, plus checks that tell you when your backups stop being real.

**The parts:** a spare drive, a USB-to-M.2 enclosure or a live Linux USB stick, a monitor and keyboard, a known-good Ethernet cable, and the OS image for your hardware downloaded ahead of time with its checksum checked.

**How it fits:** flash the image, boot it, reboot it once, re-enter the host's network settings, restore the backup from onboarding, then verify in order of what fails silently: automations and entity references first, then the things that announce themselves.

**Cost and time:** I've left cost out. My box was down about 20 hours, from the failure to the rebuilt machine's first boot.

Give this to your AIHelp me write a rebuild runbook for my Home Assistant box before I need one. First, look at my newest backup: list the largest files inside it with their sizes, and flag anything that isn't configuration, such as old database copies or git history. Check whether my backups are completing, not just being attempted, and propose an alert on backup age and on the size of the config folder and history database. Then find out how Home Assistant OS installs on my hardware, list what I need on hand to do it, and check the current OS release for open boot problems on my board, so I know which version to install. Write the steps in order: flash, first boot, one deliberate reboot, network settings, restore, then a verification list that starts with whatever fails silently.

If you have found something surprising inside your own backups, I'd like to hear about it.

Filed under [Builds](https://willcurran.com/blog/tag/builds)

![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=64&height=64&name=will-curran-avatar.jpg)

Will Curran

I spent sixteen years building one company, and I have been in the event industry since 2007. These days I write about the technology I actually use — trucks, radios, home infrastructure, and the tools that survive past the first invoice.

[All posts by Will →](https://willcurran.com/blog/author/will-curran)

Get the next one by email

One email per post. No digest, no sponsors.

[← Previous With a BedJet, Cooling Comforters Are Wrong](https://willcurran.com/blog/bedjet-cooling-comforters-are-wrong) [Next → My Motion Sensor Gave Up Above 100°F](https://willcurran.com/blog/my-motion-sensor-gave-up-above-100f)

## Related reading

[Builds A Check That Can't Fail Is Worse Than None 6 min read](https://willcurran.com/blog/a-check-that-cant-fail) [Builds Trivia Over LoRa: a game show on a slow, lossy radio mesh 8 min read](https://willcurran.com/blog/trivia-over-lora) [Builds "Precise" Is Less Precise 3 min read](https://willcurran.com/blog/precise-is-less-precise) [Builds Terrain Beats Floors 7 min read](https://willcurran.com/blog/terrain-beats-floors)

[Will Curran](https://willcurran.com/)

[LinkedIn — 29,339+ followers](https://www.linkedin.com/in/willcurran) [GitHub](https://github.com/rancur) [YouTube](https://www.youtube.com/channel/UCJgscc27l4fpkWx1SeK05xg/) [Spotify](https://open.spotify.com/user/rancur) [SoundCloud DJ mixes](https://www.soundcloud.com/thewillsee) [Twitch](https://www.twitch.tv/thewillsee) [Last.fm](https://www.last.fm/user/default) [Trakt — movies & TV](https://trakt.tv/users/willcurran) [Goodreads](https://www.goodreads.com/user/show/55302838-will-curran) [Will See Music](https://www.thewillsee.com) [Arizona Meshtastic](https://azmsh.net) [Electric Forest Meshtastic](https://efmesh.com)

© 2026 Will Curran — All rights reserved. [RSS](https://willcurran.com/blog/rss.xml) [Back to top](https://willcurran.com/blog/home-server-ssd-died#main)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Will Curran",
    "url" : "https://willcurran.com/blog/author/will-curran"
  },
  "dateModified" : "2026-10-22T20:33:13.306Z",
  "datePublished" : "2026-07-27T16:00:00.000Z",
  "headline" : "The Day the Home Server's SSD Died",
  "image" : [ "https://willcurran.com/hubfs/will-curran-brand/home-server-ssd-died-cover-nolane.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://willcurran.com/blog/home-server-ssd-died",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://willcurran.com/hubfs/image-1.png"
    },
    "name" : "Will Curran LLC"
  }
}
```