Signs That a Home Assistant Storage Layout Is Becoming a Recovery Risk
A Home Assistant storage layout is becoming a recovery risk when one disk, host, mount, credential, or undocumented path can remove both the running state and every usable restore copy.
The warning often appears before an outage: backups live beside the VM, a network share reconnects under a different path, a database is external but restored in no documented order, or archives recursively include themselves. Map every persistent role and its failure domain, then run a read-only recovery review before relocating or deleting anything.
Map Data Roles and Their Real Failure Domains
List the system disk, configuration, active database, add-on state, media, logs, local snapshots, independent backups, encryption keys, and restore documentation. Record the physical disk, storage pool, host, network path, credential, and administrator needed for each role.
Two directories on one pool are separate paths but the same storage failure domain. A VM snapshot and its host storage may fail together. A NAS backup may still depend on the same switch, password store, or administrator account needed to recover production.
Fail the layout review when any critical role has unknown ownership or when every recovery copy shares the production disk, pool, host, or credential. Do not wait for free space to become low before correcting that dependency.
Look for Capacity and Mount Warning Patterns
Measure seven-day growth by database, backups, logs, media, and temporary files. Check whether backup destinations are mounted at job start, whether a missing mount causes writes into a local fallback directory, and whether an archive path can include previous archives.
A recursive backup path can create rapid growth without adding recoverable history. Treat recursion as a configuration fault, not a reason to buy capacity.
If growth is steady and owned, compare it with retention and restore-time targets. If growth steps upward, a mount disappears, or paths duplicate, stop new backup jobs and preserve one known-good copy before correcting the destination.
Test Independence With a Controlled Loss Scenario
For each primary failure domain, ask whether the backup file, decryption key, clean target, and instructions remain available when that domain is unavailable. Verify by reading an independent copy and performing an isolated restore, not by checking a green job status.
The ability to store backups outside the production drive creates a separate failure domain only when its credentials and recovery instructions also survive production loss.
A pass requires a recovery copy that can be reached without the failed production path. A fail requires moving or replicating the backup and key before changing the active layout; otherwise the migration itself increases risk.
Correct One Risk and Rehearse Recovery
Separate the highest-impact shared failure domain first, document mount and database recovery order, remove recursion, set retention from measured growth, and monitor destination presence before each backup. Keep the previous layout available until the new copy is verified.
Use the network-storage reliability boundary before placing active state on a remote mount.
Stop when production has a named primary location, every critical role has a protection method, and an independent restore meets the recovery target. Escalate storage I/O errors, repeated unmounts, corrupted archives, or unexplained ownership changes before further migration.
Monitor the Layout After the Correction
Track free space, growth by data class, mount presence, backup age, archive size, and restore-test date after the change. Alerts should identify the affected role and destination rather than report only a whole-disk percentage.
Compare the first two backup cycles with the documented layout and confirm no local fallback directory or recursive path has reappeared. Verify that retention removes only the intended old copies while the independent recovery copy remains available.
Reopen the recovery review when a database, storage pool, mount protocol, encryption key, or backup destination changes. A layout that passed before a topology change is evidence for the old system, not the new one.
Recommended products
Support & Tips
More to Read
How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.
How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.
How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.
