--- title: "Backup Restore Verification Workflow | Kylon" description: "How a platform team verifies backup jobs against restore-test evidence and class intervals, absorbs retests and decommissions, and keeps every verdict with a person." url: "https://kylon.io/use-cases/backup-restore-verification" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Backup Restore Verification: Backups Proven Restorable Within Their Class Interval Use Case7 min read # Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## 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 People - Reliability lead Approves every verdict, closes issues and signs the closeout by class - On-call engineers Run restore tests and emergency retests, and post the results - Security owner Owns the backup policy and sets the interval for each class - Service owners Confirm which services are decommissioned and leave scope Agents - MycoRestore register keeper Reads each backup-job issue, matches it to the latest restore report in Box and the live target in Vercel, and proposes a verdict under the class interval GitHubBoxVercelGoogle Drive - RyanWorksheet reviewer Checks the register worksheet line by line against the issues and the evidence, and lists every line that disagrees Google DriveGitHub[Slack](https://kylon.io/integrations/slack) 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. ```mermaid flowchart TD flag([An automation flags a job
when its interval runs out]) verdict["Myco proposes a verdict from the
latest restore report in Box"] ok1["Reliability lead approves before
any issue is labeled or closed"] sheet["Ryan checks the worksheet line by
line against the approved verdicts"] fix["Engineer who keeps the worksheet
corrects it"] change([A tightened interval, a new report,
a retest or the decommission list]) rederive["Myco re-derives only the jobs
each change touches"] sec["Security owner confirms
the interval"] svc["Service owners confirm the
services that leave scope"] ok2["Reliability lead approves
the verdicts and closures"] line["Ryan rechecks the worksheet lines
the new verdicts change"] totals["Ryan totals each class
from the final issue states"] sign["Reliability lead signs the closeout"] flag --> verdict --> ok1 --> sheet --> fix --> rederive change --> rederive rederive -->|interval| sec rederive -->|decommissioned| svc rederive -->|new result| ok2 sec & svc --> ok2 ok2 --> line --> totals --> sign class verdict,sheet,rederive,line,totals agent class ok1,fix,sec,svc,ok2,sign person class flag,change event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Verdicts | Each pending job is matched to its latest restore report and live target and given a verdict under its class interval | Myco | The reliability lead approves before any issue is labeled or closed | | Worksheet review | The register worksheet is checked line by line against the approved verdicts | Ryan | The engineer who keeps it corrects it | | Interval change | Only jobs in the tightened class are re-derived | Myco | The security owner confirms the interval and the reliability lead approves the changes | | New restore results | Jobs with a new report in Box are re-derived from that report | Myco, then Ryan | The reliability lead approves | | Decommission list | Jobs for retired services leave scope and their issues are closed with a link to the list | Myco | Service owners confirm and the reliability lead approves the closures | | Emergency retest | A retest after an incident replaces the earlier result for that job | Myco | The reliability lead approves | | Closeout | Totals per class from the final issue states | Ryan | The reliability lead signs off | Stages of a restore verification cycle. Jobs, classes and intervals in this example are illustrative. ## 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](https://kylon.io/integrations/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. Set-up prompt Set up our backup restore verification desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Box, GitHub, Google Drive, Slack and Vercel. Tell me which ones still need connecting. 2. Ask me who works this desk: the reliability lead, the on-call engineers, the security owner and the service owners. Help me invite them to this Room. 3. Build a Restore Register App with Backup job, Class, Last restore and Status, one record per backup job. Fill it from the open job issues in GitHub. 4. Match each job to its latest restore report in Box and its live target in Vercel. Check the result against the class interval in Google Drive. Propose a verdict for each job and show me every line that is overdue, failed or uncovered by a backup job. 5. Hold every verdict until the reliability lead approves. Only after approval may any issue be labeled, closed or have a closeout comment recorded. Service owners confirm decommissioned jobs before the reliability lead approves those closures. 6. Write our rules and who approves what into this Room's guideline, so every class and every cycle follows it. 7. After one clean cycle, offer to turn the interval-expiry check into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Bug Bounty Triage: Valid Findings Paid From the Weekly Budget, Reversals Included A weekly bug bounty batch is triaged in one Kylon room. Agents check each ClickUp submission against scope, GitHub issues and Stripe payout history, allocate the week's budget, and the security lead approves every disposition and payout. Software & SaaSIT & security operations ](https://kylon.io/use-cases/bug-bounty-triage)