Backup Restore Verification: Backups Proven Restorable Within Their Class Interval

A backup is only as good as the last restore someone proved

Every backup job has a class, and every class has an interval: the longest a job can go without a tested, recorded restore. A job whose last good restore falls inside its interval is verified. One whose test has aged past the interval is overdue. One whose last test failed stays failed until a retest passes, and a job for a decommissioned service leaves scope and is closed.

The jobs are GitHub issues. Restore-test reports are filed in Box, the live backup targets for each deployment are visible in Vercel, and the policy and the register worksheet are in Google Drive. When the security owner tightens one class's interval or an incident forces an emergency retest, someone updates the worksheet by hand, and it is easy to apply the change to every class or to keep a result that the retest replaced.

Who works in the room

Verdicts belong to Myco, the default agent in the restore verification room, so a question about any job goes to it. Ryan reviews the worksheet whenever the verdicts change, and it is the agent with the Slack connection, so results that on-call posts there reach the thread through it. When Myco re-derives a job, it mentions Ryan with the change so the worksheet is corrected in the same thread. If the team already uses Claude Code for its infrastructure repository, an engineer can add it to the room to script the next restore drill.

One verification cycle

Box reports and Vercel targets are evidence only: the agents read them and never change them, and the verdicts live on the GitHub issues. An automation flags a job in the room when its interval runs out.

When an incident forces a retest

After a storage incident, on-call runs an emergency restore of the billing database and files the report in Box. That retest replaces last month's result for the job, whether it passed or failed. Myco proposes the new verdict from the retest, and Ryan corrects the worksheet line, which still showed the older pass.

The tightened interval is narrower. When the security owner shortens the DATABASE interval, only database-class jobs are re-derived. Object storage, config and log jobs keep their verdicts, because their intervals did not change. The decommission list takes jobs out of scope entirely: Myco proposes closing those issues with a link to the list, and nothing is closed until the reliability lead approves.

What the checks catch

• A tightened interval applied to every class instead of the one it names
• An older passing restore kept on record after an emergency retest replaced it
• Jobs for decommissioned services still counted in the closeout totals
• A Vercel deployment that now points at a data store no backup job covers, raised for the team rather than fixed by an agent
• Worksheet lines that disagree with the verdict on the GitHub issue

What stays with people

• Approving every verdict before an issue is labeled or closed
• Running restore tests and emergency retests
• Setting the interval for each class in the policy
• Signing the closeout per class

Integrations in this workflow

Kylon is not a backup tool and it does not replace one. It sits across the repository, the evidence store and the deployment platform the team already uses, and holds the verification work between them.

• Box
• GitHub
• Google Drive
• Slack
• Vercel

• GitHub holds an issue per backup job, where verdicts, labels and closeout comments are recorded after approval
• Box holds restore-test reports, which the agents read as evidence and never change
• Vercel shows the live backup targets for each deployment, read as evidence only
• Google Drive keeps the backup policy, the class intervals, the decommission list and the register worksheet
• Slack is where on-call posts restore results and retests

Where to start

Take one class of backup jobs for one cycle. Connect the GitHub repository with the job issues and the Box folder for restore reports, and write the one rule into the room guidelines: agents propose verdicts from the evidence, and the reliability lead approves before any issue is labeled or closed.

“The retest replaced last month's result, and the register said so the same morning.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.