Pruebas de restauración: un backup que nunca has restaurado es solo una esperanza

La mayoría de paneles de backup están en verde. Dicen que un job se ejecutó y que se escribió un archivo, lo que no dice nada de si puedes recuperar tu negocio a partir de ese archivo, cuánto tarda o si la copia sobrevive a un atacante con permisos de administrador. La única prueba es una restauración. En las plataformas que opero, los backups se escriben cada pocas horas fuera del proveedor de hosting y se restauran cada noche, de forma automática, en un gemelo aislado. Así se monta.

Dominik Heinrich

8 de noviembre de 20269 min de lectura

1. Decidir qué significa "restaurado"

Dos cifras por sistema enmarcan cualquier decisión de backup. El objetivo de punto de recuperación (RPO) es cuántos datos te puedes permitir perder: si entran reservas todo el día, cuatro horas de reservas perdidas pueden ser ya demasiado. El objetivo de tiempo de recuperación (RTO) es cuánto puede esperar el negocio hasta que el sistema vuelva. La guía de planes de contingencia para sistemas de TI del NIST usa exactamente estos términos, y conviene escribirlos con el responsable de negocio, no dejar que el equipo de plataforma los adivine.

El RPO fija la frecuencia de los backups; el RTO fija lo rápida que debe ser una restauración, y más adelante en este artículo se convierte en el umbral con el que se mide tu prueba nocturna.

2. Poner los backups fuera de alcance

Un backup que vive en la misma cuenta, con las mismas credenciales de administrador, cae con el sistema que protege: una caída del proveedor, una suscripción borrada o un atacante que llega al rol de administrador se lleva los dos. Así que cifra el backup antes de que salga, escríbelo en un almacenamiento fuera del proveedor de hosting o al menos fuera de la cuenta, y hazlo inmutable. El vault inmutable de Azure Backup impide borrar puntos de recuperación antes de que caduquen, y Amazon S3 Object Lock guarda objetos con el modelo write once, read many y un periodo de retención.

Da al job de backup credenciales que puedan escribir pero no borrar. En una plataforma que opero, hasta el registro de auditoría se escribe así: S3 Object Lock, guardado 90 días, con credenciales de solo escritura, para que una aplicación comprometida pueda añadir entradas pero nunca borrarlas.

Consejo práctico

Guarda al menos una copia en otro proveedor o región y con otras credenciales. Dos copias detrás de la misma contraseña son una sola copia.

Arquitectura de pruebas de restauración: producción, con una aplicación y una base de datos PostgreSQL, escribe cada pocas horas backups cifrados en un almacenamiento inmutable fuera del proveedor, con una segunda copia en otra región u otro proveedor; cada noche un job de restauración crea una base de datos nueva en un gemelo aislado, comprueba recuentos de filas, checksums y un smoke test de la aplicación, mide el tiempo frente al RTO y avisa a una persona si falla alguna comprobación. — Backups fuera de alcance, restaurados cada noche en un gemelo aislado, comprobados, cronometrados y avisando a una persona cuando fallan.

3. Restaurar cada noche en un gemelo aislado

Convierte la restauración en un job programado, no en un procedimiento de emergencia. Cada noche toma el último backup, crea una base de datos nueva en un entorno aislado sin ruta de red hacia producción y restaura en ella. El aislamiento importa por partida doble: una prueba nunca debe tocar datos reales, y una copia restaurada contiene los mismos datos personales que producción, así que recibe la misma protección y se borra tras las comprobaciones.

Las herramientas existen en todas las plataformas. AWS Backup tiene restore testing, que lanza restauraciones según un calendario y registra cuánto tardan. En Kubernetes, CloudNativePG puede crear un clúster PostgreSQL nuevo a partir de un backup. Un script sencillo con pg_restore en una base de datos desechable funciona en todas partes y se lee bien a las tres de la madrugada.

bash

