# Backup Verification

## Objective

Prove your backups restore, instead of trusting that they exist.

Automated checks that a backup is complete, encrypted, retained, and actually restorable — with a recorded test restore rather than an assumption.

## Before You Begin

This feature is being added to an application that already exists and already
works. Do not scaffold a new project, and do not assume a blank slate.

Inspect the codebase first and establish:

- The existing application structure and where code of this kind already lives.
- The framework and version in use.
- The existing design system — colours, spacing, typography, and component conventions.
- Existing UI components you can reuse instead of writing new ones.
- The existing database structure, if this feature needs to persist anything.
- The existing authentication and authorization system, if this feature is user-scoped.
- Dependencies already installed, so you don't add a library that duplicates one.
- The existing test setup and conventions.

Only start writing code once you understand the above. If the application
already implements part of this feature, extend it rather than replacing it.

## Implementation Instructions

1. Inventory what must be backed up first: every database, every uploaded-file store, and any external state the app cannot rebuild. A backup covering only the primary database is a partial backup, and should be reported as one.
2. After every backup, verify it mechanically: the file exists, its checksum matches, its size is within a sane band of the previous run, it is encrypted, and it is where the retention policy expects it.
3. Restore on a schedule into a fully isolated environment and assert against the restored data — row counts within expected ranges, the newest record close to the backup time, and a handful of known invariants.
4. Neutralise all outbound side effects in the restore environment before the data loads. Disable mail, webhooks, payment calls, push notifications, and analytics at the configuration level, not by hoping the code paths are not reached.
5. Record recovery-point and recovery-time evidence for each test: how much data would have been lost, and how long the restore took. Trend both over time — a restore that gets slower each month is a future incident.
6. Do NOT treat a successful backup job as a successful backup. A zero-byte file uploaded without error passes every check that only looks at the exit code.

## UI and UX Requirements

Match the application's existing design system exactly. Reuse its components,
spacing, and typography. This feature should look like it was always there.

## Responsive Requirements

Works on mobile, tablet, and desktop. Touch targets are large enough to hit on a
phone, and nothing overflows horizontally at 320px.

## Accessibility Requirements

- Fully keyboard navigable.
- Correct semantic elements and ARIA roles.
- Visible focus states.
- Meets WCAG AA contrast.
- Dynamic changes are announced to screen readers.
- Respects prefers-reduced-motion.

## Edge Cases

- The restore environment must never be able to reach production credentials, queues, or third-party accounts. Verify the isolation as part of the test, not once at setup.
- Restored data is production data. It carries the same access controls, retention obligations, and deletion requests, and the environment must be destroyed after the test.
- A size band catches truncation but also fires on legitimate growth. Compare against a rolling baseline rather than a fixed number.
- Verify that the encryption key needed to restore is itself recoverable and stored separately from the backup. A backup you cannot decrypt is not a backup.
- Retention deletion must be checked in both directions: old backups actually removed, and recent backups not removed early.
- A failing verification must alert loudly. Silent verification failures produce a system that has looked healthy for months.
- Uploaded files and database rows can drift apart. Check that a sample of restored records still points at objects present in the restored file store.

## Testing

Exercise the feature end to end in the running application. Cover every edge case
above, then run the existing test suite and confirm nothing regressed.

## Acceptance Criteria

- [ ] Every data store requiring backup is inventoried, and partial coverage is reported as partial.
- [ ] Each backup is checked for existence, checksum, size band, encryption, and retention placement.
- [ ] A scheduled test restore runs into an isolated environment and asserts data invariants.
- [ ] Mail, webhooks, payments, and push are disabled by configuration in the restore environment.
- [ ] Recovery-point and recovery-time figures are recorded per test and trended.
- [ ] Restore environments are destroyed after verification.
- [ ] A failed verification raises an alert rather than being logged quietly.
- [ ] The feature matches the existing design system.
- [ ] No existing functionality is broken.

## Adaptation Rules

- Match the existing design system. Do not introduce a new colour palette,
  spacing scale, or component library.
- Reuse existing components and utilities wherever they fit.
- Follow the naming, file layout, and code style already present.
- Do not upgrade, replace, or remove existing dependencies to make this
  feature fit. Adapt the feature to the app, not the app to the feature.
- Do not break existing functionality. If a change is genuinely required in
  existing code, make the smallest one that works and say so.
- If something in these instructions conflicts with how the application is
  built, follow the application and explain the deviation.

## Final Verification

Before you report the work as done:

1. Re-read the acceptance criteria above and check each one against what you
   actually built.
2. Run the application and exercise the feature end to end.
3. Run the existing test suite and confirm you have broken nothing.
4. Check the feature on mobile, tablet, and desktop widths.
5. Check keyboard navigation and focus handling.
6. Summarize what changed: files added, files modified, and anything you
   deliberately did differently because of how this application is built.

If any acceptance criterion is unmet, fix it before reporting completion.