Missing data, capacity and backup scope

Understand the likely causes

• Likely causes include an excluded disk, external bind mount, unavailable data source, wrong recovery point, snapshot-retained blocks or missing discard behavior. Guest filesystem free space is not the same measurement as pool allocation.

Map application paths to sources

Before allowing an empty application to initialize itself, identify where the expected data should live. Map each path to a managed guest disk, managed container volume, external mount or service. Record exact copy identity and included volumes from approved evidence. A visible path inside a running guest does not prove the backup owned its bytes. The synthetic table is deliberately descriptive rather than configuration. It helps reveal an external-data omission before a recovery action creates a new divergent dataset over what should have been a mount point.

/var/lib/catalog -> managed data volume -> included copy identity required
/srv/media -> external source -> separate recovery owner
container bind mount -> host-side source -> not assumed part of root backup
acceptance -> expected item IDs and media references

Distinguish scope from consistency

If the required data source was omitted, select its independent recovery process rather than repeating the same incomplete restore. If all sources are present, assess the recovery point and application consistency separately. A filesystem-coordinated copy can still be inconsistent with an external database or media service. Verify expected records and relationships using the application’s supported checks. Boot success and a matching file count are weak evidence; they do not establish transaction correctness or that the archive corresponds to the intended incident time.

Diagnose capacity at the right layer

For a full-pool symptom, distinguish promised logical sizes, allocated data blocks, metadata usage, snapshot references and physical free space. Deleting guest files may only update the guest filesystem; reclamation needs supported discard behavior across the path, and retained snapshots can keep old blocks alive. Do not delete unknown volumes or snapshots to make a graph improve. Establish their owners and recovery purpose first. Restore, migration and clone operations can also require temporary capacity beyond steady-state demand, so the recovery plan must account for transition space.

Verify data and recovery coverage

A corrected recovery should demonstrate the intended data sources, expected application records and usable service in an isolated authorized environment. Record the achieved point and time and any remaining excluded state. This guide opens no archive, queries no pool and runs no restore or administrative command. Its local output is an explicit scope and capacity reasoning framework. Actual engine support, disk integrity, reclamation and application correctness remain separate unexecuted checks, avoiding a misleading claim that a complete-looking inventory has already proven recoverability.

Keep it from recurring

• Keep a data-source-to-backup map, document external mounts, retain independently usable copies and review snapshot ownership. Revisit coverage when application paths change and budget for restore and migration transitions.