Backup Evidence

Each backup run belongs to a database instance. Its run number identifies the record, while its start and completion times show when the operation took place. The recorded size and status help the team review the result. A restore-test date is separate evidence: a completed run and a tested restore answer different questions.

The database administrator records the run outcome against the correct instance. A backup reviewer checks the restore-test evidence before its date is recorded against a completed run. The recorded evidence then supports the move to verified. When a run failed, the team can see it in the failed-run screen and decide whether to raise an incident against the affected service and host asset. The run record gives the team evidence for that discussion.

• Run identity. A run number and linked database prevent a result from being assigned to a similarly named instance.
• Time and size. Start, completion and byte size provide a concise operational history.
• Outcome. Running, completed, failed and verified states distinguish work in progress from review of a recorded result.

Agree which system supplies run details and who enters or checks them. Choose how a restore test is documented before its date is placed on a run. The reviewer needs to know that the date belongs to this run, not merely to an unrelated restore exercise. Decide which failures require a service incident and which person owns the follow-up. The service can be found through the database’s host asset.

For a first operating cycle, select a database and its recent run. The administrator confirms the instance and host, enters the start and completion times, and records the outcome. The reviewer then checks the restore-test evidence for that same run. A status change to verified should follow the evidence review, not the passage of time.

Suppose a run completes overnight. Open it in the completed-run screen. Check its database link, run number, times and recorded size. If a restore test has been completed, the backup reviewer checks the supporting operational record before its date is entered. A completed run with that evidence can then move to verified. If the test belongs to a different run, leave this one completed while the team resolves the mismatch.

Repeat the rehearsal with a failed run. Identify the database, then the asset and service behind it. The service manager can decide whether the failure needs an incident and who should take it. Preserve the failed outcome so the next shift sees what occurred, even if a later run succeeds.

• Backup Runs to Verify — Completed runs whose evidence needs reviewer attention.
• Failed Backup Runs — Failed outcomes grouped with their database and timing details.

See database and backup evidence and incident handling.