Run any Skill in Manus with one click

db-backup-restore

Stars2

Forks0

UpdatedJune 14, 2026 at 10:45

Safely back up and restore a Postgres/Supabase database — pg_dump/pg_restore, Supabase backups/PITR, and a no-data-loss restore runbook. Use before risky migrations, for disaster recovery, or when cloning prod to staging.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

m-binimran

m-binimran/dev-pack

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Database ArchitectsComputer and Mathematical Occupations·SOC 15-1243

SKILL.md

readonly

name	db-backup-restore
description	Safely back up and restore a Postgres/Supabase database — pg_dump/pg_restore, Supabase backups/PITR, and a no-data-loss restore runbook. Use before risky migrations, for disaster recovery, or when cloning prod to staging.

db-backup-restore

Backups are only real if you've restored one. Treat restore as the thing you're actually buying.

Back up

Logical (portable): pg_dump --format=custom --no-owner --file=backup.dump "$DATABASE_URL". Custom format restores selectively and in parallel.
Supabase: managed daily backups; enable Point-in-Time Recovery (PITR) for anything important.
Before a risky migration: take a fresh dump first. Note the timestamp and what it covers.
Store backups off the database host. Never commit a dump (it's data — and may contain PII).

Restore (runbook)

Restore into a NEW/empty target first (staging or a scratch DB), never straight over a live one: pg_restore --no-owner --clean --if-exists -d "$TARGET_URL" backup.dump
Verify row counts and a few key records match expectations before pointing anything at it.
Only then, if replacing prod, do it in a maintenance window with a fresh backup taken immediately prior.

Safety

Never restore over production without an explicit human OK and a just-taken backup. A restore is destructive — it can overwrite newer data.
Test the restore path periodically; an untested backup is a hope, not a recovery plan.
Scrub or limit PII when cloning prod → staging.

Output

The exact backup/restore commands for the situation, the target (never prod by default), and the verification step. State clearly when an action is destructive.

More from this repository

same repository

claude-pack-builder

m-binimran/dev-pack

Design, build, verify, and publish a curated Claude Code pack — a reusable collection of rules, skills, hooks, loops, and review agents — to GitHub. Trigger this skill whenever the user wants to "create a Claude Code pack", "build a rules/hooks/skills collection", "make a guardrail pack", "package my hooks/skills/agents", "publish a Claude Code config to GitHub", or assemble enforced standards for a stack (e.g. Next.js + Supabase, Django, etc.). This skill is the methodology that produced github.com/m-binimran/dev-pack; reuse it instead of re-deriving the process. Run it BEFORE writing any pack files — it sequences research, clarification, building, verification, and safe publishing.

2026-06-142

a11y-audit

m-binimran/dev-pack

Audit a web page/component against WCAG 2.2 AA — semantics, keyboard, contrast, labels, focus, alt text. Use when reviewing UI for accessibility or before shipping a page.

2026-06-142

animation-implement

m-binimran/dev-pack

Implement web animations with the right engine (Motion, GSAP, Anime.js, React Spring, tailwindcss-motion) and a mandatory prefers-reduced-motion fallback at 60fps. Use when adding any motion to a site.

2026-06-142

api-design

m-binimran/dev-pack

Design Next.js route handlers and server actions with input validation, correct status codes, error handling, and rate limiting. Use when building an API endpoint, server action, or webhook receiver.

2026-06-142

caching-revalidation

m-binimran/dev-pack

Get Next.js App Router caching right — static vs dynamic rendering, fetch cache, revalidatePath/revalidateTag, and ISR. Use when data is stale, a page won't update, or you're tuning performance vs freshness.

2026-06-142

component-scaffold

m-binimran/dev-pack

Build a production React component on shadcn/ui + Tailwind — variants, compound pattern, accessible states, and a clean prop API. Use when creating a new UI component or refactoring a messy one.

2026-06-142

name	db-backup-restore
description	Safely back up and restore a Postgres/Supabase database — pg_dump/pg_restore, Supabase backups/PITR, and a no-data-loss restore runbook. Use before risky migrations, for disaster recovery, or when cloning prod to staging.

db-backup-restore

Backups are only real if you've restored one. Treat restore as the thing you're actually buying.

Back up

Logical (portable): pg_dump --format=custom --no-owner --file=backup.dump "$DATABASE_URL". Custom format restores selectively and in parallel.
Supabase: managed daily backups; enable Point-in-Time Recovery (PITR) for anything important.
Before a risky migration: take a fresh dump first. Note the timestamp and what it covers.
Store backups off the database host. Never commit a dump (it's data — and may contain PII).

Restore (runbook)

Restore into a NEW/empty target first (staging or a scratch DB), never straight over a live one: pg_restore --no-owner --clean --if-exists -d "$TARGET_URL" backup.dump
Verify row counts and a few key records match expectations before pointing anything at it.
Only then, if replacing prod, do it in a maintenance window with a fresh backup taken immediately prior.

Safety

Never restore over production without an explicit human OK and a just-taken backup. A restore is destructive — it can overwrite newer data.
Test the restore path periodically; an untested backup is a hope, not a recovery plan.
Scrub or limit PII when cloning prod → staging.

Output

The exact backup/restore commands for the situation, the target (never prod by default), and the verification step. State clearly when an action is destructive.