Código, infraestructura y configuración
Se reconstruye desde el repositorio de forma reproducible. No requiere copia de seguridad en sentido clásico: requiere que la reconstrucción funcione, que es una propiedad verificable de otra manera.
La vía de recuperación es reconstruir, no reparar
Toda la infraestructura —el clúster, los despliegues y su configuración— está declarada como código versionado, no configurada a mano. Ante una interrupción grave, el camino previsto no es reparar un servidor dañado, sino levantar el entorno de nuevo desde el código y restaurar los datos sobre él.
Esa decisión de diseño divide el problema en dos mitades con tratamientos distintos.
Los datos
Los datos productivos y el estado de las bases de datos no pueden regenerarse. Son el objeto real de las copias de seguridad y la razón de que estas se mantengan fuera del clúster que las origina.
La consecuencia práctica es que la continuidad no descansa en manuales de recuperación, sino en que el entorno se pueda levantar de nuevo. Un procedimiento documentado que nunca se ha ejecutado no acredita capacidad de recuperación.
Una caída degrada hacia «sin acceso», nunca hacia «acceso no gobernado»
El punto de aplicación de políticas opera en modo de denegación por defecto. Ante un fallo o una duda, deniega. Esto significa que una interrupción se manifiesta siempre como pérdida de disponibilidad, y nunca como una apertura del control de acceso.
Es una elección deliberada y no es gratuita: convierte ciertos fallos parciales en indisponibilidad. La alternativa —degradar hacia el acceso abierto para preservar el servicio— resulta inaceptable en una infraestructura cuya función es gobernar quién ve qué dato.
| Prioridad 1 | Capa de consumo gobernado y su punto de aplicación de políticas. Sin ella el cliente no consulta sus datos; con ella degradada, tampoco se accede sin gobierno. |
| Prioridad 1 | Datos productivos del cliente. Es el activo cuya pérdida resulta menos tolerable y el que determina la estrategia de copias. |
| Prioridad 2 | Plano de identidad y acceso. Sin él nadie se autentica, lo que bloquea también la propia recuperación. |
| Prioridad 2 | Sustrato de ejecución, y el código y los secretos necesarios para reconstruir. |
| Prioridad 3 | Servicios de soporte interno, que toleran ventanas de recuperación mayores sin impacto en el cliente. |
Criterios de copia y de verificación
El plan de continuidad fija los requisitos de respaldo de los sistemas con estado, y establece que su utilidad debe acreditarse mediante restauración, no mediante la existencia del fichero de copia.
| Independencia | Las copias residen en un almacenamiento externo al clúster que las genera, de modo que la pérdida del entorno no arrastre a su propio respaldo. |
| Protección | Las copias heredan la clasificación de la información que contienen y, con ella, su nivel de cifrado y de control de acceso. Ninguna copia rebaja la protección del dato original. |
| Verificación | El criterio del plan es explícito: una copia nunca restaurada no se considera copia. Por eso la prueba de restauración periódica forma parte del plan y no de su documentación complementaria. |
| Redundancia proporcional | La redundancia se introduce de forma proporcional a la madurez de cada servicio. Donde no hay alta disponibilidad, el control compensatorio declarado es la reconstrucción desde código sobre copia verificada, con un objetivo de recuperación acorde. |
Los objetivos concretos de recuperación —tiempo de restauración y pérdida máxima tolerable por servicio—, la arquitectura de copias y el estado de cada control se facilitan como parte de la documentación contractual y de la revisión de proveedor. Preferimos no publicarlos en abierto: son información operativa cuyo detalle interesa a quien evalúa el servicio y también a quien quisiera atacarlo.
Quién recupera qué
La continuidad se reparte igual que el resto de controles. El detalle completo está en la matriz de responsabilidad compartida.
Opendome recupera
Opendome opera la recuperación de extremo a extremo: reconstrucción del entorno, restauración de los datos y verificación de integridad antes de devolver el servicio.
Reparto explícito
Opendome opera la recuperación del software y de la plataforma. El destino, la retención y la residencia de las copias corresponden al cliente sobre su propia infraestructura, y se fijan en el acuerdo.
Del operador
La continuidad es responsabilidad de quien opera el despliegue. Opendome entrega artefactos firmados que permiten reconstruir el entorno desde la infraestructura declarada como código.
Qué sigue funcionando sin nosotros
La pregunta que un comité de riesgos formula sobre cualquier proveedor de infraestructura no es solo qué pasa si se cae, sino qué pasa si desaparece. En un producto propietario, la respuesta depende de cláusulas de custodia de código y de la voluntad del proveedor. Aquí depende de la arquitectura.
Abierto e inspeccionable
El núcleo de la plataforma se distribuye bajo licencia de código abierto. Los derechos de uso, modificación y redistribución no dependen de la continuidad de la empresa que lo desarrolla.
En formatos estándar
El almacenamiento emplea formatos abiertos legibles por cualquier motor compatible del ecosistema. Los datos siguen siendo utilizables sin conversión previa y sin herramientas propietarias.
Reconstruible desde código
La misma propiedad que sostiene nuestra recuperación sirve a la del cliente: artefactos firmados y despliegue declarado permiten levantar el entorno con otro operador.
No es una promesa contractual añadida sobre un producto cerrado, sino una consecuencia de cómo está construido. Es la misma razón por la que se puede auditar lo que hace el sistema en lugar de confiar en que hace lo que dice.
Revisión de resiliencia
Sesión con vuestro equipo de riesgos para revisar los objetivos de recuperación aplicables al modelo de despliegue que os corresponda, la arquitectura de respaldo y la documentación que necesitáis para vuestro expediente de proveedor.
Solicitar reunión técnica