Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/selvarajmurugesan90/ops-engineering-skillsnpx agentmods add skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategiesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategies)<a href="https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategies"><img src="https://agentmods.dev/badge/skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategies/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategies"><img src="https://agentmods.dev/badge/skills/selvarajmurugesan90/ops-engineering-skills/database-backup-and-restore-strategies.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Data Exfiltration · line 333 Data is uploaded to cloud storage (S3 / GCS / Azure Blob). This may be a legitimate backup or exfiltration to an external bucket. Manual review is recommended.Fix: Verify the destination bucket is trusted and owned by you. Never upload credentials, secrets, or workspace contents to external or unverified cloud storage.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00139 | $0.04329 |
| Opus 5 | $0.00069 | $0.02165 |
| Sonnet 5 | $0.00028 | $0.00866 |
| Haiku 4.5 | $0.00014 | $0.00433 |
Grade A, and why
database-backup-and-restore-strategies scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 357 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Database Backup and Restore Strategies
Purpose
A backup that has never been restored is a hypothesis, not a safety net — the single most common cause of a "we had backups but couldn't recover" incident is a backup process that ran successfully (per its own logs/exit code) but produced an artifact that was never actually tested end-to-end against a real restore. This skill covers the dominant backup tooling for the three most common relational/document engines — pg_dump/pg_basebackup for PostgreSQL, mysqldump/Percona XtraBackup for MySQL/MariaDB, and mongodump/mongorestore for MongoDB — the logical-vs-physical backup trade-off that applies across all of them, and the restore- testing discipline that turns a backup process into an actual, provable recovery capability rather than an assumption.
When to use
- Designing a new backup strategy for a database that doesn't have one, or auditing an existing one for gaps (untested restores, missing point-in-time recovery, retention that doesn't match compliance requirements).
- Choosing between a logical backup (
pg_dump,mysqldump,mongodump) and a physical backup (pg_basebackup, XtraBackup, a filesystem/volume snapshot) for a specific database's size and recovery-time requirements. - Setting up point-in-time recovery (PITR) so a restore can target a specific moment (e.g. just before an accidental destructive operation) rather than only the last full backup.
- A restore attempt fails, is much slower than expected, or produces data that doesn't match what was expected.
- Before any operation flagged destructive elsewhere in this repo
(
TRUNCATE,DROP DATABASE/DROP KEYSPACE, an untested migration rollback, a retention policy that permanently deletes data) — this skill is the prerequisite safety net those warnings point back to.
Prerequisites & environment
- Sufficient storage for backup artifacts, sized for the retention policy (how many historical backups are kept), not just one backup's size — a common under-provisioning mistake.
- Network/IAM access from the backup process to wherever artifacts are stored (object storage, a separate backup host) — credentials scoped specifically to backup write access, not broad database-admin credentials reused for convenience.
- For physical backups: enough free disk/I/O headroom on the source database during the backup window, since streaming a full physical copy is I/O- and often CPU-intensive (compression) while the database continues serving live traffic.
- A separate, isolated environment (not the production database itself) to actually perform restore tests against — a "successful" backup validated only by re-reading the archive's own metadata, without an independent restore, does not confirm the backup is usable.
- For point-in-time recovery specifically: continuous WAL archiving (PostgreSQL), binary log retention (MySQL/MariaDB), or oplog-based replication (MongoDB) already configured and retained for at least as long as the interval between full backups — PITR requires the continuous log, not just periodic full snapshots.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 357 lines · 139 tokens per session scan A 895ebf50dcc6
database-backup-and-restore-strategies is a skill published in the GitHub repository selvarajmurugesan90/ops-engineering-skills (39 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 139 tokens to every session and 4,329 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
fastapi-init-skill
A tool that creates a complete FastAPI web-service starting point, including database choices, login protection, file uploads, streaming responses, API documentation, and start or restart scripts.
ring:mapping-service-resources
Mapping a Go service's Service -> Module -> Resource hierarchy for dispatch-layer registration: detects modules and per-module PostgreSQL/MongoDB/RabbitMQ resources, database names, and shared databases, generates MongoDB index migration pairs (.up.json/.down.json), detects existing Postgres migrations, emits an HTML…
database-expert
Advanced database design and administration for PostgreSQL, MongoDB, and Redis. Use when designing schemas, optimizing queries, managing database performance, or implementing data patterns.
software-database-design
Designs database schemas, migrations, and data models for PostgreSQL, MySQL, MongoDB, and Redis. Use when planning tables, relationships, indexes, or ORM-backed schema changes.
ck:databases
Design schemas, write queries for MongoDB and PostgreSQL. Use for database design, SQL/NoSQL queries, aggregation pipelines, indexes, migrations, replication, performance optimization, psql CLI.
database-migrator
Migrates databases between providers (Postgres, MySQL, Supabase, PlanetScale, MongoDB). Reads source schema, generates migration scripts, handles data type mapping, foreign keys, indexes, triggers, stored procedures. Validates migration with row counts and checksums. Generates migration-plan.md with step-by-step…