¿Cómo se realiza la copia de seguridad y recuperación en PostgreSQL?

Question

Accepted Answer

PostgreSQL ofrece varios métodos de **copia de seguridad** — copias lógicas (`pg_dump`) y copias físicas (copia base + WAL para **recuperación a un punto en el tiempo**). Una estrategia sólida de copia de seguridad y recuperación es esencial para protegerse contra la pérdida de datos, y crucialmente, **las copias de seguridad deben ser probadas**.

## Copias de seguridad lógicas — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` crea una copia de seguridad lógica (SQL o archivo) de una base de datos — portátil (restaurable a diferentes versiones/servidores), buena para bases de datos más pequeñas, migraciones y copias de seguridad selectivas. Pero es una instantánea de un punto en el tiempo (sin recuperación continua).

## Copias de seguridad físicas + Recuperación a un punto en el tiempo (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** es poderoso: al archivar WAL continuamente, puedes recuperarte a cualquier momento — no solo a la última copia de seguridad — lo cual es esencial para minimizar la pérdida de datos por desastres.

## Elementos esenciales de la estrategia de copia de seguridad

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## La regla más importante: PRUEBA tus copias de seguridad

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Por qué es importante

La copia de seguridad y recuperación es **conocimiento crítico** para operar PostgreSQL responsablemente — proteger contra la pérdida de datos (por fallos de hardware, corrupción, eliminación accidental, desastres) es una de las responsabilidades más importantes para cualquier base de datos en producción, por lo que entender estrategias de copia de seguridad es conocimiento esencial de nivel senior.

Entender los métodos es necesario: **`pg_dump`** (copias de seguridad lógicas — volcados SQL/archivo portátiles, buenos para bases de datos más pequeñas, migraciones y copias de seguridad selectivas/entre versiones, pero solo instantáneas de un punto en el tiempo) y **copias de seguridad físicas con Recuperación a un punto en el tiempo (PITR)** (copia base + archivado continuo de WAL, permitiendo recuperación a *cualquier* momento — lo cual es poderoso para minimizar la pérdida de datos, como recuperarse justo antes de un accidental `DROP TABLE`, esencial para datos críticos).

Conocer los **elementos esenciales de la estrategia** (copias de seguridad automatizadas regulares, almacenarlas fuera del servidor y en otro sitio, políticas de retención, combinar copias base con WAL para PITR en datos críticos, hacer copias de seguridad desde réplicas) es conocimiento operacional importante.

Más críticamente, entender que **las copias de seguridad deben ser probadas** — una copia de seguridad no probada es poco confiable y a menudo falla exactamente cuando se necesita (corrupción, datos incompletos, proceso de restauración desconocido) — es un principio vital y a menudo descuidado: probar regularmente las restauraciones es lo que hace que una estrategia de copia de seguridad sea realmente confiable.

Ya que la pérdida de datos puede ser catastrófica (y la recuperación solo es posible con copias de seguridad funcionando), y ya que una estrategia adecuada (métodos de copia de seguridad apropiados, PITR para pérdida mínima, almacenamiento en otro sitio, y crucialmente *restauraciones probadas*) es lo que protege los datos de una organización, entender la copia de seguridad y recuperación de PostgreSQL es conocimiento crítico de nivel senior para operaciones responsables de bases de datos — una responsabilidad de alto riesgo donde la diferencia entre una estrategia probada y una sin probar puede ser la diferencia entre recuperarse de un desastre y perder datos permanentemente, lo que la convierte en un tema esencial y frecuentemente relevante para cualquiera que opere bases de datos en producción.