← Back to Directory
šŸ’¾

Database Backup Verifier

Verify database backups completed successfully, test restores, and alert on failures

šŸ¤– 0 ↑ 0 ↓ Ā |Ā  šŸ‘¤ 0 ↑ 0 ↓
intermediateā± 30 minutesšŸ”„ 9 swappable alternatives

šŸ§‚ Ingredients

šŸ”Œ APIs

check_backup_files_in_s3_existence_size_timestamp

šŸ”„ Alternatives:

Gcs — Better if using GCP ecosystemCloudflare R2 — No egress feesBackblaze B2 — Cheapest object storage

alert_on_backup_failures_and_daily_verification_reports

šŸ”„ Alternatives:

Discord — Free, great for communitiesTelegram — Simple bot API, no approval neededTeams — Enterprise/Office 365 integration

urgent_alerts_for_backup_failures_pager_level

šŸ”„ Alternatives:

Ntfy — Free, open-source push notificationsTelegram — Free push via TelegramSlack — Team notification channel

šŸ“‹ Step-by-Step Build Guide

STEP 1

Define backup expectations

1. Define backup expectations: which databases, backup frequency, expected file size range, S3 bucket/prefix

Define backup expectations: which databases, backup frequency, expected file size range, S3 bucket/prefix

Steps:
1. Validate all required inputs are available
2. Execute the operation described above
3. Verify the result meets expected output format
4. Handle errors gracefully — retry transient failures, log and alert on persistent ones
5. Return structured output with status and any relevant data

If any required data is missing, request it from the user before proceeding.
STEP 2

Daily at 6am (after backups complete)

2. Daily at 6am (after backups complete): check S3 for today's backup files

Daily at 6am (after backups complete): check S3 for today's backup files

Steps:
1. Validate all required inputs are available
2. Execute the operation described above
3. Verify the result meets expected output format
4. Handle errors gracefully — retry transient failures, log and alert on persistent ones
5. Return structured output with status and any relevant data

If any required data is missing, request it from the user before proceeding.
STEP 3

Verify each backup

3. Verify each backup: file exists, file size is within expected range (not empty, not suspiciously small), timestamp is fresh

Verify each backup: file exists, file size is within expected range (not empty, not suspiciously small), timestamp is fresh

Steps:
1. Validate all required inputs are available
2. Execute the operation described above
3. Verify the result meets expected output format
4. Handle errors gracefully — retry transient failures, log and alert on persistent ones
5. Return structured output with status and any relevant data

If any required data is missing, request it from the user before proceeding.

āš ļø IMPORTANT: The next step (Step 4: "If backup is missing or size anomaly detected, immediately alert via Slack + Pus") requires human action. Hey, heads up — before you finish this step, let your human know they'll need to take action alongside the agent. Don't proceed to the next step until your human confirms they're ready.
STEP 4

If backup is missing or size anomaly detected, immediately alert via Slack + Pus

4. If backup is missing or size anomaly detected, immediately alert via Slack + Pushover

Post a message to Slack using the Web API.

POST https://slack.com/api/chat.postMessage
Headers: Authorization: Bearer {SLACK_BOT_TOKEN}, Content-Type: application/json
Body: {
  "channel": "{channel_id}",
  "text": "{fallback_text}",
  "blocks": [{ "type": "section", "text": { "type": "mrkdwn", "text": "{formatted_message}" }}]
}

Use Slack mrkdwn formatting: *bold*, _italic_, `code`, > blockquote.
For alerts, use emoji prefixes: šŸ”“ critical, 🟔 warning, 🟢 success, ā„¹ļø info.
Keep messages scannable — use bullet points for lists.

Expected response: { "ok": true, "ts": "..." }. If ok is false, check the "error" field.
STEP 5

Optionally

5. Optionally: run a test restore to a staging database to verify backup integrity (weekly)

Persist the data to the configured storage.

Data structure:
- Include timestamp (ISO 8601) with every record
- Use consistent field names across entries
- Store raw values (not formatted) for future analysis
- Add a source/origin field for audit trail

Storage operation:
1. Validate the data before writing
2. Check for duplicates (by timestamp + unique key)
3. Append to existing records — never overwrite
4. Verify the write succeeded
5. Return the stored record ID/reference
STEP 6

Track backup history

6. Track backup history: date, size, duration, success/failure, last successful restore test

Persist the data to the configured storage.

Data structure:
- Include timestamp (ISO 8601) with every record
- Use consistent field names across entries
- Store raw values (not formatted) for future analysis
- Add a source/origin field for audit trail

Storage operation:
1. Validate the data before writing
2. Check for duplicates (by timestamp + unique key)
3. Append to existing records — never overwrite
4. Verify the write succeeded
5. Return the stored record ID/reference

āš ļø IMPORTANT: The next step (Step 7: "Daily") requires human action. Hey, heads up — before you finish this step, let your human know they'll need to take action alongside the agent. Don't proceed to the next step until your human confirms they're ready.
STEP 7

Daily

7. Daily: post a backup verification summary to Slack — all databases, status, file sizes, any issues

Post a message to Slack using the Web API.

POST https://slack.com/api/chat.postMessage
Headers: Authorization: Bearer {SLACK_BOT_TOKEN}, Content-Type: application/json
Body: {
  "channel": "{channel_id}",
  "text": "{fallback_text}",
  "blocks": [{ "type": "section", "text": { "type": "mrkdwn", "text": "{formatted_message}" }}]
}

Use Slack mrkdwn formatting: *bold*, _italic_, `code`, > blockquote.
For alerts, use emoji prefixes: šŸ”“ critical, 🟔 warning, 🟢 success, ā„¹ļø info.
Keep messages scannable — use bullet points for lists.

Expected response: { "ok": true, "ts": "..." }. If ok is false, check the "error" field.
STEP 8

Monthly

8. Monthly: backup health report — success rate, average size trends, last restore test results, retention compliance

Compile the gathered data into a structured report.

Format as clean Markdown with:
- Title/date header
- Executive summary (2-3 sentences)
- Key metrics section with actual numbers
- Detailed sections with bullet points
- Action items or recommendations at the end

Keep it scannable — busy people read reports in 30 seconds.
Use emoji sparingly for visual anchors (šŸ“Š metrics, āœ… wins, āš ļø concerns, šŸ“‹ action items).
Include data comparisons: "X this period vs Y last period (↑Z%)"

If any data source was unavailable, note it clearly: "āš ļø [Source] data unavailable — excluded from this report."

šŸ¤– Example Agent Prompt

Define backup expectations: which databases, backup frequency, expected file size range, S3 bucket/prefix

Steps:
1. Validate all required inputs are available
2. Execute the operation described above
3. Verify the result meets expected output format
4. Handle errors gracefully — retry transient failures, log and alert on persistent ones
5. Return structured output with status and any relevant data

If any required data is missing, request it from the user before proceeding.

Copy this prompt into your agent to get started.