How Much Free Storage Should Home Assistant Keep for Background Jobs?
Home Assistant should not use one universal free-space percentage. The useful reserve is the space required for the current Recorder database, the largest normal maintenance or upgrade operation, backup growth, and enough recovery headroom to avoid filling the filesystem while the system is trying to repair itself.
Start with the database because Recorder can temporarily need substantial working space during rebuilds, repacks, schema changes, or corruption recovery. Then add the real size of local backups and other applications that share the system disk. A small installation with a 400 MB database has a different floor from one carrying several gigabytes of history and many retained backups.
Use the Recorder Database as the First Capacity Unit
Measure the current database size and its daily growth. A free-space floor should not drop below the amount needed to perform normal database maintenance while still leaving the operating system room to write logs, temporary files, and upgrade data.
Home Assistant community guidance from a Recorder maintainer recommends keeping at least the database size free and preferring roughly 2.5 times the database size for difficult table-rebuild recovery cases. Treat that as a database recovery requirement, not as a universal percentage of the whole disk.
If the Recorder database is 2 GB, a nearly full 256 GB disk can still be dangerous even though its free percentage looks small but acceptable. Conversely, a tiny database on a large SSD does not need an arbitrary 20% reserve solely because a percentage rule says so.
Backups Can Quietly Become the Largest Local Consumer
Automatic and manual backups accumulate independently of the Recorder database. Keeping several old archives on the Home Assistant system disk can remove the free space needed to create the next backup or complete an upgrade.
Track local backup count, individual archive size, and retention. Move recovery copies to a NAS or another destination instead of treating the production disk as both live state and long-term backup storage.
The ZimaSpace discussion of separating Home Assistant backups from the live host is the right recovery model: free-space management improves when old backups are not competing with the active database on the same device.
Reduce Database Growth Before Expanding the Disk
A fast-growing database can consume any fixed reserve. Find noisy entities, unnecessary attributes, long retention, or integrations that generate frequent state changes before simply increasing the storage allocation.
Database growth can often be reduced before storage is expanded. One practical cleanup used Recorder exclusions, shorter retention, and targeted purging for noisy entities instead of treating a larger disk as the first fix.
Measure again after the change. The goal is not the smallest database possible; it is a database that retains useful history without making routine purge, backup, and upgrade work progressively harder.
Leave Headroom for Repack, Upgrade, and Recovery Work
Purging old rows does not always immediately shrink the database file. A repack or rebuild can rewrite a large portion of the database and temporarily increase I/O and storage use before space is reclaimed.
A separate database-cleanup walkthrough shows how an oversized Recorder database can also inflate backups; reducing what is recorded and then purging or repacking the retained data addresses both growth paths rather than deleting random files from the config directory.
Never begin a heavy repack when the disk is already near full. Free backup space or expand the filesystem first, because a maintenance job that runs out of working space can create a harder recovery problem than the original large database.
Set a Measured Floor and Alert Before You Reach It
| Space component | How to size it | Why it matters |
|---|---|---|
| Recorder working space | At least current DB size; larger recovery margin when possible | Rebuild, repack, schema work |
| Backup reserve | Largest expected new archive plus retention policy | Backup must finish before cleanup |
| Upgrade reserve | Observed image/package and migration peak | Version changes may need temporary files |
| Host reserve | Normal logs and other services | System must keep operating during maintenance |
Set an alert above the failure floor so there is time to act before background work is blocked. Review the threshold after major growth in entities, cameras, retention, add-ons, or backup size.
FAQ
Should Home Assistant always keep 20% of the disk free?
No. A fixed percentage can be too much on a large disk and too little for a large Recorder database on a small disk. Size the floor from the actual database, maintenance, backup, and recovery workload.
Why did Recorder purge old data without reducing the database file immediately?
Deleting rows can free space inside the database for reuse without shrinking the file on disk. Repack or rebuild operations can reclaim filesystem space, but they are heavier jobs and need additional working headroom.
Recommended products
Support & Tips
More to Read
Should You Back Up Home Assistant Live or Stop the Service First?
Built-in Home Assistant backups can run live; plain filesystem copies should stop or quiesce Home Assistant unless the database is backed up consistently.
Why Does a Home Assistant Server Run Hot or Noisy During Idle Hours?
Correlate Home Assistant fan or temperature spikes with Recorder, backups, integrations, and co-hosted jobs before changing cooling or CPU limits.
When Should You Rebuild Rather Than Repair Home Assistant?
Repair the smallest failed Home Assistant layer first, restore known-good state next, and rebuild only when persistent configuration cannot be trusted.
