Should You Back Up Home Assistant Live or Stop the Service First?

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.

For current Home Assistant installations, use the built-in backup system as the first choice and let it run while Home Assistant is online. Stop or quiesce the service only when you are making a plain filesystem copy or using another method that does not coordinate the active database.

The real decision is therefore โ€œsupported application backup versus generic file copy,โ€ not simply โ€œlive versus stopped.โ€ A successful rsync, SMB copy, VM snapshot, or archive command does not by itself prove that the database and the rest of Home Assistant state were captured at one consistent recovery point.

Use the Built-In Backup Path First

Home Assistant's Backup integration now creates and restores backups across installation types. For Core and Container, the backup.create action includes the Home Assistant configuration and database while the system remains online.

That supported path should be the baseline for routine recovery points. Keep the encryption key or emergency kit outside the Home Assistant host, move at least one backup off-host, and confirm that the backup can be restored before relying on it for an upgrade or migration.

Only move to manual filesystem copying when you have a reason the built-in backup does not cover, and then make the database-consistency behavior explicit.

Stop Home Assistant Only for a Plain /config Copy

Stopping the service is still the simplest way to make a generic config-directory copy internally consistent. Prepare the destination, permissions, and free space first; then stop Home Assistant, copy the tree, verify the job, and start the service again.

A practical container migration workflow uses exactly this boundary: stop the container before copying its SQLite-backed persistent configuration. That is appropriate for a raw filesystem transfer, not a reason to stop Home Assistant for every built-in backup.

Do not extend downtime by discovering path errors after the stop. Validate the destination beforehand and use the stopped window only for the final authoritative copy.

A Live Database Backup Can Be Safe When It Is Database-Aware

SQLite itself supports online backup mechanisms that produce a consistent standalone copy while the source database remains active. That is very different from copying the database file and WAL independently with a generic synchronizer.

A recent homelab backup workflow explains why SQLite's page-aware .backup command avoids the inconsistent main-file and WAL combinations of naive live rsync.

If you build a custom live backup, stage the database-aware copy separately, copy the remaining configuration with compatible semantics, and prove the whole result in a restore test. Database consistency alone does not preserve missing custom files, secrets, or runtime definitions.

Keep Database-Aware Live Backups Separate From Generic Snapshots

Do not apply the โ€œstop for rsyncโ€ rule to database-aware live backup methods or to Home Assistant's own backup interface. The consistency guarantee comes from the backup primitive, not from whether the word โ€œsnapshotโ€ or โ€œbackupโ€ appears in the tool name.

For Container installations, also preserve the runtime definition outside Home Assistant: the Compose file, host config path, device mappings, network mode, and external service dependencies. A backup archive can restore Home Assistant state without recreating an undocumented container layout by itself.

The ZimaSpace example of giving Home Assistant its own recovery plan beside the NAS reinforces the scope boundary: data protection must cover both application state and the environment needed to run it.

Judge the Backup by Restore Results

Restore a recent backup into an isolated target and verify users, integrations, dashboards, automations, helpers, device registries, history if required, and one representative local-control path. Restart that restored target once before calling the backup proven.

A backup method that completes every night but cannot restore a working system is operationally worse than a short maintenance stop with a tested recovery result. Prefer the simplest method that meets your downtime requirement and produces a repeatably restorable state.

FAQ

Do I need to stop Home Assistant before using its built-in backup feature?

No. Use the built-in backup workflow as designed. The stop recommendation applies to ordinary file-level copies that do not coordinate Home Assistant's active database and state.

Is a filesystem or VM snapshot automatically a safe live backup?

Not automatically. A snapshot is only as useful as the consistency it captures and the restore test that follows. If the application and database keep writing during the snapshot, verify that the snapshot method provides the consistency guarantees your recovery plan depends on.

Support & Tips

More to Read

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.