backup succeeds but file-level restore shows empty folders

TL;DR

Restore to an alternate location first, then check whether the files were ever in the backup at all: inspect the job exclusion list, the file-level index for that restore point, and the account used to browse the catalog. Most empty-folder restores are not data loss, they are filtered files, a metadata-only browse, or permissions hiding file entries while folder entries remain visible.

backup succeeds but file-level restore shows empty folders

Use this when

• Backup job finishes green but a file-level restore shows folders with no files inside them.
• Only some extensions or large files are missing from the restore browse.
• The same restore point shows files in one console view and empty folders in another.

Not for this skill when

• The restore point itself is corrupt or fails checksum checks. Use the checksum-specific skill first.
• A VM or image restore fails to boot. That is a boot and driver problem, not a file browse problem.

Steps

1. Stop restoring over the original location and pick an alternate target folder on different storage, then rerun the file-level restore for one known file by exact name and date. Verify: the restore log names that file, or explicitly says it was not found in the selected restore point
2. Open the job definition for that restore point and list every exclusion: file masks, size limits, hidden and system file settings, snapshot quiesce options, and changed-block or incremental filters that skip unchanged data. Verify: any exclusion that matches the missing files is identified in writing before you change it
3. Check the file-level indexing status for the restore point in the catalog. If indexing was disabled, failed, or is still running, rebuild or wait for the index and browse again instead of trusting the empty view. Verify: the catalog shows indexing complete for that point and file counts greater than zero
4. Browse the restore point with the backup service account and with an administrator account, and compare results. Folder objects often carry looser access control than file objects, so a limited account can see the tree and nothing inside it. Verify: one account shows the files, which proves a permissions cause rather than missing data
5. Mount the backup directly where the product supports it, for example a Veeam mount, a restic mount, or a Borg mount, and list the folder from the operating system instead of the console. Verify: the mounted view and the console view agree, or the mount shows files the console hid
6. If the files truly were never captured, fix the filter or the source selection, run a new backup, and test restore that new point before closing the incident. Do not declare recovery from the old point. Verify: the new restore point restores the sampled files with matching sizes and hashes

Why it happens

File-level browse is a catalog view, not a direct read of the backup file. Backup engines create folder entries during the walk of the source, then apply filters file by file. Exclusions for temporary files, database files, very large files, or files open at snapshot time remove the contents while leaving the tree. Separately, many products build a separate file index after the backup; if that index failed, the data blocks exist but the browse has nothing to show. Permissions add a third split: the browse session inherits the operators rights, and files backed up under a service account can be invisible to a restricted restore operator. That is why mounting the backup outside the catalog is the decisive test - it separates data loss from a display, index, or rights problem.

Variants and edge cases

empty folders after incremental restore only

Full restore points show files but incrementals show empty folders when the incremental captured metadata changes without file content, or when the chain is browsed at a point before the file was added. Browse the full and the next two incrementals in order and track when the file first appears. Verify against the synthetic full if the product builds one.

files missing but folder size looks right

A nonzero folder size with no visible files usually points to indexing or rights, not exclusion. Excluded files normally reduce the reported size as well. Rebuild the index first, then re-browse with the service account before escalating to corruption.

hidden and system files not showing in restore

Some consoles hide dotfiles, hidden attributes, and system files by default in the restore wizard. Toggle show hidden items, and compare with a mounted view. Application data folders on Windows and dot-directories on Linux are the classic casualties. Edge cases: deduplicated and compressed backups may report logical folder sizes that look healthy while a single damaged index segment empties one subtree, so sample several folders, not just the reported one. Time based browse can also land between a rename and a copy, showing the new folder empty and the old folder full. Always record which restore point, index state, and account produced the empty view - that triple is what support will ask for, and it is what turns a vague missing data report into a fixable catalog, filter, or permissions defect.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Fm3zyuiOtw4qVuyl0k3H0Q