Una copia de seguridad solo es real tras una restauración

Casi todo el mundo tiene copias de seguridad. Muchos menos equipos saben cuánto tarda una restauración, si los archivos están completos o si el volcado de la base de datos siquiera carga. La única forma de saberlo es restaurar, con regularidad y sin que una persona tenga que acordarse.

Qué responde una política de copias útil

• ¿Cuántos datos podemos perder? (punto de recuperación)
• ¿Cuánto tiempo podemos estar caídos? (tiempo de recuperación)
• ¿Dónde vive la segunda copia? Al menos una copia debe estar fuera del servidor y fuera del alcance de las credenciales que lo operan.

Una prueba de restauración pequeña y honesta

La idea es simple: volcar, cargar en una base de datos temporal, ejecutar una consulta de verificación y fallar con ruido si algo no cuadra.

#!/usr/bin/env bash
set -euo pipefail

STAMP=$(date +%F)
DUMP=/backup/db/app-$STAMP.sql.gz

# 1. crear la copia (instantánea consistente para InnoDB)
mysqldump --single-transaction --routines --triggers app | gzip > "$DUMP"
gzip -t "$DUMP"

# 2. restaurar en una base de datos desechable
mysql -e "DROP DATABASE IF EXISTS restore_test; CREATE DATABASE restore_test"
gunzip -c "$DUMP" | mysql restore_test

# 3. verificación: los datos deben parecer datos
ROWS=$(mysql -N -e "SELECT COUNT(*) FROM restore_test.users")
[ "$ROWS" -gt 0 ] || { echo "restore test failed: users is empty" >&2; exit 1; }

mysql -e "DROP DATABASE restore_test"

Ejecútalo desde cron o un temporizador de systemd y envía la salida de fallo a un lugar donde una persona la vea.

Detalles que muerden después

1. Cifra las copias que salen del servidor y guarda la clave por separado.
2. Conserva varias generaciones. La corrupción y los borrados accidentales a menudo se notan días tarde.
3. Respalda la configuración, no solo los datos: servidor web, PHP, cron, reglas del cortafuegos y registros DNS.
4. Cronometra una restauración completa al menos dos veces al año y anota el número. Ese número es tu tiempo de recuperación real.