Snapshot validation
In Snapshots → Validation history, expand a run to see which recovery point was tested, which checks ran, and what remains unproven. This applies to Connect and Direct wherever volume snapshots are available, with the same existing permissions.
This page covers volume snapshots, not backups (logical database dumps). Snapshot validation checks a restored volume snapshot; it does not validate a logical dump backup.
What happens during a validation?
- Quave ONE selects the full snapshot and ordered incremental snapshot files through the chosen recovery point.
- The operator restores them into temporary, no-retention storage. It does not replace the source environment or move customer traffic.
- A separate validation Job inspects the restored data volume read-only. Other selected volume roles are restored but are not inspected by the integrity/catalog checks. It does not start your application or run production integrations.
- The result is recorded, then temporary resources are removed. Check outcome and cleanup are reported separately.
What do the checks prove?
| Check | Evidence | Does not prove |
|---|---|---|
| Integrity | The restored volume mounted and was non-empty | Business-data correctness or application consistency |
| Schema / catalog-control files | The supported engine-specific probe passed; for example, catalog files exist or PostgreSQL control data can be inspected | Database server startup, successful queries, or application behavior |
| Query | Not implemented by this validation flow | No query validation should be inferred |
A requested depth is not executed coverage. Generic applications run integrity checks only; unsupported schema checks are shown as skipped. A failed Job without execution evidence does not count as a successful integrity check. Failed and skipped checks remain visible even when another check passed.
Reading the evidence
- Data cutoff: the capture time of the exact tested snapshot, when recorded. It is not the time validation finished, and it does not describe newer snapshots.
- Recovery point and chain: identify the tested data. Older records may identify only a chain; its latest point is not assumed.
- Execution start/completion and elapsed duration: operator measurements, separate from submission and polling times. Historical observation timestamps are not relabeled as measured runtime.
- Selected volumes and restore progress: show the recorded coverage and restored snapshot-chain file counts, not application records. Independent volumes are not certified as application-consistent.
- Per-check duration: shown only when measured. “Not recorded” does not mean zero.
- Run reference: use this when contacting support. Raw logs, credentials, signed URLs, filenames, and internal resource names are not displayed.
Cleanup is separate from validation
Cleanup can be pending, failed/retrying, confirmed, or not recorded. Confirmation means the temporary Job, pods, restore requests, volume claims, and run secrets were observed to be absent. Merely accepting their deletion is not confirmation.
No-retention storage is configured for reclamation, but this validation does not independently observe physical storage reclamation. The evidence says so rather than treating volume-claim removal as physical deletion proof. A cleanup delay does not erase the check results; inspect the status again, or contact support with the run reference if cleanup remains unresolved.
Limits and failures
A pass applies only to the recorded point and checks at that time. It does not certify current application behavior, dependency availability, multi-volume consistency, regional recovery, RPO/RTO compliance, or Disaster Ready status. Snapshot validation is not a DR Check or Recover operation.
For failure, expand the checks and restore progress. Retry validation when appropriate; if evidence is missing or failure persists, contact support with the run reference. Historical sparse records remain available with “Not recorded” rather than fabricated details.