Tu respaldo no existe hasta que lo restauras: cómo probar que realmente funciona
El 100% de las empresas hace respaldos. Un porcentaje mucho menor los ha restaurado alguna vez. Ahí vive el desastre.
Pregúntale a cualquier empresa si hace respaldos y la respuesta será que sí. Pregúntale cuándo fue la última vez que restauró uno completo, en un equipo distinto, cronómetro en mano, y verás cómo cambia el tono de la conversación. Ese silencio es el problema entero.
Un respaldo no es un archivo: es una hipótesis. La hipótesis de que ese conjunto de bytes, en esas condiciones, permitirá reconstruir un sistema funcional. Y como toda hipótesis, no vale nada hasta que se comprueba. Mientras no la pruebes, lo que tienes no es protección: es la sensación de tenerla, que es peor, porque impide buscar la de verdad.
Lo incómodo es que los respaldos fallan de formas que el reporte verde no detecta. El trabajo termina «exitoso», el correo llega, el tablero está en orden, y el día que lo necesitas descubres que la base de datos quedó inconsistente, que faltaba la carpeta que se agregó en marzo o que restaurar dos terabytes iba a tomar cuarenta horas que nadie tenía.
Sumario
- 01Seis formas de fallar en silencio
- 02Los tres niveles de prueba
- 03Calendario realista
- 04Cómo medir el RTO real
- 05El acta de prueba
- 06Checklist de cierre
Seis formas de fallar en silencio
Ninguna de estas produce un error visible. Todas se descubren únicamente restaurando.
Respalda, pero no lo que importa
El trabajo se configuró hace tres años con una lista de rutas. Desde entonces alguien movió los adjuntos a otro volumen, se agregó un servicio nuevo y se migró una base de datos. El respaldo sigue copiando fielmente lo que se le dijo en 2022.
Comparando el contenido del respaldo contra el sistema vivo, no revisando la configuración del trabajo. Un inventario semestral de qué se respalda y qué no, firmado por quien conoce la aplicación.
Falla, pero nadie se entera
El clásico: el respaldo lleva once semanas fallando y las notificaciones llegan a la cuenta de alguien que salió de la empresa, o a una carpeta con regla de archivado automático. El sistema avisó todos los días. Nadie escuchó.
No monitorees el fallo: monitorea la antigüedad del último respaldo exitoso. Es la única métrica que no se puede ignorar por accidente, porque no depende de que alguien lea un correo.
# Alerta si el respaldo más reciente tiene más de 26 horas
ULTIMO=$(find /mnt/backups -name "*.tar.zst" -mtime -2 | wc -l)
[ "$ULTIMO" -eq 0 ] && notificar "SIN RESPALDO EN 48 H"
# Con restic: verifica integridad de una muestra del repositorio
restic check --read-data-subset=5%Está completo, pero inconsistente
Copiar los archivos de una base de datos con el servicio encendido produce un respaldo que existe, pesa lo correcto y no sirve. Lo mismo pasa con snapshots de máquina virtual tomados sin coordinar con la aplicación: capturan un instante a mitad de una transacción.
Restaurando y dejando que el motor valide. Es el único juez.
# PostgreSQL: ¿el archivo es legible y trae todo?
pg_restore --list respaldo.dump | head -40
# SQL Server: verificación de integridad del archivo
RESTORE VERIFYONLY FROM DISK = 'D:\resp\base.bak' WITH CHECKSUM;
# Después de restaurar, siempre:
DBCC CHECKDB('MiBase') WITH NO_INFOMSGS;Está cifrado y nadie tiene la llave
El respaldo es impecable y está perfectamente protegido. Tan protegido que la única persona que conocía la frase de cifrado ya no trabaja aquí, o la llave vivía en el servidor que se perdió. Ocurre más de lo que parece y es irreversible.
Las llaves de cifrado se resguardan fuera del sistema que protegen, con al menos dos custodios y un procedimiento escrito de recuperación. Y se prueban: descifrar es parte de la prueba de restauración, no un paso aparte.
Sirve, pero tarda demasiado
Este no es un fallo técnico: es un fallo de diseño. El respaldo restaura perfectamente en cuarenta horas, y el negocio aguanta seis. Nadie lo supo antes porque nadie midió. Es, con diferencia, el hallazgo más común de una primera prueba real.
El almacenamiento frío en la nube y las cintas son los sospechosos habituales: baratísimos para guardar, lentísimos para sacar. Suma tiempo de rehidratación, ancho de banda de descarga y descompresión antes de prometer un tiempo de recuperación.
Sirve, pero no hay dónde restaurarlo
Tienes los datos y no tienes destino: no hay servidor libre, la licencia del sistema operativo estaba atada al hardware que murió, el instalador de la aplicación no está en ningún lado o el certificado que necesita venció hace un año.
Instaladores y versiones exactas, llaves de licencia, certificados, configuración de red y DNS, y el runbook de arranque. Un respaldo de datos sin eso es media recuperación.
Los tres niveles de prueba
No todas las pruebas cuestan lo mismo ni prueban lo mismo. La confusión entre ellas es lo que lleva a equipos a creer que están cubiertos cuando solo están haciendo el nivel más barato.
| Nivel | Qué comprueba | Qué NO comprueba | Costo |
|---|---|---|---|
| Verificación | Que el archivo existe, está íntegro y es legible. Checksums, restic check, VERIFYONLY. |
Que los datos adentro sirvan, ni que la aplicación arranque con ellos. | Automatizable. Diaria. |
| Restauración parcial | Que puedes recuperar un elemento concreto: una base, una carpeta, el buzón de alguien. Valida el procedimiento y las credenciales. | El tiempo total de recuperación ni las dependencias entre sistemas. | 1 a 2 horas. Mensual. |
| Restauración completa | Que el sistema arranca y opera en hardware distinto, con datos consistentes, en un tiempo medido. | Solo queda fuera el factor humano bajo presión real. | Medio día. Trimestral. |
Restaurar un archivo suelto para un usuario que borró algo no cuenta como prueba de restauración. Es útil y confirma que el respaldo existe, pero no valida consistencia, ni tiempos, ni dependencias, ni el procedimiento completo. Muchos equipos llevan años creyendo que prueban sus respaldos porque hacen esto cada semana.
Calendario realista
La clave está en que sea sostenible. Un calendario ambicioso que se abandona al segundo mes protege menos que uno modesto que se cumple durante tres años.
-
1Verificación automática Diaria
Integridad del repositorio y alerta por antigüedad del último respaldo exitoso. Cero intervención humana. Si esto no está, nada de lo demás importa.
-
2Restauración parcial rotativa Mensual
Un sistema distinto cada mes, siguiendo una rotación escrita. En un año habrás probado los doce sistemas críticos. Una a dos horas de trabajo con acta al final.
-
3Restauración completa Trimestral
El sistema más crítico, restaurado de cero en un equipo o máquina virtual distinta, con la aplicación arrancando y alguien del área usuaria validando que los datos son correctos. Con cronómetro.
-
4Simulacro de desastre Anual
Escenario completo: se asume que el sitio principal no existe. Se restaura desde la copia externa, con el equipo siguiendo el runbook y sin acceso a los sistemas de siempre. Aquí se descubren las dependencias que nadie documentó.
Cómo medir el RTO real
El objetivo de tiempo de recuperación que aparece en el plan de continuidad suele ser un deseo. El RTO real es un número que se obtiene midiendo, y casi siempre resulta entre dos y cuatro veces mayor que el estimado.
Mide con marcas de tiempo, no de memoria. Y mide desde la declaración del incidente, no desde que empiezas a copiar archivos:
T0 Declaración del incidente
T1 Localización del respaldo válido # suele sorprender
T2 Destino listo (VM creada, SO instalado)
T3 Transferencia terminada # mide MB/s reales
T4 Datos restaurados y validados
T5 Aplicación arrancando
T6 Usuario del negocio confirma que sirve # este es el RTO real
RTO = T6 - T0 # no T4 - T2Los dos tramos que más se subestiman son T0 a T1 —encontrar qué respaldo usar y con qué credenciales— y T5 a T6, la validación funcional. Ambos dependen de documentación, no de infraestructura, y ambos son los más baratos de reducir.
Un RTO medido convierte una discusión de opiniones en una decisión de negocio. «Tardaríamos 31 horas y el negocio aguanta 8» es un caso de inversión que se aprueba solo. «Deberíamos mejorar los respaldos» no lo es, y por eso lleva tres años en la lista de pendientes.
El acta de prueba
Sin documento, la prueba no ocurrió. El acta sirve para tres cosas: comparar contra la prueba anterior, sustentar ante auditoría o seguros, y —la más importante— convertir los hallazgos en tareas con dueño y fecha en vez de comentarios que se olvidan al día siguiente.
| Campo | Qué se registra |
|---|---|
| Identificación | Fecha, sistema probado, tipo de prueba, quién la ejecutó y quién validó del lado del negocio |
| Origen | Qué respaldo se usó: fecha, ubicación, medio y método de cifrado |
| Destino | Dónde se restauró y con qué recursos, para poder repetirlo igual |
| Tiempos | T0 a T6 con hora exacta. Es el corazón del acta |
| Criterio de éxito | Definido antes de empezar. Ejemplo: «se consultan los últimos 10 pedidos y coinciden con producción» |
| Resultado | Cumple, cumple con observaciones, o no cumple. Sin medias tintas |
| Hallazgos | Cada uno con responsable y fecha compromiso |
| Firmas | Quien ejecuta y quien valida del negocio |
Si el criterio se escribe después de ver el resultado, siempre se cumple. Ese es el modo más elegante de hacer una prueba inútil. Escribe la frase concreta —qué consulta, qué pantalla, qué número tiene que coincidir— antes de tocar nada.
Checklist de cierre
Antes de firmar el acta
Imprimir o guardar como PDF- El respaldo se restauró en un equipo distinto del original Restaurar sobre el mismo servidor no prueba portabilidad ni disponibilidad de licencias
- El proceso se ejecutó siguiendo el runbook escrito, no de memoria Si hubo que improvisar un paso, ese paso falta en el documento
- La aplicación arrancó y alguien del negocio validó los datos No basta con que el servicio esté escuchando en el puerto
- Se registraron los tiempos T0 a T6 con hora real Estimaciones a ojo invalidan la medición
- Se probó el descifrado con las llaves resguardadas, no con las del servidor vivo Es el escenario real: el servidor original no existe
- Se verificó la copia externa, no solo la local La copia de sitio es la que va a fallar el día del incendio o del ransomware
- Cada hallazgo quedó con responsable y fecha Un hallazgo sin dueño reaparece idéntico en la prueba del próximo trimestre
- El RTO medido se comparó contra el RTO comprometido Si no coinciden, hay que cambiar el diseño o cambiar la promesa
- El entorno de prueba se destruyó y no quedó expuesto Una copia de producción olvidada sin contraseñas es una fuga esperando ocurrir
Guarda las actas juntas. La serie histórica —cómo evolucionó tu RTO trimestre a trimestre— es el mejor argumento que vas a tener frente a dirección.
Empieza por lo pequeño
Si nunca has hecho una prueba formal, no arranques con el simulacro anual: vas a descubrir veinte problemas a la vez y el equipo va a salir desmoralizado. Elige el sistema crítico más simple, aparta dos horas de un jueves, escribe el criterio de éxito en una línea y restaura.
Sea cual sea el resultado, vas a terminar sabiendo algo que hoy no sabes. Y si sale mal, mejor: lo descubriste un jueves cualquiera y no un lunes con la empresa detenida.
No tienes respaldos. Tienes intentos de respaldo. Se convierten en respaldos el día que los restauras.
¿Cuándo fue la última vez que alguien restauró un respaldo completo en tu empresa?
Hacemos la prueba por ti. Restauramos tus sistemas críticos en un entorno aislado, medimos el tiempo real de recuperación de punta a punta y te entregamos el acta con los hallazgos priorizados. Si tus respaldos sirven, lo vas a saber con certeza. Si no, lo vas a saber un jueves cualquiera y no el día del incidente.
- —Auditoría y pruebas de restauración de respaldos
- —Diseño de esquemas de respaldo inmutable y fuera de sitio
- —Planes de continuidad y runbooks de recuperación
- —Mantenimiento y monitoreo de servidores