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.
Take a snapshot now
On supported regions, account admins can choose Take snapshot now beside Refresh in the Snapshots tab. This requests a new recovery point without changing the configured schedule. If a snapshot is already uploading, the next point waits for that upload to finish.
The request acknowledgment does not mean the snapshot is ready. Capture and upload can take a few minutes; use Refresh to see the new recovery point after upload completes. If a request cannot be confirmed, retrying checks the same request rather than deliberately creating another one. Snapshot validation remains a separate action.
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
Before submitting a restore or validation, Quave ONE checks that the selected snapshot has a full snapshot and an uninterrupted incremental chain. It uses the original encryption key recorded in that chain, including retained historical keys after rotation—not whichever key is currently active. Missing or ambiguous key metadata, unavailable original keys, and chains requiring multiple keys are rejected rather than guessed. Keep historical keys; choose an earlier complete recovery point or contact support if needed. These metadata checks do not prove that the stored objects can actually be restored.
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. A Running live app also does not prove this snapshot is good.
On the live source, this Snapshots-tab test and Disaster Readiness Validate now both exist for different questions: this page tests a backup; Validate now tests the destination copy. Neither replaces the other there. The destination is not another snapshot on this tab — use Validate now for that pipeline. See Disaster Readiness.
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.