Plantilla de Prueba de Verificacion de Backups

Descripcion General

Un backup que no se puede restaurar no es un backup. Esta plantilla ayuda a los equipos a programar, ejecutar y documentar pruebas de verificacion de backups. Cubre los sistemas en prueba, el procedimiento de restauracion, los criterios de validacion y que hacer cuando una prueba falla.

Cuando Usar

• For alternatives, see Disaster Recovery: RTO, RPO, and Resilient Recovery Runbooks.

• Despues de configurar una nueva politica o herramienta de backup.

• Antes de una auditoria de cumplimiento o revision de recuperacion ante desastres.

• Despues de que un incidente de restauracion en produccion revelo brechas.

• En una programacion recurrente (mensual, trimestral o anual segun la criticidad).

• Cuando cambian los requisitos de objetivo de tiempo de recuperacion (RTO) o punto de recuperacion (RPO).

Prerequisitos

• Politica de backup documentada y programacion de retencion.
• Acceso al almacenamiento de backups y al entorno de restauracion de destino.
• Una ventana de mantenimiento o entorno de prueba aislado que no afecte la produccion.
• Dueno para cada sistema en prueba.
• Objetivos RTO y RPO definidos para cada carga de trabajo.
• Un metodo para validar los datos restaurados y el comportamiento de la aplicacion.

Solucion

Plantilla

1. Identificacion de la Prueba

Campo	Descripcion	Ejemplo
ID de prueba	Identificador unico	BVT-2026-Q3-001
Sistema / Aplicacion	Lo que se prueba	Base de datos de clientes
Entorno	Donde se restaura la prueba	Sandbox de DR aislado
Tipo de backup	Completo, incremental, snapshot, copia de objetos	Snapshot nocturno
Fecha del backup	Punto en el tiempo del backup	2026-06-25 02:00 UTC
Dueno de la prueba	Persona responsable de la ejecucion	Equipo SRE
Fecha programada	Cuando se realiza la prueba	2026-06-27
Stakeholders	Equipos a notificar	DBA, seguridad, equipo de aplicacion

2. Alcance y Objetivos

Objetivo	Objetivo	Medicion
Verificar integridad del backup	La restauracion se completa sin corrupcion	Coincidencia de hash o health check de aplicacion
Validar RTO	Restaurar dentro del tiempo acordado	Comparar tiempo transcurrido con RTO
Validar RPO	Perdida de datos dentro de la ventana acordada	Comparar antiguedad del backup con RPO
Confirmar dependencias	Servicios y credenciales requeridos disponibles	Checklist aprobado
Probar precision del runbook	Los pasos producen el resultado esperado	Sin desviaciones registradas

3. Procedimiento de Restauracion

Paso	Accion	Resultado Esperado	Resultado Actual	Aprobado / Fallido
1	Identificar medio y ubicacion del backup	Backup encontrado y accesible
2	Aprovisionar entorno de restauracion de destino	Entorno listo y aislado
3	Copiar backup al destino	Transferencia completa sin errores
4	Ejecutar comando de restauracion	Restauracion completada exitosamente
5	Verificar estado del sistema de archivos o base de datos	Todos los objetos esperados presentes
6	Iniciar servicios de aplicacion	Servicios alcanzan estado saludable
7	Ejecutar verificaciones de validacion	Pruebas de humo aprobadas
8	Capturar logs y metricas	Evidencia recolectada
9	Limpiar entorno de prueba	Recursos eliminados

4. Checklist de Validacion

• El tamano de los datos restaurados coincide con el tamano del backup (dentro de la tolerancia esperada).
• No se reportan errores de corrupcion por la herramienta de restauracion o validacion de checksum.
• La aplicacion puede conectarse a la base de datos o almacenamiento restaurado.
• Las consultas de lectura criticas o lecturas de archivos devuelven resultados esperados.
• Las operaciones de escritura pueden realizarse en el entorno de prueba sin afectar la produccion.
• El RTO se cumple o se registra una excepcion documentada.
• El RPO se cumple o se registra una excepcion documentada.
• Las credenciales, secretos y acceso a red funcionan despues de la restauracion.
• Los logs no muestran errores inesperados durante la restauracion.
• Los pasos del runbook son precisos y completos.

5. Resumen de Resultados

Metrica	Objetivo	Actual	Estado
Duracion de la restauracion	< 60 minutos	47 minutos	Aprobado
Frescura de datos	< 4 horas	3 horas	Aprobado
Pruebas de humo de aplicacion	100% aprobado	100% aprobado	Aprobado
Precision del runbook	Sin desviaciones	2 desviaciones menores	Aprobado con notas
Resultado general de la prueba	Aprobado		Aprobado

6. Registro de Problemas y Remediacion

ID de Problema	Descripcion	Severidad	Dueno	Fecha Limite	Estado
BVT-001	El script de restauracion usa ruta hard-coded	Media	Equipo SRE	2026-07-04	Abierto
BVT-002	Documentacion con paso faltante para rotacion de secretos	Baja	Equipo de plataforma	2026-07-11	Abierto

Explicacion

La verificacion de backups es la unica forma de probar que un plan de recuperacion ante desastres funciona. Las pruebas regulares exponen problemas como backups faltantes, desviacion de credenciales, errores en runbooks y desajustes de RTO/RPO antes de una emergencia. Documentar cada prueba crea una trazabilidad de auditoria e impulsa la mejora continua de los procedimientos de restauracion.

Script de Verificacion de Restauracion PostgreSQL

#!/bin/bash
# Restaurar y verificar un backup de PostgreSQL
set -euo pipefail

BACKUP_FILE="/backups/prod_db_2026-07-11.sql.gz"
TEST_DB="restore_test_$(date +%s)"
PG_HOST="test-db.internal"
PG_USER="restore_verifier"

