Continuidad y recuperación ante desastres

¿Qué es la continuidad y en qué se diferencia del respaldo?

Conviene empezar por la distinción que más confusión causa, porque de ella depende todo lo demás. El respaldo responde a una pregunta: «¿tengo una copia de mis datos?». La continuidad responde a otra mucho más exigente: «¿puedo seguir operando cuando algo falla, y volver a la normalidad a tiempo?». Son dos capas distintas. La continuidad de negocio (BCP) mantiene funcionando los servicios críticos durante la interrupción —personas, comunicaciones, procesos alternativos—, mientras que la recuperación ante desastres (DR) restaura la tecnología y los datos para cumplir los objetivos acordados. El sector lo resume con un dato incómodo: la mayoría de los proveedores ofrecen «backup y recuperación», pero la pregunta es si lo que entregan es realmente continuidad o solo copias. Tener copias es la base imprescindible; convertirlas en una recuperación que de verdad ocurre, dentro del tiempo que el negocio tolera, es lo que añade la continuidad.

Tener copias no es tener continuidad

Lo vemos a diario desde el otro lado, el de la recuperación de emergencia: empresas con copias que, llegado el momento, no sirvieron. La causa número uno de recuperaciones fallidas es un backup que todos creían que corría y que en realidad nunca terminó, o que nunca se probó restaurando. A veces el problema es más sutil: se confunden las instantáneas con un respaldo real, o se descubre tarde que un backup no probado no es un backup. La continuidad cierra esa brecha porque no se conforma con que la copia exista: exige que esté probada, que la restauración encaje en el tiempo objetivo y que alguien sepa exactamente qué hacer, en qué orden, a las tres de la madrugada. Esa diferencia —entre suponer y saber— es la que separa una interrupción molesta de una crisis existencial. Y es, también, la razón por la que un laboratorio de recuperación tiene algo que decir aquí: sabemos cómo fallan las recuperaciones porque las arreglamos.

¿Qué son el RTO y el RPO?

Toda la disciplina gira en torno a dos números, y entenderlos bien evita gastar de más y proteger de menos. El RTO (objetivo de tiempo de recuperación) es cuánto puede estar caído un sistema antes de que el daño sea inaceptable: si tu RTO de facturación es de cuatro horas, toda tu cadena de recuperación debe entregar dentro de esa ventana. El RPO (objetivo de punto de recuperación) es cuántos datos puedes permitirte perder, medidos en tiempo: un RPO de una hora significa que debes copiar al menos cada hora, o arriesgas perder todo lo hecho desde la última copia. La clave, que muchos pasan por alto, es que el RTO y el RPO son compromisos de negocio, no métricas de TI: los fija la dirección según lo que cuesta cada hora de parada, y de ellos se derivan la arquitectura y la inversión. Cómo fijarlos sin quedarse corto ni pasarse lo explicamos en detalle en cómo fijar el RTO y el RPO. Apuntar a objetivos muy ajustados es legítimo, pero encarece todo: más redundancia, más observabilidad y más pruebas.

El análisis de impacto al negocio (BIA): por dónde se empieza

Antes de comprar tecnología o prometer tiempos, hay que saber qué hay que proteger y con qué urgencia, y para eso existe el análisis de impacto al negocio (BIA). Es el ejercicio de listar los procesos de la empresa, estimar qué pasa —en dinero, en cumplimiento, en reputación— si cada uno se detiene, y a partir de ahí asignar a cada sistema su RTO y su RPO. El BIA no tiene que ser un proyecto de consultoría de meses; sí tiene que ser honesto. Su resultado más útil es una clasificación por niveles de criticidad: los sistemas Tier 0 —los que sostienen el ingreso o la seguridad, como facturación, pagos, identidad o atención al cliente— exigen los tiempos más ajustados; los Tier 1 y Tier 2 admiten ventanas más holgadas. Esa jerarquía evita el error más común y más caro: tratar todo como igual de urgente, lo que dispara el costo sin mejorar la resiliencia donde de verdad importa. No todo necesita un RTO de cuatro horas, y reconocerlo es parte de hacerlo bien. Esta etapa la desarrollamos como servicio en plan de continuidad de negocio y BIA.