#!/usr/bin/env bash
# Nightly restore test: latest backup -> fresh database in the isolated twin -> checks
set -euo pipefail
LATEST=$(ls -1 /backups/db/*.dump.gpg | sort | tail -1)   # synced from the off-site store
gpg --batch --decrypt --output /tmp/latest.dump "$LATEST"

START=$(date +%s)
dropdb --if-exists -h restore-twin restore_check
createdb -h restore-twin restore_check
pg_restore -h restore-twin -d restore_check --no-owner --jobs 4 /tmp/latest.dump
echo "restore_seconds $(( $(date +%s) - START ))"            # compare with the RTO

psql -h restore-twin -d restore_check -v ON_ERROR_STOP=1 -f checks.sql
rm -f /tmp/latest.dump

4. Comprobar los datos, no el código de salida

Una restauración puede terminar sin errores y aun así no servir: una tabla que nunca estuvo en el backup, un dump truncado, una copia de hace tres días porque el job de backup falló en silencio. Así que compara el resultado con producción. Recuentos exactos de filas de las tablas clave frente a una réplica de producción, un checksum sobre las filas de las tablas que importan, ordenado para que la disposición física no cambie el resultado, y la marca de tiempo más reciente, que debe estar dentro del RPO.

Las mismas comprobaciones son las que hacen seguras las migraciones. Cuando moví bases de datos de clientes a un clúster de Kubernetes con CloudNativePG, los recuentos de filas y los checksums tenían que ser idénticos antes de cambiar nada, y lo fueron.

sql

-- checks.sql: run the same queries on a production replica and compare
-- 1. Exact row counts of the key tables
SELECT 'bookings' AS tbl, count(*) FROM bookings
UNION ALL SELECT 'payments', count(*) FROM payments
UNION ALL SELECT 'customers', count(*) FROM customers;

-- 2. Checksum independent of physical row order
SELECT md5(string_agg(b::text, '|' ORDER BY b.id)) AS bookings_checksum
FROM bookings b WHERE b.created_at < date_trunc('day', now());

-- 3. Freshness: the newest row must be inside the RPO
SELECT now() - max(created_at) AS data_age FROM bookings;

Consejo práctico

Calcula el checksum solo sobre filas anteriores al inicio del backup, como en el ejemplo. Si no, cada reserva nueva en producción hace fallar la comparación por el motivo equivocado.

5. Ejecutar la aplicación contra la restauración

Unos datos que parecen correctos pueden seguir siendo inservibles: una extensión de la base de datos que no está instalada en el destino, roles y permisos que el dump no incluía, secretos que solo existen en producción. Un smoke test corto los detecta: arranca la aplicación contra la base de datos restaurada y deja que inicie sesión, lea un registro y escriba otro. Si funciona, has recuperado un sistema, no solo un conjunto de tablas.

Mantén el smoke test pequeño y determinista. No es una batería completa de tests; responde cada mañana a una pregunta: ¿podríamos llevar el negocio con el backup de anoche?

6. Medir el tiempo de restauración frente al RTO

Las bases de datos crecen, y con ellas el tiempo que cuesta recuperarlas. Una restauración que el año pasado tardaba veinte minutos puede tardar ahora dos horas, y nadie se da cuenta hasta el día en que importa. Registra la duración de cada restauración nocturna, desde el inicio de la descarga hasta el smoke test superado, y ponla en una gráfica junto al RTO.

Cuando la línea se acerque al objetivo, actúa antes de que lo haga un incidente: restauraciones en paralelo, un almacenamiento más rápido para el gemelo, otro método de backup para las tablas más grandes o una conversación sincera sobre un RTO más largo.

7. Avisar de las restauraciones fallidas y practicar con personas

La mayoría de las monitorizaciones avisan cuando falla un job de backup. Avisa también cuando falla una restauración: una comprobación fallida, un smoke test que no pasa o una duración por encima del RTO despierta a una persona por la mañana, en un canal que alguien lee. Un backup que no se puede restaurar es una caída que simplemente aún no has tenido.

La automatización demuestra los datos, no las personas. Una vez al trimestre, haz una restauración con el equipo siguiendo el runbook, incluido quién decide, quién comunica y dónde están las credenciales. La checklist de abajo lo incluye entre lo básico que necesita una plataforma antes de considerarse lista para producción.

Conclusión
Los backups son una promesa; las restauraciones, la prueba. Restaura cada noche, comprueba los datos y la aplicación, mide el tiempo frente al RTO y deja que una restauración fallida despierte a alguien.

Proyectos reales relacionados

Monitorización de resultados de negocio y copias probadas cada noche

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos