# Restore Drill Reporter: An AI Agent for Recovery Evidence

The Restore Drill Reporter is an AI agent that reports on backup and restore drills for a customer data platform (CDP), comparing results with targets and flagging gaps in the evidence. It serves platform leads at read level (L1), working from drill logs alone, and it never triggers a restore, changes a backup policy or reads restored data.

The method behind it is [AI agent rails](https://privycdp.org/ai/rails), applied to recovery evidence. The [platform and data pipeline operations playbook](https://privycdp.org/ai/rails/functions/platform-operations) covers the wider picture.

## Rail at a glance

The Restore Drill Reporter's rail lets it read drill logs and nothing the drill restored. It holds no credential for backup systems, so it cannot start a restore even if a log line tells it to.

| Field | Value |
|---|---|
| Job | Report on backup and restore drills, and flag gaps in evidence. |
| Trigger | A completed restore drill or a schedule. |
| Data scope | Drill logs, recovery time and recovery point results, and the drill calendar, with no restored data. |
| Tool scope | Read: drill logs, targets, calendar; propose: no changes; execute: no actions. |
| Output contract | Result against target, gaps, overdue drills. |
| Gate | The platform lead reviews each report. |
| Limits | Log data only. |
| Ledger | Drill ID, results cited, report version. |
| Evaluation | Spot checks against drill logs. |
| Owner and kill switch | Platform lead; stopping the schedule ends the reports, and drills carry on as planned. |

## What it does and who uses it

The Restore Drill Reporter turns drill logs into a report a platform lead can sign, and it says plainly when the logs do not support a claim.

Illustrative run: a quarterly drill restores the profile store and the consent store into an isolated environment. The report shows a recovery time of 5 hours 20 minutes against a 4-hour target, which is a miss, and a recovery point inside its target. The profile store has a checksum comparison on record. The consent store's log shows only that the job finished, so the report says "integrity not shown". It also notes that key-management recovery has not been drilled and that the event store's drill is overdue. The platform lead books the follow-ups.

Customer data adds a test that general backup practice can miss. A restored snapshot predates the latest opt-outs, so withdrawals made after the snapshot must be replayed, or the platform may contact someone who has said stop. A drill should prove that replay, not only the restore, for the reasons the [consent withdrawal architecture](https://privycdp.org/email/consent-withdrawal-suppression-architecture) sets out.

Each claim in a drill report needs specific evidence, and this illustrative table gives the wording to use without it.

| Claim | Evidence in the log | Wording if absent |
|---|---|---|
| Backup exists | Job result, plus a non-empty target of plausible size | "No evidence of a usable backup" |
| Data intact | Checksums or row-count reconciliation [2](#source-2) | "Restored; integrity not shown" |
| Recovery time met | Declared start and service-usable timestamps | "Recovery time not measurable" |
| Recovery point met | Newest recovered record against the drill's chosen point | "Recovery point not measurable" |
| Consent current | Replay of changes since the snapshot, reconciled | "Withdrawals since the snapshot not shown as replayed" |

## Why this level

The Restore Drill Reporter stays at read level (L1) because recovery actions carry some of the largest blast radius in a platform. A restore pointed at the wrong target can overwrite live data. Reading restored data would pull customer records into a session with no need for them. Reporting carries neither risk.

Log lines include error text from many tools, so the Rule of Two [1](#source-1) treats them as untrusted. The session holds no customer data and no tool, which leaves one property of three, and a separate service delivers the report.

Running drills belongs to the platform team and its runbooks, so this agent never moves up. With one team and one database, a scripted report from logs may be enough.

Regulation shapes what readers expect, though the report states no view on compliance. Article 32(1) of the General Data Protection Regulation (GDPR) refers to restoring availability after an incident and regularly testing measures [4](#source-4). Article 12 of the Digital Operational Resilience Act (DORA) requires financial entities to test backup and restoration periodically, with no set interval [5](#source-5). The January 2025 HIPAA Security Rule proposal would add monthly test restores, as our [HIPAA update tracker](https://privycdp.org/regulation/hipaa-security-rule-update-tracker) records.

## Three ways it fails, and the control for each

Recovery reporting fails when a log line is taken for proof, as GitLab's 2017 outage shows.

| Failure | What it looks like | Control |
|---|---|---|
| "Succeeded" taken at face value | Nobody hears about a failing job, or a clean exit hides an unusable copy. GitLab's postmortem found an empty backup bucket, rejected failure emails and no owner for testing backups [3](#source-3). | A claim needs integrity evidence from the log. Without it the report says so, and it never says "passed". |
| A flattering clock | Recovery time starts with the restore job, leaving out the decision to restore and slow data copies. GitLab's copy alone took about 18 hours [3](#source-3). | The drill plan defines start and stop events. Code computes the interval, and the report prints both timestamps. |
| The same easy drill, repeatedly | One database is restored each quarter, while keys, the ledger and the consent store never are. The calendar still looks green. | Code tracks the last drill per component from the calendar. Undrilled components appear under a "not covered" heading. |

## How to evaluate it

A good report survives someone checking it line by line against the logs.

- **Report errors on spot checks.** Sample figures each cycle and trace them to log lines.
- **Overdue drills,** counted and aged per component, from the calendar.
- **Seeded logs.** Feed in a success with no checksum, a clock that starts late and a missing consent replay. Each should produce the absent wording.
- **"Not shown" trend.** The count should fall as drills improve. A fall with no change in drill practice suggests the reporter has grown generous.

## Where it runs

Drill logs hold no customer records, so the contract decides whether an external model may read them. Hostnames and topology are still sensitive, and [air-gapped sites](https://privycdp.org/learn/glossary/air-gapped-deployment) have no choice but private inference, as the [on-premise LLM guide](https://privycdp.org/ai/on-premise-llm-deployment-marketing-personalization) explains. [PrivyCDP](https://privycdp.org/cdp) includes AI-assisted review of reports, and a reporter on this pattern would be yours to define.

## Related

- [AI agents for platform and data pipeline operations](https://privycdp.org/ai/rails/functions/platform-operations): recovery among the other platform jobs.
- [Evidence Packer](https://privycdp.org/ai/rails/agents/evidence-packer): can cite a drill report when an auditor asks.
- [Rail card template](https://privycdp.org/tools/agent-rail-card): a starting form for this log-only rail.


Start from the [AI agent rails hub](https://privycdp.org/ai/rails) to see the other platform agents. Use the [rail card template](https://privycdp.org/tools/agent-rail-card) to record who reads each drill report.

Rail level: L1 · Risk: low · Function: platform operations

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### How often should you test a backup restore?

Set the interval by how critical the data is, and write it into the drill calendar. DORA Article 12 says periodically, without a figure. The reporter then flags anything overdue.

### What are recovery time and recovery point objectives?

Recovery time is the longest acceptable gap before a service returns. Recovery point is the most data you can accept losing, measured back in time. A drill tests both.

### Does a passed drill prove compliance?

No. A drill shows that a specific restore worked on a specific day, and the report records that evidence. Whether it meets a rule is for your compliance team and auditor to decide.

## Sources

1. Meta, Agents Rule of Two, applied to a log-reading session: https://ai.meta.com/blog/practical-ai-agent-security/
2. NIST SP 800-53 Rev. 5, CP-9(1), reprint: https://csf.tools/reference/nist-sp-800-53/r5/cp/cp-9/cp-9-1/
3. GitLab, postmortem of the 31 January 2017 database outage: https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31/
4. GDPR Article 32: https://gdpr-info.eu/art-32-gdpr/
5. DORA, Regulation (EU) 2022/2554, Article 12: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022R2554

This article is general information, not legal advice.

## Further reading

- [AI Agents for Platform and Data Pipeline Operations: The Playbook on Rails](https://privycdp.org/ai/rails/functions/platform-operations)
- [Connector Change Reviewer: An AI Agent That Flags Risky Config](https://privycdp.org/ai/rails/agents/connector-change-reviewer)
- [Cost Watcher: An AI Agent That Tracks Spend per Rail](https://privycdp.org/ai/rails/agents/cost-watcher)
- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)
- [AI Agent Rail Card Template: YAML, Spreadsheet and JSON Schema](https://privycdp.org/tools/agent-rail-card)