Medianoche. Un DELETE sin WHERE en la tabla de pedidos. El administrador abre el ticket de "restauración de copia de seguridad". A las 2:00, el volcado de MySQL se niega a importar: juego de caracteres incompatible. A las 4 a.m., faltan los archivos multimedia: estaban en un volumen que no era de instantáneas. A las 6 de la mañana, el cliente se enteró de que nadie había hecho nunca el ejercicio.
Probar una restauración no es paranoia. Esta es la única prueba de que su estrategia de copia de seguridad funciona fuera de PowerPoint.
Dos escenarios mínimos para simular
Escenario A: error humano específico. Se eliminó una tabla o directorio. Objetivo: restauración parcial de menos de su RTO, sin reconstruir todo.
Escenario B: Compromiso o ransomware. Producción sospechosa. Objetivo: reconstruir en infraestructura virgen a partir de una copia inmutable fechada antes de la intrusión, no la última copia de seguridad.
| Escenario | Pregunta probada | Éxito medible |
|---|---|---|
| Mesa de caída | Volcado parcial / PITR | Pedidos en el sitio OK, datos consistentes |
| ransomware | Copia inmutable D-5 | Sin malware, secretos enterrados |
| Implementación incorrecta | Código de reversión + base de datos alineada | Versión funcional N-1 |
| Pérdida del centro de datos | Restaurar fuera del sitio | DNS cambiado, RTO retenido |
Si solo prueba un escenario, pruebe el peor, no el más cómodo.
Sandbox: reproducir sin riesgo
Máquina aislada: VPS desechable, Docker compone VM local y fuera de línea.
Datos anonimizados si es RGPD: oculta correos electrónicos y PII para realizar pruebas frecuentes; realizar una prueba anual sobre un ejemplar fiel en un ambiente cerrado.
Lista de verificación ordenada: prueba de DNS, importación de base de datos, sincronización de archivos, variables de entorno, trabajadores, vaciado de caché, inicio de sesión de prueba de humo + pago.
Calcula el tiempo de cada paso. Tu RTO teórico de 2 horas que se convierte en 8 horas en la práctica es la información más valiosa del ejercicio.
Lo que el ejercicio casi siempre revela
- Credenciales de copia de seguridad caducadas o restauración automática de bloqueo de 2FA.
- Volcados vacíos o 0 bytes perdidos.
- La versión de restauración de MySQL es incompatible con la fuente de volcado.
- Falta
.env: la aplicación se inicia pero ya no envía correos electrónicos. - Orden inverso: sitio activo, imágenes 404 porque el objeto de almacenamiento no se resincroniza.
Anote cada desviación en un runbook fechado. Este es su capital para la verdadera crisis.
Medir y mejorar
Establezca KPI simples:
- Tiempo total frente al RTO objetivo.
- Pérdida de datos simulada frente al RPO objetivo.
- Número de pasos manuales: candidato a automatización.
- Tickets abiertos durante el ejercicio: ¿te falta entrenamiento?
Comparta un breve informe con el equipo. Una falla en el sandbox vale oro; un fallo en la producción vale la pena perder un cliente.
La parte superior: la copia de seguridad “verificada” por el host no es su restauración
Esta es la línea que borran los SLA de marketing. Requerir ejercicio interno; no delegues la habilidad de restauración.
Decide y avanza sin puntos ciegos
- Programar la próxima prueba en el calendario (fecha fija, no “cuando tengamos tiempo”).
- Preparar entorno de pruebas + conjunto de datos representativo.
- Juega los escenarios A y B con cronómetro.
- Repare la canalización de respaldo antes de cerrarla.
- Compare hosts sobre la facilidad de restauración a través de directorio.
Véase también prueba de restauración para documentar el ejercicio para los clientes u oyentes.
Preguntas frecuentes
¿Con qué frecuencia probar una restauración?
Mínimo trimestral para un sitio crítico; bianual para un escaparate. Vuelva a realizar la prueba después de un cambio importante en la infraestructura o en la copia de seguridad.
¿Deberíamos restablecer la producción?
No. Caja de arena aislada. El ejercicio mide el proceso, no la disponibilidad en vivo.
¿Qué hacer si falla la restauración?
Documente la causa, arregle la tubería, vuelva a realizar la prueba dentro de una semana con pruebas.
¿Restauración parcial o completa?
Ambos dependiendo del escenario: tabla eliminada = parcial; ransomware = reconstrucción completa a partir de una copia antigua y saludable.
Una copia de seguridad de sandbox sin restaurar no es un seguro. Es una hipótesis, y las hipótesis siempre surgen los martes por la noche.