echo "=== Verificacion de Restauracion de Backup PostgreSQL ==="
echo "Backup: $BACKUP_FILE"
echo "DB de prueba: $TEST_DB"
echo ""

# Crear base de datos de prueba
echo "[1/6] Creando base de datos de prueba..."
createdb -h "$PG_HOST" -U "$PG_USER" "$TEST_DB"

# Restaurar backup
echo "[2/6] Restaurando backup..."
gunzip -c "$BACKUP_FILE" | psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -v ON_ERROR_STOP=1 > /dev/null

# Verificar conteo de filas
echo "[3/6] Verificando conteo de filas..."
TABLES=$(psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -t -c "SELECT tablename FROM pg_tables WHERE schemaname='public'")
for table in $TABLES; do
  count=$(psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -t -c "SELECT count(*) FROM $table")
  echo "  $table: $count filas"
done

# Verificar constraints
echo "[4/6] Verificando constraints..."
CONSTRAINTS=$(psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -t -c "SELECT count(*) FROM pg_constraint WHERE conrelid IN (SELECT oid FROM pg_class WHERE relnamespace='public'::regnamespace)")
echo "  Constraints activos: $CONSTRAINTS"

# Verificar indices
echo "[5/6] Verificando indices..."
INDEXES=$(psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -t -c "SELECT count(*) FROM pg_indexes WHERE schemaname='public'")
echo "  Indices activos: $INDEXES"

# Ejecutar queries de prueba
echo "[6/6] Ejecutando queries de smoke..."
psql -h "$PG_HOST" -U "$PG_USER" -d "$TEST_DB" -c "SELECT 1 as test" > /dev/null && echo "  Smoke query: PASS" || echo "  Smoke query: FAIL"

# Limpiar
echo ""
echo "Limpiando base de datos de prueba..."
dropdb -h "$PG_HOST" -U "$PG_USER" "$TEST_DB"
echo "=== Verificacion Completada ==="

Hoja de Calculo de Medicion RTO/RPO

=== Hoja de Calculo RTO/RPO de Verificacion de Backup ===

Fecha de prueba: 2026-07-11
Servicio: production-database
Tipo de Backup: Full + WAL streaming

Medicion RPO:
  - Ultimo backup exitoso:    2026-07-11 02:00 UTC
  - Ultimo WAL archivado:     2026-07-11 10:45 UTC
  - Punto de restauracion:    2026-07-11 11:00 UTC
  - Perdida de datos:         15 minutos
  - Objetivo RPO:             30 minutos
  - Estado RPO:               PASS (15 min < 30 min)

Medicion RTO:
  - Inicio de restauracion:   11:00 UTC
  - DB disponible:            11:08 UTC
  - App conectada:            11:10 UTC
  - Smoke tests pasaron:      11:12 UTC
  - RTO total:                12 minutos
  - Objetivo RTO:             30 minutos
  - Estado RTO:               PASS (12 min < 30 min)

Problemas Encontrados:
  - Brecha de WAL de 3 minutos durante 09:30-09:33
  - Script con path hard-codeado (BVT-001)
  - Falta paso de rotacion de secretos (BVT-002)

Remediacion:
  - Investigar causa del brecha WAL
  - Corregir paths hard-codeados para 2026-07-04
  - Agregar rotacion de secretos al runbook para 2026-07-11

Variantes

• Verificacion de backups de base de datos: Restaurar backups completos e incrementales, verificar la reproduccion de logs de transacciones y ejecutar verificaciones de consistencia.
• Verificacion de backups de sistema de archivos: Restaurar directorios, validar permisos y comparar checksums.
• Verificacion de backups de maquinas virtuales: Arrancar la VM restaurada, verificar red y servicios, luego ejecutar pruebas de aplicacion.
• Verificacion de backups de almacenamiento de objetos: Restaurar objetos seleccionados, validar metadata y comparar contra el bucket de origen.
• Verificacion de snapshots en la nube: Crear un volumen temporal desde el snapshot, montarlo y validar la integridad de datos.
• Verificacion de backups a nivel de aplicacion: Restaurar datos en una nueva instancia de aplicacion y ejecutar pruebas de humo end-to-end.

Lo que funciona

• Prueba los backups en una programacion recurrente, no solo una vez al ano.
• Usa un entorno aislado que refleje la topologia de produccion.
• Automatiza los pasos de restauracion donde sea posible, pero manten un runbook manual.
• Valida tanto la integridad de datos como el comportamiento de la aplicacion despues de la restauracion.
• Mide y compara el RTO/RPO real contra los objetivos cada vez.
• Registra desviaciones y remediarlas antes de la siguiente prueba.
• Rota credenciales y secretos en entornos de prueba para que coincidan con produccion.
• Manten la metadata de backups accesible sin depender del sistema de produccion.
• Incluye la verificacion de backups en la gestion de cambios para sistemas criticos.
• Almacena evidencia de pruebas para cumplimiento y auditorias.

Errores Comunes

• Asumir que un backup es valido porque el trabajo de backup reporto exito.
• Probar solo backups completos e ignorar cadenas incrementales o diferenciales.
• Restaurar en el mismo entorno donde se tomo el backup.
• Omitir la validacion de aplicacion despues de la restauracion de datos.
• No probar la restauracion de credenciales o dependencias de red.
• No documentar y corregir problemas encontrados durante las pruebas.
• Probar con demasiada poca frecuencia para detectar desviacion de configuracion.
• Ignorar el crecimiento del tamano de backup y las tendencias de tiempo de restauracion.

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de backup y disaster-recovery para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de prueba de verificacion de backups cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.