Agent skill

Backups

by ericrisco in ericrisco/rsc-harness

A skill your agent uses when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite…

MITAuto-check passedDevOps & Cloud

Install Backups

skills CLI
$ npx skills add ericrisco/rsc-harness --skill backups -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ericrisco/rsc-harness backups --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ericrisco/rsc-harness.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/backups .claude/skills/backups && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
backups
GitHub stars
156
Token cost
~2.7k tokens
SKILL.md length
1,492 words
Files
6 (incl. scripts, references)
Skills in repo
229
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite…

  • Works in 7 steps: Decide RPO and RTO first — numbers, not… → The 3-2-1-1-0 layout → Pick the mechanism per data store → …
  • Auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets
  • SKILL.md covers Start here, 1. Decide RPO and RTO first —…, 2. The 3-2-1-1-0 layout and 3. Pick the mechanism per data…, plus 5 more sections
  • Runs Shell scripts from its folder

What it does

Backups is an agent skill from ericrisco/rsc-harness. Use when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite and immutable, wiring point-in-time recovery, and proving restores work on a schedule. NOT tuning Postgres internals or writing the archivecommand (that is postgresdb).

Its SKILL.md is about 2.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 8 other files, including scripts and reference files (for example `evals/README.md`, `evals/cases.yaml` and `references/engine-recipes.md`).

It sits in DevOps & Cloud, covering Backup and disaster recovery. It works with PostgreSQL. The repository describes itself as: Your agent invents things because it has no memory, and can't touch your database because it has no arms. rsc is the meta-harness that gives it both, plus the trade to know the… The licence is MIT.

When your agent uses it

  • Auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets
  • Laying out 3-2-1-1-0 copies that are offsite and immutable
  • Wiring point-in-time recovery
  • Proving restores work on a schedule

Example prompts

  • “/backups”

Requirements

  • A Bash shell

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Decide RPO and RTO first — numbers, not adjectives
  2. The 3-2-1-1-0 layout
  3. Pick the mechanism per data store
  4. PITR, generically
  5. Offsite + immutability
  6. The tested restore — this is the part everyone skips
  7. Verify & monitor

What it can do on your machine

Read from SKILL.md and the folder at commit 92fde8f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Shell), which the agent can run.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Backups loads about 2.7k tokens when it runs, and up to ~4.7k if it reads all its reference files. Until then it costs about 89 tokens; SKILL.md has 1,492 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~89
When it runs · the whole SKILL.md, loaded when a task matches
~2.7k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from ericrisco/rsc-harness at commit 92fde8f, republished under its MIT licence (© ericrisco). 1,492 words, ~2,749 tokens.

