No se ha perdido nada. No ha fallado nada. No se ha intentado ninguna restauración que haya vuelto vacía. Quiero decir esto claramente desde el principio, porque el resto de esta entrada resulta incómodo de una manera muy concreta, y sería igual de deshonesto exagerarlo para que pareciera más dramático de lo que es. Esta es una entrada sobre una brecha que existe ahora mismo, hoy, que conozco y que no he cerrado. Es un riesgo identificado y admitido —del tipo que es fácil dejar siempre para “ya me pondré con ello”— y merece la pena dejarlo por escrito precisamente porque escribirlo es una forma de no dejar que eso siga ocurriendo en silencio.
La brecha es esta: los datos de producción existen sin una vía de restauración verificada, probada y fuera del nodo. Existe un trabajo de copia. Lo que no existe es una forma demostrada de coger esa copia y reconstruir con ella un sistema funcional, en un hardware que no sea la máquina que actualmente contiene el original.
Por qué “tengo los datos” y “tengo un backup” son afirmaciones distintas
Resulta tentador tratar “los datos están copiados en algún sitio” como equivalente a “los datos tienen backup”, pero no lo son. Un backup es una afirmación sobre el futuro: en concreto, la afirmación de que cuando algo falle en el original, existe una vía para volver desde la copia a un estado funcional. “Los datos están copiados en algún sitio” es una afirmación sobre el presente: ahora mismo, los bytes existen en dos sitios. Son propiedades genuinamente distintas, y precisamente en esa distancia entre ambas es donde las estrategias de backup fallan en silencio, sin que nadie se dé cuenta hasta el momento en que se necesitan.
La brecha tiene varias formas de esconderse. Un trabajo de copia puede estar ejecutándose y fallando en silencio a mitad de camino: escribiendo un archivo parcial, o deteniéndose por un error que queda registrado en algún log que nadie revisa. Una copia puede completarse perfectamente y aun así ser inútil, porque lo que hay al otro lado no basta en realidad para reconstruir un sistema en marcha: puede que sean los archivos de datos pero no la configuración que les da sentido, o un volcado de base de datos tomado a mitad de una escritura, internamente inconsistente de una forma que solo se manifiesta al intentar cargarlo. Una copia puede ser completa y consistente a la vez, y aun así fallar en el momento de la restauración por motivos que no tienen nada que ver con los datos en sí: permisos que no se trasladan bien a un hardware distinto, una estructura de directorios asumida que en realidad no está ahí, una dependencia de algo específico de la máquina original que nadie se molestó en documentar porque nunca se probó de verdad en otro sitio.
Ninguno de estos modos de fallo es exótico. Son las formas corrientes y aburridas en las que fallan los backups, y lo único que las descarta todas a la vez es hacer de verdad la restauración: en un hardware distinto, partiendo de cero, y comprobando que lo que sale al otro lado funciona de verdad. Hasta que eso no ha ocurrido, “tengo una copia” y “tengo un backup” no son la misma frase, por muy segura que sonara la última línea del log del trabajo de copia.
Por qué lo no probado es, en la práctica, lo mismo que lo inexistente
La conclusión incómoda a la que lleva esto es que un backup no probado y la ausencia total de backup están más cerca entre sí, en términos de en qué se puede confiar realmente, que cualquiera de los dos de un backup probado. Suena a exageración hasta que uno se para a pensar qué significa realmente “no probado”: significa que la vía de restauración tiene una probabilidad desconocida de funcionar, y que esa probabilidad nunca se ha medido. Podría ser alta. También podría ser baja, por razones que resultan invisibles hasta el momento en que se necesita, y ese momento es, por definición, el peor momento posible para descubrir cuál de las dos era. Una brecha conocida se puede planificar. Una red de seguridad que se da por hecha pero que en realidad no está ahí es una posición mucho peor, porque cambia qué otros riesgos parecen aceptables de asumir, apoyándose en una garantía que todavía no se ha ganado.
Esa es la razón honesta por la que merece la pena nombrar esta brecha públicamente en lugar de guardarla en silencio hasta que esté resuelta: ahora mismo, las decisiones sobre qué otros riesgos son aceptables en esta infraestructura se apoyan implícitamente en una capacidad de restauración que no se ha demostrado que exista. Nombrar esa brecha explícitamente es la única forma de asegurarse de que realmente se tiene en cuenta como brecha, en lugar de darla por cubierta en silencio.
Qué hace falta realmente para cerrar esto
Cerrar esto no es simplemente hacer más grande el trabajo de copia que ya existe. Tienen que cumplirse tres condiciones, y ninguna es opcional:
La copia tiene que vivir en un sitio genuinamente independiente del original: fuera del nodo en el sentido real, no simplemente en un disco distinto de la misma máquina, y tampoco en una máquina distinta que comparta dominio de fallo con el original (misma alimentación eléctrica, mismo segmento de red, misma ubicación física) hasta el punto de que lo que tumbe al original tenga bastantes papeletas de tumbar también a la copia.
La restauración tiene que ejecutarse de verdad, no darse por supuesta. Eso significa coger la copia fuera del nodo y reconstruir con ella un sistema funcional en un sitio que no sea el original: en una máquina genuinamente distinta, idealmente una que no tenga ya la respuesta guardada por alguna otra vía. Una prueba de restauración que en el fondo se apoya en un estado que sigue presente en la máquina original no ha probado nada.
Y tiene que ejecutarse más de una vez, con una cadencia, no como una prueba puntual que luego queda obsoleta. La configuración se desvía, los datos crecen, las dependencias cambian: una restauración que funcionó hace seis meses es evidencia de hace seis meses, no de hoy. Esta es la parte que más fácil resulta dejar pasar, porque una prueba de restauración que salió bien una vez da la sensación de haber zanjado la cuestión para siempre, cuando en realidad solo la zanjó para ese momento concreto.
Ninguna de las tres cosas es ingeniería exótica. Las tres exigen tiempo real y deliberado, y precisamente por eso este es el tipo de brecha que sobrevive en silencio más tiempo del que debería: siempre hay algo que parece más urgente que demostrar algo que uno espera no necesitar nunca.
Por qué una copia en otro hardware no es automáticamente “fuera del nodo”
Vale la pena señalar una trampa concreta, porque es la que más probablemente genera una confianza falsa: tener una segunda copia en una segunda máquina no es lo mismo que tener un almacenamiento fuera del nodo genuinamente independiente, si esa segunda máquina comparte suficiente dominio de fallo con la primera. Mismo circuito eléctrico, mismo switch de red, misma sala física, misma cuenta de administración con acceso a ambas: cualquiera de estas cosas es una vía por la que lo que tumbe al original podría plausiblemente tumbar también a la copia, al mismo tiempo o poco después. Una copia que muere junto con el original nunca fue realmente una segunda copia en el sentido que importa; era un único dominio de fallo con dos discos dentro.
La independencia, en el sentido que necesita un backup de verdad, significa preguntarse específicamente qué tendría que salir mal para que el original y la copia queden ambos inaccesibles a la vez, y quedarse satisfecho solo si la respuesta es un evento significativamente distinto y menos probable que lo que tumbaría al original en solitario. Ese listón es más alto que “es una pieza de hardware distinta”, y es el listón que este montaje todavía no supera: la respuesta honesta ahora mismo a “dónde vive la copia fuera del nodo y qué no comparte con el original” no está lo bastante resuelta como para dar la brecha por cerrada.
La trampa de tratarlo como “lo siguiente de la lista” para siempre
Parte de por qué este tipo de brecha sobrevive es una forma concreta y muy conocida de autoengaño: nunca suspende la prueba de “es esto urgente” en un día cualquiera, porque en un día cualquiera todavía no ha fallado nada, y el coste real de no tener una vía de restauración probada es cero hasta el día en que deja de serlo. Esa asimetría —cada día de retraso parece gratis, hasta que un día deja de serlo de golpe— es exactamente lo que permite que un trabajo genuinamente importante pero no urgente quede desplazado en silencio por lo que parezca más apremiante esa semana, indefinidamente. No hay ninguna presión natural de plazo que empuje en contra, porque el riesgo no se anuncia con un reloj corriendo. Simplemente está ahí, correctamente modelado como “algún día esto podría importar muchísimo” pero tratado, en la práctica, incorrectamente como “hoy no”.
Dejarlo por escrito es una contramedida pequeña y concreta frente a ese patrón. Una brecha que solo existe como una sensación privada y difusa de “ya me pondré con eso” es fácil de seguir postergando indefinidamente, porque no hay ningún artefacto fijo que obligue a comparar la fecha de hoy con la fecha en la que se suponía que esto debía estar resuelto. Una brecha fechada, publicada y concreta sobre las tres condiciones que la cierran es otra cosa distinta: es una afirmación con una forma que se puede contrastar más adelante, y comprobar si se ha cumplido o no. Eso no arregla la asimetría de fondo entre lo urgente que esto parece día a día y lo mucho que importaría el día en que se ponga a prueba. Pero sí hace más difícil seguir aplazándolo en silencio sin al menos darse cuenta de que eso es lo que está pasando.
Por qué publicar esto en lugar de esperar a que esté resuelto
La versión honesta de un informe de estado sobre este tipo de riesgo no es decir “todo está cubierto” antes de que sea cierto de verdad. Es esto: una declaración clara de qué hay realmente en marcha, qué no lo hay, y qué tiene que pasar específicamente para cerrar la distancia entre ambas cosas. Eso es legítimo publicarlo antes de que llegue la solución, no una confesión que deba esperar a un final más ordenado. Una brecha que está escrita, fechada y es concreta sobre lo que hace falta para cerrarla es mucho más difícil de olvidar en silencio que una que solo existe como una preocupación vaga de fondo. Esta entrada es exactamente eso: el modelo de riesgo, nombrado, con las tres condiciones concretas que lo cierran: un almacenamiento fuera del nodo genuinamente independiente, una restauración que se haya ejecutado de verdad, y una cadencia de repetición para que esa prueba no quede obsoleta. La que de las tres llegue primero será una continuación más corta y mejor que esta.
Mientras tanto, Recuperación ante desastres antes de tener backups reales cubre el control compensatorio que hace que esta brecha sea sobrellevable mientras sigue abierta: triaje ensayado y documentación como fuente de verdad, que reducen el daño de un fallo sin pretender ser un sustituto de la vía de restauración de la que trata esta entrada.