Backup y Restauración

Semestre 01, 2026

La importancia de los backups

Los datos se pierden

No es una pregunta de si ocurrirá.
Es una pregunta de cuándo.

Causas reales de pérdida de datos

El error humano es responsable de la mayoría de las pérdidas de datos en producción.

El costo de no tener backup

Una empresa de e-commerce pierde su base de datos un viernes a las 11 PM.

• Sin backup: los datos de clientes, pedidos e inventario son irrecuperables.
• El negocio no puede operar hasta reconstruir — si es que puede.
• Pérdida económica directa + reputación + posibles problemas legales.

El costo de implementar backups es una fracción mínima del costo de no tenerlos.

La ilusión de seguridad

Muchos sistemas tienen backup en teoría.

• El backup se configuró hace 2 años y nadie verificó si sigue funcionando.
• El backup existe pero el archivo está corrupto.
• El backup existe pero restaurar toma 6 horas que el negocio no puede permitirse.

Un backup que nunca se ha restaurado no es un backup.

Conceptos fundamentales

RPO — Recovery Point Objective

La cantidad máxima de datos que el sistema puede perder.

Si el backup es diario a las 2 AM y el fallo ocurre a las 11 PM, se pierden ~21 horas de datos.

El RPO define la frecuencia mínima del backup.

RTO — Recovery Time Objective

El tiempo máximo que el sistema puede estar inactivo.

Un backup de 100 GB puede tardar 2 horas en restaurarse.
Si el RTO del negocio es 30 minutos, ese proceso no es suficientemente rápido.

El RTO define qué tipo de estrategia de recovery se necesita.

Tipos de backup

Full vs Incremental en restauración

Restaurar = 1 backup
Riesgo    = 1 archivo

Restaurar = full +
  cada incremental
Riesgo    = cadena
  se rompe si falta uno

Restaurar = full +
  último diferencial
Balance   = intermedio

La regla 3-2-1

La estrategia estándar de la industria para backups confiables.

Por qué cada número importa

• 3 copias: la copia en producción + 2 backups. Si una falla, hay dos más.
• 2 medios distintos: no guardar todo en el mismo tipo de almacenamiento. Un fallo de tipo no elimina todo.
• 1 offsite: un desastre físico destruye todo lo que está en el mismo lugar. La copia offsite sobrevive.

Implementación práctica

Copia 1: Base de datos en producción (servidor principal)
Copia 2: Backup en servidor de backup local (NAS, otro servidor)
Copia 3: Backup en almacenamiento en la nube (S3, Google Cloud Storage)

Medio 1: Disco del servidor
Medio 2: Almacenamiento en la nube

Offsite:  La copia en la nube está en una ubicación geográfica diferente

La regla 3-2-1-1-0

Extensión recomendada en entornos críticos.

• +1 copia inmutable — no puede ser modificada ni eliminada. Protección contra ransomware.
• +0 errores al verificar la restauración — ningún backup no verificado cuenta.

PostgreSQL: pg_dump

La herramienta estándar para hacer backup de una base de datos PostgreSQL.

Genera un script SQL o un archivo binario que puede restaurarse en cualquier instalación compatible.

Backup completo en formato SQL

pg_dump -U usuario -h localhost -d nombre_db > backup.sql

El archivo resultante contiene todos los CREATE TABLE, INSERT, índices, vistas y funciones.

Backup con compresión

# Formato custom (comprimido, permite restauración selectiva)
pg_dump -U usuario -h localhost -d nombre_db -Fc > backup.dump

# Formato directory (paralelizable)
pg_dump -U usuario -h localhost -d nombre_db -Fd -f backup_dir/

El formato -Fc es el recomendado para producción:

• Comprimido — ocupa menos espacio.
• Permite restaurar tablas individuales.
• Compatible con pg_restore.

Backup de todas las bases de datos

# pg_dumpall incluye roles, tablespaces y todas las bases de datos
pg_dumpall -U postgres -h localhost > backup_completo.sql

Usar cuando se necesita migrar o recuperar un servidor completo.

Opciones útiles de pg_dump

# Solo el esquema (sin datos)
pg_dump -U usuario -d nombre_db --schema-only > esquema.sql

# Solo los datos (sin CREATE TABLE)
pg_dump -U usuario -d nombre_db --data-only > datos.sql

# Solo una tabla específica
pg_dump -U usuario -d nombre_db -t nombre_tabla > tabla.sql

# Excluir una tabla
pg_dump -U usuario -d nombre_db --exclude-table=logs > backup_sin_logs.sql

PostgreSQL: Restauración

Restaurar desde SQL plano

# Crear la base de datos primero (si no existe)
createdb -U postgres nueva_db

# Restaurar
psql -U usuario -d nueva_db < backup.sql

Restaurar con pg_restore

# Restaurar completo
pg_restore -U usuario -d nombre_db -Fc backup.dump

# Restaurar solo una tabla específica
pg_restore -U usuario -d nombre_db -Fc -t productos backup.dump

# Restaurar con verbose — ver el progreso
pg_restore -U usuario -d nombre_db -Fc -v backup.dump

# Solo el esquema
pg_restore -U usuario -d nombre_db -Fc --schema-only backup.dump

Restaurar en paralelo

# -j 4 usa 4 workers en paralelo — útil para backups grandes
pg_restore -U usuario -d nombre_db -Fd -j 4 backup_dir/

El formato -Fd (directory) es necesario para usar restauración paralela.

MySQL: mysqldump

La herramienta estándar para backup en MySQL.

Genera un script SQL con toda la estructura y los datos.

Backup completo

# Una base de datos
mysqldump -u usuario -p nombre_db > backup.sql

# Todas las bases de datos
mysqldump -u root -p --all-databases > backup_completo.sql

Opciones importantes de mysqldump

# Incluir rutinas y triggers
mysqldump -u usuario -p --routines --triggers nombre_db > backup.sql

# Solo esquema / solo datos
mysqldump -u usuario -p --no-data nombre_db > esquema.sql
mysqldump -u usuario -p --no-create-info nombre_db > datos.sql

# Transacción consistente (para InnoDB — snapshot sin bloquear)
mysqldump -u usuario -p --single-transaction nombre_db > backup.sql

# Con compresión
mysqldump -u usuario -p nombre_db | gzip > backup.sql.gz

--single-transaction es esencial en producción para no bloquear la base de datos durante el backup.

Restaurar en MySQL

# Restaurar en una base de datos existente
mysql -u usuario -p nombre_db < backup.sql

# Restaurar desde archivo comprimido
gunzip -c backup.sql.gz | mysql -u usuario -p nombre_db

# Crear la base de datos y restaurar
mysql -u root -p -e "CREATE DATABASE nueva_db;"
mysql -u root -p nueva_db < backup.sql

Un backup no es un backup hasta que se restaura

Esta es la parte que casi todos omiten.

El backup puede fallar de estas formas

• Corrupto — el disco tuvo un error al escribir.
• Incompleto — el proceso se interrumpió.
• Irrestaurable — versión incompatible, permisos incorrectos, dependencias faltantes.

El único test válido es que se pueda restaurar y que los datos funcionen correctamente.

Frecuencia de las pruebas de restauración

Si no se puede probar con frecuencia, documentar el proceso detallado para que sea reproducible bajo presión.