Download SKILL.mdSave it as .claude/skills/backups/SKILL.md (or your agent's skills folder). This skill also uses 5 other files; get the full folder from GitHub.
name
backups
description
Use when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite and immutable, wiring point-in-time recovery, and proving restores work on a schedule. NOT tuning Postgres internals or writing the archive_command (that is `postgresdb`).
tags
backups, disaster-recovery, pitr, rpo-rto, restore
recommends
postgresdb, secure-coding, monitoring
origin
risco

Backups & disaster recovery

Start here

One question decides whether you have backups or a hope: if you restored right now, would it work — and how do you know?

If the answer is "we have a nightly job and it hasn't errored," you do not have backups. You have a job. A backup you have never restored is an untested assertion about the future. This skill exists to turn that assertion into evidence: pick the numbers, lay out the copies so ransomware can't reach them, and run a real restore on a schedule so the answer becomes "yes, we restored it last Tuesday in 41 minutes."

This is the cross-engine strategy + verification skill. Engine-specific SQL knobs (the actual archive_command, VACUUM, schema migrations) belong to ../postgresdb/SKILL.md. Encryption-key management as a general security control belongs to ../secure-coding/SKILL.md.

1. Decide RPO and RTO first — numbers, not adjectives

Everything downstream derives from two numbers. Never start from "what does the tool do."

  • RPO = maximum acceptable data loss, the gap between the disaster and your last good copy. It sets backup frequency. "RPO 1 hour" means a copy at least hourly.
  • RTO = maximum acceptable downtime until you're serving again. It sets topology: a snapshot restore is hours; a warm standby you promote is minutes.

Get a real number from whoever owns the revenue, not "as little as possible." Then map it:

RPO targetRequired cadence + mechanism
24 hNightly full/snapshot is enough
~5 minContinuous change-log shipping: WAL / binlog / transaction-log → PITR
~0Synchronous replica plus PITR (the replica covers hardware loss, PITR covers the bad DELETE)
RTO targetRequired topology
HoursRestore from snapshot / object-storage backup is fine
MinutesWarm standby or read-replica you promote; pre-provisioned restore target
SecondsMulti-AZ / failover cluster (and you still need backups for logical corruption)

Rule: a replica is not a backup — it faithfully replicates your DROP TABLE in milliseconds. You need point-in-time recovery to step back before the mistake.

2. The 3-2-1-1-0 layout

The classic 3-2-1 rule grew two digits because ransomware now targets the backup infrastructure itself in ~96% of attacks — an attacker who can delete your backups has no reason to fear your backups. The current rule:

  • 3 copies of the data (production + 2 backups). Why: one extra copy still dies with a correlated failure.
  • 2 different media / storage types. Why: a single storage class has a single failure mode.
  • 1 offsite. Why: fire, flood, region outage, or a billing-locked cloud account kills everything in one place. Offsite ≠ another folder on the same host.
  • 1 immutable or offline. Why: a mutable copy an attacker (or a buggy script) can delete is not a safety net. See §5.
  • 0 verification errors. Why: an unverified backup is Schrödinger's backup — both good and corrupt until you restore it. See §6–7.

Map it concretely: production Postgres (copy 1) → pgBackRest repo on local disk, different media (copy 2) → same repo replicated to an S3 bucket in another region with Object Lock (offsite + immutable) → pgbackrest verify + a scheduled test restore (the 0).

3. Pick the mechanism per data store

PITR availability is the column that decides whether you can hit a sub-hour RPO.

Data storeToolPITR?The one gotcha
Managed DB (RDS, Cloud SQL, Supabase, Neon)Built-in automated backupsYesSet retention to your real window; know the ceiling (RDS caps at 35 days). Add a cross-region/cross-account copy you control.
Self-hosted PostgreSQLpgBackRest or WAL-G + WAL archivingYesSingle-threaded archive_command falling behind = WAL storm (see §4). Use archive-async=y.
MySQL / MariaDBPercona XtraBackup + binlogYes (binlog)mysqldump alone has no PITR — you also need --single-transaction and binlog shipping.
RedisRDB snapshot + AOFPartialCache-first caveat: if Redis is just a cache, a backup may be pointless; if it's a system of record, enable AOF everysec and treat it like a DB.
Files / app data + object storagerestic or BorgBackup → Object-Lock bucketn/a (versions)Both dedup + AES-256 encrypt. restic = concurrent shared repos + faster restore; Borg = smaller repos but one exclusive lock per repo.
App config / secretsVersioned + encrypted storen/aBack these up too, or your restored DB has nothing to connect to. Key must live somewhere the disaster doesn't.

Concrete copy-paste config (pgBackRest stanza, RDS CLI, XtraBackup, restic/Borg) lives in references/engine-recipes.md.

4. PITR, generically

The model is the same for every engine that supports it: a base/full backup + a continuous change log replayed forward to a target time.

text
base backup (T0) ──► change log: WAL / binlog / txn-log ──► replay to "2026-06-02 13:59:00"

You restore the base, then replay the log up to one second before the bad event. That second is why PITR beats snapshots for logical corruption.

  • Amazon RDS: a daily automated snapshot plus transaction logs shipped to S3 every 5 minutes, restorable to any second within a retention window of up to 35 days. Snapshots after the first are incremental. Trap: AWS Backup does not support a PITR restore into another region — you can copy the backup cross-region, but the restore-to-a-point-in-time happens in the original region. Plan failover accordingly.
  • Self-hosted Postgres traps (both kill PITR silently):
    • WAL storm: a single-threaded archive_command can't keep up under write load, pg_wal/ fills the disk, and Postgres stops accepting writes. Use async/parallel archiving (archive-async=y, --process-max tuned to disk count — it's I/O-bound, not CPU-bound).
    • Retention trap: expiring WAL too aggressively means the chain to your target time is gone and PITR fails. Retain WAL at least as long as your oldest restorable full backup.

Engine commands are in references/engine-recipes.md. For the Postgres-internals side of this (writing the archive_command, tuning), use ../postgresdb/SKILL.md.

Show full SKILL.md (592 more words)Show less

5. Offsite + immutability

  • Immutable = Object Lock / WORM on the backup bucket: copies cannot be edited or deleted until the retention window expires, even by a root key. Enable it on a dedicated backup bucket.
  • Retention ≥ 90 days. A 30-day default is often too short: malware commonly dwells for weeks before triggering, so a 30-day lock can expire on the very copies that predate the infection. 90+ days outlives typical dwell time.
  • Offsite means a different blast radius, not a different folder. Different region, and ideally a different account/project with separate credentials — so a compromised application key cannot reach in and delete the backups. The app that writes backups should not hold the key that can delete them.

6. The tested restore — this is the part everyone skips

The number-one reason PITR fails in a real disaster is that it was never tested. Schedule restores like you schedule backups.

