Home Assistant Shows Stale Data After a Storage Path Change

Stale Home Assistant data after a storage path change usually means the running instance is reading a different /config or database than you expect, not that Home Assistant has recreated old state from memory.

Stop making path changes and preserve both the old and new data locations. From the running container, prove the mounted source, identify the active database and instance, compare timestamps and unique state, and only then correct one mapping. If history or registries may be overwritten, stop Home Assistant before copying or renaming anything.

Prove Which Path the Running Container Actually Sees

Inspect the live container rather than the Compose file alone. Confirm the host source mapped to /config, whether it is a bind mount or named volume, and whether the resolved source exists and contains the expected configuration files. A correct-looking declaration can differ from the running container after an incomplete recreation.

A resolved migration discussion emphasizes that a container move depends on a correct bind-mounted config folder with usable permissions. That supports checking the live mapping first; it does not prove that every stale-data case is a permission fault.

Create a harmless marker file in the intended host path while Home Assistant is stopped, then confirm that the same marker is visible at /config inside a temporary inspection container. If it is absent, fix the mapping. If it is present, continue to database and instance identity.

Distinguish an Older File Copy From an External Database

Compare modification times and a few unique configuration facts across the old and new paths: an automation name, dashboard change, helper, or recent backup. If the new directory is simply an older copy, do not merge files selectively while Home Assistant is running; choose the authoritative set and copy it as a stopped, consistent unit.

Check the Recorder database URL. Moving /config does not move an external MariaDB or PostgreSQL database, and a restored configuration may still point to the previous database. If current entities look correct but history is old, the database branch is stronger than a full config mismatch.

The ZimaSpace article on persistent data after stack recreation explains the neighboring failure mode: an empty mount can look like data loss, while an older mount can look like data rolling backward.

Rule Out a Duplicate Instance and Client-Only Cache

Confirm the browser URL, server name, IP address, instance ID, and certificate belong to the intended Home Assistant host. During migrations, an old DNS record, reverse proxy target, mobile-app server entry, or powered-on old host can send different clients to different instances.

Compare the same entity and history timestamp from a private browser session and a second client. If only one client is stale while the server logs and another client are current, clear that client connection or cached frontend data rather than changing storage again.

If clients alternate between old and new state, stop the old instance and correct DNS, proxy, or load-balancer targets. Do not allow two controllers to run automations against the same devices while you diagnose identity.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correct One Mapping and Preserve a Rollback Copy

Stop Home Assistant, snapshot or copy both candidate paths, and label them with host, date, and known state. Select the authoritative /config and database as a matched recovery set. Correct only the container mapping or database URL responsible for the verified mismatch.

Check ownership and write access before starting. If the container can read the chosen path but cannot write it, the system may appear correct initially and then fail to persist new state. Do not use broad recursive permission changes without confirming the service identity and expected ownership.

Start Home Assistant once and inspect logs before making further edits. If the expected entities, dashboards, history, and recent changes appear, continue to persistence testing. If not, stop and roll back to the labeled copy rather than combining the two data trees.

Verify the Correct Data Survives Recreation and Restart

Make one reversible test change, such as creating a temporary helper or renaming a test automation. Restart Home Assistant and confirm the change remains. Then recreate the container from the saved deployment configuration and check again.

A passing result shows the same instance identity, expected history, current registries, correct mount source, successful writes, and no duplicate controller. Confirm a new backup includes the selected state and store it away from both migration paths.

Escalate if data changes depending on the client, history comes from a different database than live state, or the correct path becomes read-only after reboot. Preserve mount inspection, database URL, timestamps, logs, and the two untouched rollback copies so the next step can target the remaining branch.