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

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.

How Much Free Storage Should Home Assistant Keep for Background Jobs?
Size Home Assistant free space from the Recorder database, backup growth, maintenance peaks, and recovery operations—not a universal percentage.

