Una copia de seguridad que nadie ha restaurado no es una copia de seguridad

A la pregunta «¿nos hacemos copias de seguridad?» el especialista técnico casi siempre responde afirmativamente, y responde honestamente: la tarea está en el programador, los archivos se crean, ocupan espacio. El responsable pone una marca mental y vuelve a sus asuntos.

El problema es que la pregunta formulada no era la correcta. La correcta suena así: ¿cuándo fue la última vez que nos restauramos desde estas copias y cuánto tiempo tomó?

La diferencia entre las dos preguntas se revela exactamente una vez: el día en que la restauración realmente es necesaria.

Qué se descubre ese día

La lista es corta y se repite de empresa en empresa.

Las copias estaban en el mismo servidor. La copia de seguridad se configuró en la partición vecina del mismo disco. El disco falló: desapareció todo.

Los archivos están vacíos. El script de copias se rompió tras una actualización de la base de datos hace medio año y desde entonces creaba archivos de tamaño cero. Nadie lo comprobó porque la tarea finalizaba sin error.

La copia existe, pero no la clave. Los archivos estaban cifrados; la clave la tenía un empleado que se fue.

La restauración tarda más de lo previsto. Todos estaban seguros de que estaría listo en una hora. Desplegar una base de varios terabytes desde un volcado lógico tardó casi dos días, y durante todo ese tiempo el negocio no funcionó.

No se restauró todo. La base se levantó, pero la configuración de servidores, el contenido del almacenamiento de objetos, los certificados y las credenciales de servicios externos no formaban parte de la copia de seguridad: simplemente no se pensó en ello. Una base operativa sin la aplicación que sabe trabajar con ella no restaura el negocio.

La replicación no es una copia de seguridad

Merece una explicación aparte la confusión más frecuente.

La réplica repite los cambios de la base principal casi instantáneamente —y esa es su ventaja ante una falla de hardware. Y esa misma cualidad la hace inútil ante cualquier otro tipo de desastre: un comando de borrado ejecutado por error, una migración incorrecta, la acción de un cifrador malicioso o de un empleado con malas intenciones se reproducen en la réplica en segundos. Los datos borrados en el servidor principal acaban borrados también en la réplica.

La réplica protege contra fallos del hardware. La copia de seguridad protege contra errores, y los errores ocurren con más frecuencia que el fallo de los discos.

De ahí las consecuencias prácticas: las copias deben almacenarse separadas de la infraestructura productiva y, siempre que sea posible, en un modo que impida modificaciones y borrados durante el periodo de retención. La cuenta con la que opera el sistema productivo no debe tener permiso para borrar las copias de seguridad —de lo contrario quien obtenga acceso las destruirá como primera medida. Esto es exactamente lo que hacen los secuestradores modernos: primero los backups, luego todo lo demás.

La regla clásica sigue siendo válida: tres copias de los datos, en dos soportes diferentes o con dos proveedores distintos, y una fuera del sitio principal.

Qué debe incluirse en las copias

Además de la base de datos:

• La configuración de los servidores y la descripción de la infraestructura.
• El contenido del almacenamiento de objetos —los archivos y documentos subidos por los usuarios.
• Credenciales y claves de acceso a servicios externos, en forma trasladable.
• La configuración de la zona DNS: no se podrá reconstruir de memoria en el momento del desastre.
• Las instrucciones mismas de recuperación —si sólo existen en el sistema que ha caído, no las tiene.

Simulacros: cómo comprobar sin romper nada

La comprobación no requiere intervenir en el entorno productivo. Basta con tres pasos y un día de trabajo.

1. Entorno limpio. Tome un servidor nuevo en un entorno aislado. Nuevo: restaurar en una máquina donde ya existe el entorno no demuestra nada —verificará la copia, pero no la integridad del procedimiento.

2. Restauración solo desde el almacenamiento externo. Los ingenieros cogen las copias del almacenamiento remoto habitual y despliegan el sistema desde cero. Nada de archivos de los servidores productivos, nada de “ahora me acuerdo y añado la configuración”: todo lo que falte se anota en la lista de huecos.

3. Cronometraje y verificación del resultado. Se mide el tiempo desde el inicio hasta el momento en que el sistema está accesible y puede aceptar pedidos. Hay que comprobar el escenario operativo completo, no solo la disponibilidad de la página de inicio.

Los primeros simulacros casi siempre dan un resultado desagradable: el procedimiento lleva muchas más horas de las esperadas y se detectan dos o tres elementos faltantes. Esa es la utilidad: descubrirlo en condiciones controladas cuesta un día laboral; descubrirlo en el momento del desastre cuesta la parada del negocio.

El tiempo obtenido —ese es su RTO real. No el que figura en el documento, sino el que está verificado. Frecuencia razonable: una vez por trimestre, y siempre después de cambios importantes en la arquitectura.

Otra comprobación que se olvida

La restauración verifica que los datos vuelvan. Separadamente conviene comprobar que son correctos.

Tras la restauración, contraste indicadores clave: número de pedidos del último mes, suma de saldos, número de usuarios activos. La copia puede desplegarse técnicamente sin fallos y aun así contener datos con una semana de retraso respecto a lo esperado —por ejemplo, porque la tarea de copia se ejecutaba antes, y no después, del procesamiento nocturno.

Tres preguntas que conviene hacer hoy

Se pueden plantear ahora mismo en el chat de trabajo. No se aceptan respuestas abstractas tipo «todo está configurado» —se necesitan concretas.

1. ¿Dónde están físicamente las copias?
Respuesta aceptable: con otro proveedor o al menos en otra ubicación, en un almacenamiento desde el que el sistema productivo no pueda eliminarlas.

2. ¿Cuándo fue la última vez que desplegamos el sistema desde estas copias en un servidor limpio y cuánto tardó?
Respuesta aceptable: una fecha concreta dentro del último trimestre y un tiempo concreto en horas. La respuesta «cuando se configuró, hace tres años» significa ausencia de copias verificadas.

3. ¿Qué exactamente no se recuperará si la ubicación desaparece por completo?
Una reacción sensata: una lista breve y honesta. La respuesta «todo se recuperará» sin simulacros realizados significa que la cuestión no se ha estudiado.

El plan de recuperación ante desastres no existe para los auditores. Un plan no verificado deja de funcionar en el primer paso durante una emergencia real, donde la realidad difiere del documento —y siempre difiere.

Análisis relacionados: RTO y RPO — cómo establecer requisitos de recuperación en términos de negocio, y los primeros 30 minutos tras la caída — qué hace el equipo mientras dura la recuperación.