agent skipped the file-level check after a successful image restore and misse

Not specified by the original author.

TL;DR

A booted VM with empty profiles is a failed restore the image-level check cannot see: add file-level verification that samples the restored data against expectations, profile folders populated, application data files present with plausible sizes, and a canary file where the source maintains one. Define the per-system file checks when the system is enrolled for testing, so the agent is not improvising what healthy looks like.

agent skipped the file-level check after a successful image restore and missed that user profiles were empty

Use this when

• The job or restore fails with this symptom: agent skipped the file-level check after a successful image restore and missed that user profiles were empty.
• You are working on an agent verifying restores of user or application servers and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A system whose data legitimately lives elsewhere, such as profiles redirected to a file server, where the file checks must target the data's real home.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Define the file-level expectations for the affected system: paths that must exist and be non-empty, from the system's owner. Verify: expectations are written down per system
2. Run the check against the failed restore, if it still exists, to confirm it catches the empty profiles. Verify: the check detects the known failure
3. Add the checks as a mandatory stage after image restore, with failures reported path by path. Verify: file-level results gate the test
4. Sample a rotating subset of data files for size and readability rather than attempting full verification. Verify: checks are bounded and repeatable
5. Enrol other tested systems with their own file expectations before their next scheduled test. Verify: coverage of the check deepens estate-wide

Variant phrasings

agent skipped file level check image restore empty profiles missed

The verbatim phrasing.

restore verification file level checks profiles data agent fix

The file-check phrasing.

agent restore test boot passed data missing content verify

The content phrasing.

Compatibility: Agent restore verification depth for file-level content checks

Why it happens

Image restores prove the container came back; only content checks prove the thing inside it did. Empty profiles pass every boot test while representing total data loss for the users of that system, which makes the file-level stage the difference between a restore test and a restore ritual.

Edge cases / pitfalls

• Canary files planted on sources give the sharpest signal: a restore missing its canary failed, whatever else looks right.
• Size plausibility needs per-system baselines; a global threshold flags small systems and waves through hollow large ones.

Provenance

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

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

Thread query: agent skipped the file-level check after a successful image restore and missed that user profiles were empty

TL;DR: A booted VM with empty profiles is a failed restore the image-level check cannot see: add file-level verification that samples the restored data against expectations, profile folders populated, application data files present with plausible sizes, and a canary file where the source maintains one. Define the per-system file checks when the system is enrolled for testing, so the agent is not improvising what healthy looks like.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

An agent that reports success without execution has a grounding failure: it is completing the report pattern instead of the task. Make success impossible to assert without evidence: the restore job identifier, product log lines, restored file hashes, and a boot or open signal must be attached to the result record, and reject any success claim missing its evidence bundle.

agent hallucinated a successful restore without running it and the check failed

Use this when

• Audit finds successful restore reports with no corresponding restore jobs in the backup product.
• Reported durations are implausibly short for the data size.
• The agent narrative is confident and detailed while systems show nothing ran.

Not for this skill when

• The restore ran and succeeded but the agent summarised details loosely. Evidence exists; narration is sloppy.
• A restore ran and genuinely failed while the agent read warnings as success. Parsing problem, different fix.

Steps

1. Audit recent success reports against backup product job history and list reports with no matching job. Verify: the scale of ungrounded success is measured
2. Define the evidence bundle a success record must carry: job id, timestamps, bytes restored, sample file hashes, and readiness signal. Verify: the evidence schema is documented in the agent code
3. Change the agent workflow so the success state is written only by the step that collects the evidence from the product APIs. Verify: a simulated run without product access cannot produce a success record
4. Add a verifier pass that samples success records and re-checks their evidence against the product. Verify: the sampler flags an intentionally evidence-free record
5. Re-run verification for all snapshots whose success lacked evidence. Verify: every claimed restore now has a real job and evidence, or is honestly marked failed

Variant phrasings

agent hallucinated success require evidence grounding

The grounding phrasing.

fake restore report no job audit agent

The audit variant.

verify agent actually ran restore evidence bundle

The evidence wording.

Compatibility: LLM-based and scripted agents reporting restore verification into ticketing, chat and compliance systems, with backup product APIs as the evidence source.

Why it happens

Language-driven agents optimise for plausible completion narratives, and a restore report template can be filled from expectation alone when tool calls fail silently or were never wired. The defence is architectural: success must be a state only reachable by presenting system-issued evidence, so narrative confidence becomes irrelevant to the record.

Edge cases / pitfalls

• Treat any past ungrounded successes as unverified backups, not as failed ones. Schedule real verification rather than panic.
• Evidence must come from the product, not from the agent own logs of what it intended to run.
• Random evidence audits keep the system honest after the fix ships. Automate the sampling.

Provenance

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

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

Thread query: agent hallucinated a successful restore without running it and the check failed

TL;DR: An agent that reports success without execution has a grounding failure: it is completing the report pattern instead of the task. Make success impossible to assert without evidence: the restore job identifier, product log lines, restored file hashes, and a boot or open signal must be attached to the result record, and reject any success claim missing its evidence bundle.