Hire an AI database recovery planner

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• Recovery targets in plain words, and whether your current setup can meet them.
• A restore test plan with the steps, the checks to run and what to measure.
• A failover plan and drill that avoids promoting a copy that is behind.
• A safe change plan for a table, with lock limits, batches and a way back.
• Limits for connections, the alerts to set and a drill schedule.

How it does the job well

• An untested backup is not a backup. Every backup plan includes a restore to a spare server, data checks and a measured recovery time.
• Do not promise a recovery time. Say it must be measured by a drill.
• Never promote a replica that is behind without stating the data it could lose. Replication lag is a correctness risk, not only a number.
• Every failover, migration and large delete has a written way back and a note of what it could affect before it runs.
• Table changes are split into short steps. Each step has a lock time limit and a statement time limit and is retried off peak on timeout. Even small changes can take locks. State which lock behaviour you assume, and ask the user's database admin to check it against the engine's own docs for that version.
• An untested backup is not a backup. Backups that have never been restored are a hope, not a recovery plan. Automate restore verification on a schedule and measure the actual RTO — the first time you test a restore must never be during an incident.
• Know your RPO and RTO, and prove you meet them. How much data can you lose (RPO) and how long can you be down (RTO)? These are business decisions with technical consequences. Design backup frequency, replication, and failover to hit them, then verify with drills.

Mistakes it avoids

• Tuning queries or indexes. Point to the Database Optimizer agent.
• Multi-region designs when the user runs one small database. Match the size they gave you.
• Copying the profile's SQL or topology as the user's design without fitting it to their engine.
• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: You have backups but have never restored one, and want a way to prove they work.

• Scope. Your engine, hosting and the assumptions the plan is built on.
• Recovery targets. Your data loss and downtime limits, and whether today's setup can meet them.
• Backup and restore test plan. The steps to restore a backup to a spare server, what to check and the time to measure.
• Failover plan and drill. How a new main server is chosen and the drill that proves it works.
• Safe change plan. A table change in small steps with lock limits, batches and a way back.
• Connections and alerts. Connection limits and alerts for copy delay, backup age and overdue drills.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Set the recovery targets. It asks how much data you can lose and how long you can be down, then marks any answer it is missing.
• Check the backup and copy setup. It compares what you have with those targets and names the gaps.
• Plan the restore test. It plans a scheduled restore on a spare server, with checks on the data and a measured time.
• Plan the failover drill. It plans how the system picks the new main server, avoids a stale copy and repoints the app.
• Plan safe table changes. It splits a change into small steps with short lock limits, batched updates and a way back.
• Plan limits and alerts. It sets connection limits and alerts for copy delay, backup age and drill dates.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-database-reliability-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-database-reliability-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The database engine and version, such as PostgreSQL or MySQL, and whether it is managed (for example by your cloud provider) or run by you.
• How you back up today and how often, and the tool you use.
• How much data you can lose and how long you can be down. If you do not know, say so.
• Your copy setup, such as one main server and one or more replicas (optional)
• The last time you restored a backup or ran a failover (optional)
• A table change you plan, and roughly how big and how busy the table is (optional)

Helpful context (optional)

• Your backup tool settings and the last backup report.
• A diagram or note of your main server and its replicas.
• The table you want to change, with its size and busiest hours.

Tools and access

• Claude, ChatGPT or Gemini: A strong reasoning model keeps recovery and lock risks straight. No code running or web access is needed. Check engine details against its own docs.

Functions and deliverables

• Database recovery planner: Check that your database can be restored and will fail over safely. Get a backup test plan, a failover drill and a safe way to change tables.
  • Recovery targets in plain words, and whether your current setup can meet them.
  • A restore test plan with the steps, the checks to run and what to measure.
  • A failover plan and drill that avoids promoting a copy that is behind.
  • A safe change plan for a table, with lock limits, batches and a way back.
  • Limits for connections, the alerts to set and a drill schedule.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Database backup setup helper: Get database backup scripts, a schedule, a retention rule and a restore test for PostgreSQL, MySQL or MongoDB. Know your backups work before you need them.
  • Backup scripts
  • Schedule and retention rule
  • Integrity check and restore test
  • Failure alert setup
  Source: Burhan Sebin.
• Backup and recovery planner: Describe systems and agreed loss and downtime limits. Get a backup plan, restore steps and drills, with results when actually run.
  • A list of your systems ranked by how much you need them back
  • Recovery targets for each rank
  • A backup design, or a review of what you have
  • A restore guide for each system
  • A drill plan and a schedule for the next drill
  Source: RampStack.
• Safe database query runner: Ask a question about your Postgres data in plain words. Get a read-only SQL query run for you, with the results back and write commands blocked.
  • A list of your databases and tables
  • The read-only SQL it wrote and ran
  • The rows that came back, with the row count
  • A short plain answer to your question
  • A clear refusal if a command would write
  Source: sickn33.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• You have backups but have never restored one, and want a way to prove they work.
• Someone asks "what happens if the main database server dies?" and you do not have a tested answer.
• You must change a table on a busy database, such as adding a column, without freezing the app.
• Your app runs out of database connections under load, even when the database looks idle.

Limits to check before starting

• Your database is down or losing data right now. Follow your own runbook and call your database admin or provider. For a live outage, use the Incident response coordinator to run the response.
• You want slow queries and missing indexes fixed. Use the Database performance analyst.
• You want goals and alerts for a whole service, not just the database. Use the SRE agent.
• You want it to run restores, failovers or changes. It writes the plan. Your team runs it on a spare copy first.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack and add it to your AI as a skill. If you cannot, paste SKILL.md into a new chat, then paste references/source-agent.md.
• Write your engine and version, how you host it, your backup tool and schedule, and your data loss and downtime limits. No database access is needed.
• Type "Plan recovery for this database. Start with the restore test. Ask for any limit I did not give. Mark every assumption."
• Check the restore test first. It must restore to a spare server and measure the real time.
• Run the restore test and the drill on a spare copy, never on production. Write down what you measure.
• Give any table change plan to your database admin to check against your engine's own docs before it runs.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-database-reliability-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.