Why Does a Home NAS Backup Exclude Hidden Files and App Metadata?

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.

Why Does a Home NAS Backup Exclude Hidden Files and App Metadata?

The backup is usually excluding a path, not randomly losing hidden data.

On a home NAS, hidden files and app metadata are commonly missed because the task selected only the visible share, an ignore rule matched the path, the backup identity lacked access, or the data lived in a container volume, database, symlink, or mounted filesystem outside the chosen tree. The repair starts by locating the missing recovery unit and testing the smallest likely cause.

Map the Missing Result to the First Test

Begin with the restore result rather than the green completion status. Different missing patterns point to different layers of the backup job.

If every dotfile is absent, inspect hidden-file and pattern filters; if one app returns without settings, map its database, secrets, and volumes; if one protected folder is absent, test access as the scheduled backup identity. Those observations narrow the cause before any production rule changes.

Record the missing path, expected item count, actual restore location, and first failed test. That evidence becomes the comparison baseline for the corrected run.

The table turns the visible symptom into a low-risk first action.

Missing Result	Likely Layer	First Test
All dotfiles missing	Filter or hidden-attribute rule	Inspect include/exclude order
App files exist but settings are gone	Database or volume outside the share	Map mounts and state paths
Only protected folders are absent	Service-account access	List as the backup identity
Mounted subtree is empty	Mount or symlink traversal	Compare real target and device ID

Use one row at a time. Changing filters, permissions, and mounts together can make the next success impossible to attribute.

Check Source Scope and Ignore Rules as One Decision

A task cannot protect data outside its selected roots, even when the NAS interface visually nests several datasets beneath one share. Source scope and ignore patterns must therefore be reviewed together.

Duplicity users can exclude dot-prefixed paths with a hidden-path exclusion pattern. Similar rules may exist in a NAS template, command line, environment variable, marker file, or per-folder configuration.

Export the task settings and compare each selected root with the real path of the missing item. Test the suspect pattern on a small staging tree and narrow only the rule that excludes recovery-critical content.

Find App State Outside the Visible Shared Folder

Self-hosted apps often separate user files from application state. A photo folder can hold originals while the database, thumbnails, face data, secrets, and configuration live in other locations.

Container deployments use persistent Docker volumes and bind mounts to store state independently from the image. Backing up only the media share can therefore preserve visible files while omitting the state required to rebuild the app.

Inventory the complete recovery unit: Compose file, environment variables, secrets, named volumes, bind mounts, database dump, application configuration, and user-data paths. Add the real sources or an application-aware export instead of assuming one share contains everything.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Test Permissions and Traversal as the Backup Identity

An administrator may browse a path that the scheduled backup account cannot read. A mounted subtree or symlink may also appear local while the backup tool refuses to cross or follow it.

A backup support case traced skipped NAS data to backup-account access. Run a non-destructive listing as the exact service account and record every denied directory before changing ACLs.

Then compare mount points, device IDs, symlink targets, encrypted-folder state, and container UID mappings. If the target lives elsewhere, add the real path as a source and document whether the tool stores the link, follows it, or stops at the filesystem boundary; real-world symlink handling show why that behavior cannot be assumed.

Separate Recovery-Critical Metadata From Disposable Hidden Data

Enabling every hidden directory can increase scan time and repository size without improving recovery. The correct decision is whether the item is needed to reproduce user data or application state.

Keys, configuration, databases, manifests, secrets, ratings, albums, and irreplaceable sidecars are usually recovery-critical. Thumbnail caches, runtime sockets, temporary uploads, lock files, and easily regenerated indexes may be disposable or lower priority.

Document the classification in the backup plan. A deliberate exclusion should name the rebuild method and acceptable recovery delay; anything without a documented rebuild path should remain protected until an isolated restore proves otherwise.

Prove the Corrected Backup Contains the Whole Recovery Unit

Run a new backup after changing only the confirmed cause, then compare source and backup inventories. A second green status is still insufficient when the item count or restored application state remains smaller than expected.

Use the existing guide to silent backup warning signs when duration, byte count, exclusions, skipped objects, or restore behavior drift from the baseline.

Restore the hidden files or application state into an isolated folder or test container and open it through the expected user path. Stop and redesign the method if the only capture available is an unsafe live copy of a running database.