TestCadenceScope
File / single-object restoreMonthlyPull one file/table back, in an isolated env, confirm integrity
Application recoveryQuarterlyStand up the app against the restored data, run smoke queries
Full-environment failoverAnnuallyRebuild the whole stack from backups in an isolated account/region

Rules:

  • Always restore into an isolated environment — never over production, never sharing its credentials.
  • Record the actual recovery time every run and update your RTO to that reality. An RTO of "4 hours" that you've never measured is fiction.
  • A restore test that "looks fine" isn't done until you've run a validation query / row-count / checksum that proves the data is correct, not just present.

The fill-in-the-blank restore runbook, the scheduled-test checklist, and the actual-RTO log format are in references/restore-runbook.md.

7. Verify & monitor

  • Integrity-verify the backups themselves: restic check / borg check / pgbackrest verify re-read and checksum chunks. A backup that won't pass check won't restore.
  • Alert on three conditions: a backup job failed, the newest good backup is older than your RPO (backup-age check — silence is the dangerous failure mode), and a restore test is overdue.
  • Wiring those alerts into a metrics/paging stack is a monitoring concern — own the what to alert on here, hand the how to ../monitoring/SKILL.md.

Anti-patterns

Anti-patternWhy it bitesDo instead
Backups on the same host/disk as the sourceOne disk/host failure takes the source and the backup togetherOffsite copy, different blast radius (§2)
Never test-restoredThe restore fails for the first time during the disasterMonthly/quarterly/annual scheduled restores (§6)
"The replica is our backup"It replicates your DROP TABLE faithfullyReplica for RTO, PITR for the bad write (§1)
Mutable bucket the app key can deleteRansomware/compromised key wipes backups tooObject Lock + separate credentials (§5)
30-day retention onlyMalware dwell time outlasts the lockRetention ≥ 90 days (§5)
pg_dump/dump to /tmpReboot or full disk silently loses it; no PITRDedicated repo + WAL/binlog shipping (§3–4)
RPO promised, cadence can't meet it"RPO 5 min" with a nightly job = up to 24 h lossDerive cadence from RPO first (§1)
Single-threaded archive_command under loadWAL storm fills pg_wal, writes stopAsync/parallel archiving (§4)
Encrypted backup, key only in the vault that's goneBackup is recoverable but unreadableStore the key in a separate blast radius (§3)
Trusting managed snapshots without knowing the ceilingRDS caps at 35 days; longer needs an exported copyKnow the retention ceiling, export beyond it (§3)
Counting "job succeeded" as successThe job wrote a corrupt/empty archivecheck/verify + a real test restore (§6–7)

scripts/verify.sh <path-to-policy-or-runbook> lints a produced backup-policy/runbook artifact for the five pillars (RPO, RTO, offsite, immutability, scheduled-restore + verification). It is a completeness lint, not a backup executor.

© ericrisco, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 5 other files (scripts, references) in skills/backups of ericrisco/rsc-harness.

  • SKILL.md
  • evals/README.md
  • evals/cases.yaml
  • references/engine-recipes.md
  • references/restore-runbook.md
  • scripts/verify.sh

Open the folder on GitHubat commit 92fde8f

Compare with similar skills

Backups next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Backups compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Backups this skillericrisco/rsc-harness156—~2.7kAutomated safety check: PassMIT
Mg Local DB Restoremodelguide/modelguide108—~645Automated safety check: PassMIT
Azure Resource Manager Postgresql Dotnetmicrosoft/skills3.1k6 repos~4kAutomated safety check: PassMIT
Planetscale Postgres Safety Reviewplanetscale/skills132—~2.4kAutomated safety check: PassMIT
Database Adminaiskillstore/marketplace4306 repos~2.5kAutomated safety check: PassNone
Postgres Backup Restorefmflurry/settings-opencode171—~2.3kAutomated safety check: PassMIT

Similar skills

  • Mg Local DB Restore

    modelguide/modelguide

    Trigger phrases - "reset local db", "recreate local postgres", "restore dump to local", "reset local database", "load backup locally"

    108 GitHub stars~645 tokensUpdated 3 mo ago
    DevOps & CloudAuto-check passed
  • Azure PostgreSQL Flexible Server SDK for .NET. An agent skill from microsoft/skills.

    3.1k GitHub starsUsed in 6 repos~4k tokens
    DevOps & CloudAuto-check passed
  • Official

    Review PlanetScale Postgres for Traffic Control, query tags, roles, pgstrict, backups/PITR, private connectivity, webhooks, branches, and safe agent operation.

    132 GitHub stars~2.4k tokensUpdated 4 days ago
    DevOps & CloudAuto-check passed
  • Database Admin

    aiskillstore/marketplace

    Expert database administrator specializing in modern cloud databases, automation, and reliability engineering.

    430 GitHub starsUsed in 6 repos~2.5k tokens
    DevOps & CloudAuto-check passed
  • Postgres Backup Restore

    fmflurry/settings-opencode

    PostgreSQL backup & restore playbook for the docker instance: pgdump/pgdumpall recipes, WAL archiving + PITR setup (archivemode, archivecommand, recovery.signal, recoverytargettime, timelines)…

    171 GitHub stars~2.3k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed
  • Headscale Backup

    magnus919/agent-skills

    Manage Headscale backups, restores, or migrations with a verified SQLite snapshot and explicit recovery paths before upgrades, host moves, or disaster recovery; do not use for server deployment…

    111 GitHub stars~1.4k tokensUpdated yesterday
    DevOps & CloudAuto-check passed

