noCV
ARESTORE-102 · Identify recovery inputs

Create a backup manifest that binds bytes to schema revision

Practice briefTaskIntermediate

Operators find three similarly named dump files and cannot tell which migration version or time each represents.

Focused work estimate
2h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Provenance · Checksums

Estimated field mix

  • Database engineering60%
  • Storage systems40%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional case-management team has nightly backup files but has never tested application behavior after restore. Missing roles and external artifact references may make a successful database restore unusable.

Setup prerequisites

  • Create a disposable synthetic database and local backup directory.
  • Never connect these drills to production or overwrite a shared database.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Record byte hash, size, UTC capture time and migration identity.
  • Bind the manifest to the exact backup artifact.
  • Reject a missing or mismatched manifest before restore.

Implementation constraints

  • Use synthetic data and avoid credentials in command logs.

Verification to include

  • Verify a backup and matching manifest.
  • Alter backup bytes and reject the restore plan.

Deliverables

  • Backup manifest command and integrity checks

Rollout and recovery

Create manifests for new backups; label unverified older files as uncertain.

Value of the work

For the engineer: Practice restore verification, provenance and operational recovery.

For the team: Review evidence that recovery produces coherent usable state under declared limits.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.