home / skills / racar / racar_agent_skills / postgres-backup-restore

postgres-backup-restore skill

/skills/postgres-backup-restore

This skill automates loading PostgreSQL backups into local Docker databases, speeding debugging and QA work with realistic data.

npx playbooks add skill racar/racar_agent_skills --skill postgres-backup-restore

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.1 KB
---
name: postgres-backup-restore
description: Automate loading PostgreSQL backups from SQL files into local databases running in Docker containers for debugging and testing. Use when working with PostgreSQL database backups, restoring QA/production data to local environments, setting up local debugging environments with real data, or when users mention loading/restoring database backups to Docker containers.
---

# PostgreSQL Backup Restore

## Overview

Automate the process of loading PostgreSQL backup files into local databases running in Docker containers. This skill provides both an automated script and manual workflow for restoring database backups, commonly used for debugging with production/QA data in local development environments.

## Quick Start (Automated)

Use the provided shell script to automate the entire process:

```bash
./scripts/restore_backup.sh <backup-file> <container-id> <database-name>
```

**Example:**
```bash
./scripts/restore_backup.sh ~/Descargas/qa-order-service.sql c091f5a68780 order_development
```

**Arguments:**
- `backup-file`: Path to SQL backup file (e.g., `~/Descargas/qa-order-service-06012026-154531.sql`)
- `container-id`: Docker container ID or name (find with `docker ps`)
- `database-name`: Target database name (e.g., `order_development`)

The script will:
1. Copy backup file to container
2. Drop existing database
3. Create fresh database
4. Restore from backup
5. Clean up temporary files

## Manual Workflow

For situations requiring manual control or customization:

### Step 1: Prepare Backup File

Backup files typically have timestamped names. Optionally rename for convenience:

```bash
# Original: qa-order-service-06012026-154531.sql
# Simplified: qa-order-service.sql
mv ~/Descargas/qa-order-service-06012026-154531.sql ~/Descargas/qa-order-service.sql
```

### Step 2: Copy to Container

Find container ID and copy backup:

```bash
# Find running containers
docker ps

# Copy file to container
docker cp ~/Descargas/qa-order-service.sql c091f5a68780:/qa-order-service.sql
```

### Step 3: Enter Container

```bash
docker exec -it c091f5a68780 bash
```

### Step 4: Drop and Recreate Database

Connect to PostgreSQL:

```bash
psql -U postgres
```

Drop and recreate the database:

```sql
DROP DATABASE order_development;
CREATE DATABASE order_development;
\q
```

### Step 5: Restore Backup

Run the SQL script:

```bash
psql -U postgres -d order_development -a -f /qa-order-service.sql
```

### Step 6: Exit

```bash
exit
```

## Common Use Cases

**QA Data to Local:**
Restore QA environment data to debug issues locally with real data scenarios.

**Production Debugging:**
Load production backup (sanitized) to reproduce and debug production-specific issues.

**Database State Testing:**
Test migrations or schema changes against realistic data volumes and structures.

## Troubleshooting

**Container not found:**
```bash
# List all containers (running and stopped)
docker ps -a

# Start a stopped container
docker start <container-id>
```

**Permission denied:**
```bash
# Ensure you have permissions to access the backup file
ls -la ~/Descargas/qa-order-service.sql

# Make script executable
chmod +x scripts/restore_backup.sh
```

**Database already exists error:**
The automated script handles this with `DROP DATABASE IF EXISTS`. For manual workflow, ensure Step 4 is completed.

**Large backup files:**
Restore process may take several minutes for large backups. The automated script suppresses verbose output for cleaner logs.

## Best Practices

1. **Backup filename convention:** Keep timestamped backups for version tracking
2. **Container identification:** Use `docker ps` to verify container is running before restore
3. **Data sanitization:** Ensure production backups are sanitized (PII removed) before local use
4. **Disk space:** Verify sufficient space in container for backup file
5. **Testing:** Test restored database connectivity after completion

## Resources

### scripts/restore_backup.sh

Automated shell script that handles the complete backup restore workflow. Includes error handling, colored output, and automatic cleanup. Can be executed directly without loading into context.

Overview

This skill automates loading PostgreSQL SQL backups into local PostgreSQL databases running in Docker containers for fast debugging and testing. It supplies an automated shell script and a clear manual workflow to copy, drop/recreate, and restore databases from SQL files. Use it to reproduce QA/production issues locally or to set up realistic test environments quickly.

How this skill works

The provided shell script copies a specified SQL backup file into a target Docker container, drops the existing database (if present), creates a fresh database, runs psql to import the SQL file, and removes temporary files. A documented manual workflow describes the same steps for cases that need custom commands or interactive troubleshooting.

When to use it

  • Restoring QA or sanitized production backups into a local Dockerized Postgres for debugging
  • Reproducing production bugs locally with real data snapshots
  • Setting up realistic test data for migration or performance testing
  • Loading a backup into a development container when the automated script needs customization
  • Recovering a local database state from a SQL dump file

Best practices

  • Keep timestamped backup filenames for traceability and easy rollback
  • Verify the Docker container is running with docker ps before attempting restore
  • Sanitize or remove PII from production backups before using them locally
  • Ensure the container has sufficient disk space for the backup file and resulting database
  • Test database connectivity and run a few queries after restore to validate integrity

Example use cases

  • Automated script usage: ./scripts/restore_backup.sh /path/qa-order-service.sql <container> order_development to quickly load QA data
  • Manual controlled restore when you need to edit the SQL file or run custom pre/post steps inside the container
  • Testing a migration: restore a production-like snapshot to run migration scripts against real data
  • Debugging a production-only bug by loading a sanitized production backup into your local dev container

FAQ

What arguments does the automated script expect?

It expects three arguments: path to the SQL backup file, the Docker container ID or name, and the target database name.

What if the Docker container is stopped or not found?

Run docker ps -a to list containers and docker start <container-id> to start a stopped container before restoring.