More from ericrisco/rsc-harness

All 229 skills in this repo
  • Ab Testing

    ericrisco/rsc-harness

    A skill your agent uses when designing or analyzing a controlled experiment — falsifiable hypothesis, sample size from an MDE, reading significance/CI/power, CUPED, or rescuing tests that won't go…

    156 GitHub stars~2.4k tokensUpdated today
    Auto-check passed
  • Accessibility

    ericrisco/rsc-harness

    A skill your agent uses when making a web UI conform to WCAG 2.2 Level AA — axe-core or Lighthouse a11y violations, keyboard operability, focus management, ARIA roles/names/live regions, contrast…

    156 GitHub stars~3.4k tokensUpdated today
    Auto-check passed
  • Ads

    ericrisco/rsc-harness

    A skill your agent uses when running or fixing paid acquisition on Google or Meta — campaign structure (Performance Max, Demand Gen, Search, Advantage+), platform-fit creative, budget/scaling rules…

    156 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Agent Eval

    ericrisco/rsc-harness

    A skill your agent uses when measuring whether an LLM or agent system actually got better and gating merges on it: golden sets, fixing an inflated LLM-as-judge, scoring RAG (faithfulness, contextual…

    156 GitHub stars~3.2k tokensUpdated today
    Auto-check passed
  • AI Media

    ericrisco/rsc-harness

    A skill your agent uses when a creative goal must become a finished media file: pick and order generative-media models per modality — AI voiceover, image-to-video clips, score — then glue them with…

    156 GitHub stars~3.3k tokensUpdated today
    Auto-check passed
  • Analytics

    ericrisco/rsc-harness

    A skill your agent uses when instrumenting product or web analytics — GA4/PostHog SDK wiring, event taxonomy, funnels, double-counted events, consent gating, PII scrubbing.

    156 GitHub stars~2.8k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Backups

What does Backups do?

A skill your agent uses when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite…. Backups is an agent skill from ericrisco/rsc-harness. Use when designing or auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets, laying out 3-2-1-1-0 copies that are offsite and immutable, wiring point-in-time recovery, and proving restores work on a schedule.

When should I use Backups?

Backups fits situations like: auditing a backup-and-restore program that must survive a real disaster: setting defensible RPO/RTO targets; laying out 3-2-1-1-0 copies that are offsite and immutable; wiring point-in-time recovery; proving restores work on a schedule.

How do I install Backups in Claude Code?

Run `npx skills add ericrisco/rsc-harness --skill backups -a claude-code`. Or copy the skill folder (skills/backups in ericrisco/rsc-harness) into .claude/skills/backups in your project. Claude Code loads it when a task matches its description.

How do I install Backups in Codex?

Run `npx skills add ericrisco/rsc-harness --skill backups -a codex`. Or copy the skill folder (skills/backups in ericrisco/rsc-harness) into .agents/skills/backups in your project. Codex loads it when a task matches its description.

Can I use Backups in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ericrisco/rsc-harness --skill backups -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/backups, .gemini/skills/backups, .github/skills/backups and .opencode/skills/backups in your project.

What does Backups need to run?

Going by SKILL.md and its folder, Backups needs a shell for the scripts in its folder. Our summary lists: A Bash shell.

Does Backups access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Backups safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Backups use?

Backups is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Backups use?

About 2.7k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2k tokens, read only when the agent opens those files.

What are the alternatives to Backups?

Skills that share tags, products or a category with Backups: Mg Local DB Restore (modelguide/modelguide, 108 stars), Azure Resource Manager Postgresql Dotnet (microsoft/skills, 3.1k stars), Planetscale Postgres Safety Review (planetscale/skills, 132 stars) and Database Admin (aiskillstore/marketplace, 430 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Backups?

ericrisco (a GitHub user) maintains it in ericrisco/rsc-harness, which has 156 GitHub stars. The repository holds 229 skills in this directory. The repository was last updated on October 6, 2026.

Source: ericrisco/rsc-harness on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.