How to Recover a Home Assistant Database From a Known-Good Backup

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Recover a Home Assistant Database From a Known-Good Backup

A known-good Home Assistant database backup is most useful when you first decide what you actually want to recover. If the whole Home Assistant installation should return to the backup point, use the supported Home Assistant restore workflow. If configuration is healthy and only Recorder history needs recovery, a database-only restore can avoid overwriting newer automations and integrations.

Do not replace the live database while Home Assistant is writing to it. Preserve the current database first, stop Home Assistant or otherwise quiesce Recorder, restore the known-good copy into an isolated or controlled path, then start and verify before deleting either version.

Choose Full Home Assistant Restore or Database-Only Recovery

A full Home Assistant backup restore replaces current application state with the backup contents. That is appropriate when the configuration, integrations, apps, and database should all return to the same known point.

The current full-backup restore action explicitly warns that current changes are overwritten by the backup state. If the only failure is Recorder history, that scope may be broader than necessary.

For database-only recovery, identify the exact known-good Recorder database copy and keep the current configuration tree untouched. Document the timestamp of the backup so you know how much history will be lost by going back to it.

Confirm Which Database Home Assistant Is Actually Using

Home Assistant uses SQLite by default, stored as /config/home-assistant_v2.db, but Recorder can instead point to MariaDB, MySQL, or PostgreSQL through db_url. Do not copy an SQLite file into a deployment that actually writes to an external database.

SQLite is the default Home Assistant Recorder database and is normally stored as /config/home-assistant_v2.db; Recorder can also be configured to use a supported external database through db_url. Check the effective Recorder configuration before touching files so the recovery asset matches the database Home Assistant is actually using.

If the database is external, restore it with the database engine's own backup method and coordinate the application version and schema. Do not treat a SQL dump and a SQLite file as interchangeable recovery assets.

Stop Writes Before Replacing a SQLite Database File

If your known-good backup is a clean physical copy of home-assistant_v2.db, stop Home Assistant before replacing the live file. Preserve the current database under a different name rather than deleting it.

SQLite's own backup guidance explains that a database copy must represent a consistent snapshot; the SQLite Online Backup API exists specifically to create a consistent copy while a database is active. A known-good stopped copy or a database-aware online backup is safer than an arbitrary file copy taken during writes.

Also confirm that no sidecar WAL or journal state from the failed database is being mixed with the restored copy. Start from the complete known-good recovery asset, not a hybrid of files from different timestamps.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Start With the Backup Copy Intact and Let Home Assistant Validate It

Place the restored database at the expected path with the correct ownership and permissions, then start Home Assistant and watch Recorder logs. Do not run purge, repack, or manual SQL maintenance during the first validation boot.

If the database schema is older than the current Home Assistant version, Recorder may need to migrate it. Allow that process to complete before judging performance or restarting again. Avoid bouncing between old and new Home Assistant versions against the same restored database because schema migrations are not a general downgrade mechanism.

A practical recovery walkthrough demonstrates the same controlled principle: work on copies and start Home Assistant only after the replacement database is ready.

Validate History Before Removing the Failed Database

Confirm Recorder starts without corruption or migration errors.
Open History and Logbook for a time range that should exist in the backup.
Check long-term statistics or Energy data if those records matter to you.
Trigger a new state change and confirm new history is written after the restore point.
Restart Home Assistant once and confirm Recorder opens the same database again.

The ZimaSpace guide to database-consistent backups and restore tests applies directly: a backup becomes trustworthy only when the database accepts it and the application can write new state after restoration.

Keep the failed database until this acceptance test passes. It may still contain newer history that can be examined or selectively recovered if the known-good backup is older than expected.

FAQ

Can I restore only Home Assistant history without rolling back my automations?

Yes, when you have a known-good Recorder database copy and the current Home Assistant configuration is healthy. Stop writes, preserve the current database, restore only the Recorder database, and validate it before cleanup.

Should I restore a database backup taken from a much older Home Assistant version?

Only with care. A newer Home Assistant may migrate an older Recorder schema forward, but downgrading and repeatedly swapping versions against one database is risky. Keep backups and use a compatible recovery path.