Mapa de dependencias y runbooks

Un sistema rara vez vive solo, y los planes que ignoran eso fallan en el peor momento. Por eso, tras el BIA, levantamos un mapa de dependencias: qué aplicación necesita qué base de datos, qué servicio depende de qué red, y —el punto que más se olvida— las dependencias que no son de TI, como la identidad, las telecomunicaciones, los servicios SaaS de terceros y los proveedores. Con ese mapa escribimos los runbooks de recuperación: guías paso a paso que dicen, sin ambigüedad, cómo levantar cada servicio, en qué orden, quién lo hace y cómo se verifica que quedó bien. Un buen runbook convierte el conocimiento que vive en la cabeza de una persona —y que desaparece cuando esa persona está de vacaciones durante la crisis— en un procedimiento que cualquiera del equipo puede ejecutar. La documentación, aquí, no es burocracia: es la diferencia entre improvisar bajo presión y seguir un plan probado.

La continuidad va más allá de la tecnología: personas y comunicación

Es fácil reducir la continuidad a servidores y copias, pero la parte de negocio —el BCP— es igual de decisiva, y es la que más se descuida. Un plan completo define cómo siguen trabajando las personas durante la interrupción: ubicaciones alternativas, procesos manuales de respaldo y, sobre todo, un plan de comunicación que diga quién decide activar el plan, quién informa a clientes y empleados, y por qué canal cuando el correo corporativo es justo lo que está caído. También fija el orden de prioridades acordado entre las áreas de negocio y TI, para que en plena crisis nadie discuta qué se levanta primero. La tecnología restaura los sistemas; las personas mantienen viva la operación mientras tanto. Un plan que ignora ese lado humano falla aunque la recuperación técnica sea impecable, porque una empresa no se reduce a sus servidores: es su gente sabiendo qué hacer.

¿Cómo se restaura el servicio? Estrategias de recuperación

Con los objetivos claros y las dependencias mapeadas, se decide cómo se vuelve a operar, y hay un abanico de estrategias según el RTO que se persiga. En un extremo está la restauración desde copias, más lenta pero más económica, válida para sistemas que toleran ventanas amplias. En el otro, la replicación con failover hacia un sitio alterno o la nube, que permite retomar la operación en minutos para los sistemas Tier 0. Entre medias caben la corrida en paralelo —levantar el entorno de recuperación sin interrumpir producción para validar— y los esquemas de sitio templado o frío. La regla es sencilla: la estrategia se elige por el objetivo, no al revés. Aquí es donde el respaldo se conecta con la continuidad, porque una recuperación rápida se apoya en copias bien diseñadas, como las copias inmutables y aisladas o el respaldo de servidores y máquinas virtuales que sostienen el failover.

¿Y los servicios SaaS de terceros?

Hay un punto ciego que casi todos los planes comparten: los servicios SaaS de terceros rara vez se incluyen en la continuidad. Se da por hecho que «está en la nube, luego está protegido», y no es así. Bajo el modelo de responsabilidad compartida, el proveedor mantiene la plataforma, pero tus datos siguen siendo tu responsabilidad: un borrado accidental, un empleado que se va, un ransomware que cifra los archivos sincronizados o una cuenta comprometida pueden hacer desaparecer información de la que el proveedor no guarda una copia recuperable para ti. Por eso un plan de continuidad serio inventaría también los SaaS críticos —correo, suites ofimáticas, CRM— y define cómo se respaldan y se restauran. Es la misma lógica que aplicamos al respaldo de Microsoft 365 y Google Workspace: lo que vive en la nube de otro también necesita su red de seguridad y su prueba de restauración.

¿Por qué un plan sin probar no es un plan?

Esta es la sección que más nos importa, porque es donde casi todos los planes mueren. Un plan de continuidad que nunca se ha probado es una hipótesis, no una garantía; las pruebas son lo único que confirma si tus RTO y RPO son alcanzables de verdad y dónde se rompen. Hay varios niveles, y conviene combinarlos: la lista de verificación revisa que el plan esté completo; el ejercicio de mesa (tabletop) hace que el equipo recorra un incidente simulado sobre el papel; la prueba en paralelo levanta los sistemas en el entorno de recuperación sin tocar producción; y el failover completo ejecuta el cambio real al sitio de recuperación y la vuelta. La cadencia recomendada es clara: como mínimo una prueba completa al año y tras cada cambio importante, ejercicios de mesa cada trimestre y failover parciales cada semestre. Y un requisito que no admite atajos: la prueba debe incluir una restauración real, no una revisión en papel. Un backup que no se ha restaurado nunca es una promesa, no una copia. Estos ensayos los ofrecemos como servicio en pruebas de recuperación (DR drills).

