La continuidad no se compra: se diseña. Antes de hablar de tecnología hay que saber qué procesos sostienen la facturación y la producción, y qué coste tiene cada hora de parada para la empresa.
Qué nos encontramos habitualmente
Nadie ha puesto por escrito cuánto tiempo puede estar parada cada aplicación.
Existen copias, pero no un procedimiento de recuperación probado.
La recuperación depende de una única persona que conoce el entorno.
Las pruebas se posponen porque siempre hay algo más urgente.
Para qué empresas encaja
Empresas industriales, logísticas o de servicios donde una parada prolongada tiene impacto directo en clientes, producción o cumplimiento.
Analizamos procesos críticos, dependencias y tiempos de recuperación actuales frente a los que necesita el negocio.
Qué aplicaciones sostienen cada proceso y en qué orden deben volver.
RTO y RPO acordados
Objetivos de tiempo y de pérdida de datos pactados por escrito, con las medidas que los hacen posibles.
Infraestructura de respaldo
Réplica, backup externo o entorno alternativo en nuestro datacenter según el objetivo definido.
Pruebas y documentación
Simulacros periódicos con informe de resultados y de los ajustes aplicados.
Cómo se implanta
1Entrevistas con dirección y responsables de área.
2Clasificación de aplicaciones por criticidad.
3Diseño de la arquitectura de respaldo y de los procedimientos.
4Prueba de recuperación real y ajuste del plan.
5Revisión periódica cuando cambian aplicaciones o procesos.
Escenarios reales
Incendio o inundación en la sala de servidores
Un incidente físico en la oficina afecta a la vez a los servidores y a las copias si ambos están en el mismo edificio. La continuidad empieza por separar geográficamente el respaldo: una copia fuera de la sede, en nuestro datacenter, permite levantar los servicios esenciales aunque las instalaciones no sean utilizables durante días.
Prueba anual de recuperación
Una vez al año se ejecuta una recuperación planificada de los sistemas críticos y se cronometra el resultado. La prueba sirve para actualizar la documentación, confirmar que los contactos y las credenciales de emergencia siguen siendo válidos y detectar dependencias que nadie recordaba, como un servicio de licencias o un certificado.
Qué incluye el plan
El plan recoge el inventario de sistemas y su criticidad, los objetivos de recuperación acordados por sistema, la arquitectura de respaldo, el orden de restauración, los contactos y credenciales de emergencia, y el calendario de pruebas. Seintec ejecuta la parte técnica y documenta cada prueba con tiempos reales. Las decisiones organizativas —quién activa el plan, cómo se comunica y qué se hace manualmente durante la contingencia— las define la empresa, con nuestro apoyo metodológico. Un plan que sólo cubre la parte técnica deja fuera la mitad de lo que ocurre durante un incidente real.
Qué se arriesga si no se aborda
Plan escrito pero nunca ejecutado
Un documento sin prueba real suele fallar en los detalles: orden de arranque, credenciales caducadas o dependencias externas no contempladas.
Copia y sistema en el mismo lugar
Si el respaldo comparte edificio, alimentación y red con el servidor, cualquier incidente físico afecta a los dos a la vez.
Expectativas no acordadas
Sin objetivos de recuperación escritos, la dirección espera minutos y la técnica prepara horas. La conversación debe tenerse antes del incidente.
El backup permite recuperar datos; la continuidad define en cuánto tiempo y en qué orden vuelve a funcionar el negocio, con los recursos necesarios para conseguirlo.
¿Qué son RTO y RPO?
RTO es el tiempo máximo aceptable hasta recuperar el servicio y RPO la cantidad máxima de información que se puede perder, medida en tiempo.
¿Cada cuánto se debe probar?
Depende de la criticidad y de los cambios del entorno; se acuerda una frecuencia y se documenta cada prueba.
¿Se garantiza que no habrá paradas?
No. Se acuerdan objetivos, medidas y pruebas; ningún proveedor serio garantiza ausencia total de incidentes.
¿Qué objetivos de recuperación son razonables?
Dependen del coste de la parada para cada proceso, no de una cifra genérica. Se acuerdan por sistema: la identidad y la red suelen ir primero, después la aplicación que sostiene la actividad principal y por último el resto. Esos objetivos se documentan, se contrastan con la arquitectura disponible y se revisan en cada prueba.
¿Cada cuánto conviene probar la recuperación?
Como mínimo una vez al año para los sistemas críticos, y siempre que haya un cambio relevante: una migración, una aplicación nueva o un cambio de proveedor. Entre pruebas completas se pueden hacer verificaciones parciales de restauración de ficheros y bases de datos, que son rápidas y detectan la mayoría de problemas.
¿La continuidad es sólo una cuestión técnica?
No. La parte técnica es la mitad: hace falta decidir quién comunica, con qué criterio se decide activar el plan, cómo se informa a clientes y proveedores y cómo se valida el trabajo hecho durante la contingencia. Esa parte organizativa se documenta junto con los procedimientos técnicos.
¿Por dónde se empieza si no hay nada documentado?
Por el inventario y por una conversación de dirección sobre qué procesos no pueden parar y durante cuánto tiempo. Con eso se priorizan tres o cuatro sistemas, se comprueba si la arquitectura actual permite cumplir el objetivo y se corrige lo que falte antes de escribir un documento extenso.
Solicitar revisión de continuidad
Analizamos procesos críticos, dependencias y tiempos de recuperación actuales frente a los que necesita el negocio.