Continuidad frente al ransomware

El ransomware merece párrafo propio porque cambió las reglas de la continuidad. Ya no basta con tener copias: hay que asegurarse de que el atacante no pueda cifrarlas ni borrarlas, y de que al restaurar no se reintroduzca el malware. Por eso un plan de continuidad frente a ransomware se apoya en copias inmutables y aisladas (air-gap) y en runbooks de recuperación que contemplan el aislamiento de la red, la verificación de que la copia está limpia y el orden seguro de restauración. La meta es poder restaurar el servicio sin pagar rescate, que es la única respuesta que no financia el siguiente ataque. Cuando el incidente ya está en curso, la recuperación ante ransomware entra en acción; pero la diferencia entre una crisis de días y una de horas se decide antes, en si todo esto se ensayó. La continuidad es, en el fondo, la versión preventiva de lo que hacemos cuando ya es tarde.

Cómo construimos tu plan de continuidad

Ordenamos todo lo anterior en cinco etapas, de la pregunta de negocio a la prueba que lo demuestra.

# Cada servicio recibe un nivel de criticidad y sus objetivos
SERVICIO               TIER    RTO        RPO
Facturación / POS      Tier 0  < 1 h      < 5 min
Identidad / acceso     Tier 0  < 1 h      < 5 min
Correo corporativo     Tier 1  < 4 h      < 1 h
ERP / contabilidad     Tier 1  < 4 h      < 1 h
Archivo histórico      Tier 2  < 48 h     < 24 h

# Regla: cada objetivo se valida con una restauración real, no en papel.
Estado pruebas: Tier 0 OK (mensual) · Tier 1 OK (trimestral)

Nuestro papel honesto: qué hacemos y qué no

Preferimos ser claros sobre dónde aportamos valor, porque en continuidad las medias verdades se pagan caras. Lo que hacemos: el análisis de impacto (BIA), la definición de RTO/RPO, el mapa de dependencias, los runbooks, el diseño de la arquitectura de recuperación y las pruebas con restauración real. Y, cuando llega el desastre, la ejecución de la recuperación: somos, literalmente, el laboratorio que rescata los datos y levanta los sistemas. Lo que no hacemos: no vendemos un sitio de failover propio como si fuéramos un proveedor de nube. La infraestructura de recuperación —el sitio alterno, la replicación, el cómputo en la nube— se implementa con tu proveedor de infraestructura, y nosotros la diseñamos, la integramos y, sobre todo, la validamos para que el día de la verdad responda. Esa honestidad es deliberada: hay quien promete una continuidad «llave en mano» que en la práctica es solo backup con otro nombre. Nosotros preferimos decir qué capa pone cada quién, y responder por la que es nuestra. Todo bajo los estándares de calidad y cadena de custodia del laboratorio.

Casos frecuentes en empresas panameñas

La necesidad de continuidad en Panamá rara vez llega como un proyecto ordenado; suele llegar después de un susto. Vemos a la pyme que sobrevivió a un ransomware pagando un precio altísimo en días de parada y que ahora quiere no repetirlo; a la empresa de servicios financieros o de salud a la que un requisito regulatorio o un cliente grande le exige demostrar un plan de continuidad probado; y a la operación logística o comercial que entendió, tras una tormenta o un corte largo, cuánto cuesta cada hora detenida. Para todas, el camino es el mismo y empieza con una conversación honesta sobre qué procesos no pueden parar. Partimos a menudo del plan de recuperación ante desastres para pymes como base y lo elevamos a un programa probado. Coordinamos el trabajo en toda la república y, si el desastre ya ocurrió y la operación está detenida, activamos la línea de emergencia y entramos por donde mejor sabemos: recuperando.

Preguntas frecuentes