Plan de Recuperación ante Desastres (DRP): Qué Es y Cómo Crearlo para tu Empresa

Un informe de Splunk y Oxford Economics calculó que el tiempo de inactividad no planificado le cuesta a las 2.000 empresas más grandes del mundo unos 600.000 millones de dólares al año, un 50% más que apenas dos años antes. Para una empresa individual eso equivale, en promedio, a cerca de 15.000 dólares por minuto fuera de línea. AWS, por su parte, estima que una hora de caída puede costarle a una empresa entre 100.000 y 1 millón de dólares, dependiendo de su tamaño y del sistema afectado. Y según un estudio de The Diffusion Group entre pymes, el 60% de las que pierden su información terminan cerrando en los siguientes seis meses.

La pregunta no es si en algún momento vas a tener una falla grave — un ransomware, un servidor que se daña, un error humano que borra una base de datos, una inundación en el centro de cómputo — sino qué tan rápido puedes volver a operar cuando pase. Esa respuesta la da (o no) tu plan de recuperación ante desastres.

¿Qué es un plan de recuperación ante desastres (DRP)?

Un plan de recuperación ante desastres (DRP, por sus siglas en inglés, Disaster Recovery Plan) es el documento y el conjunto de procedimientos que definen cómo tu empresa va a restaurar sus sistemas, datos y operaciones de TI después de un incidente grave, con roles, tiempos y pasos ya definidos de antemano — no improvisados en medio de la crisis.

Aquí es donde muchas empresas se confunden: tener backups no es tener un DRP. El backup es apenas uno de los ingredientes. Un DRP completo también define quién hace qué durante la crisis, en qué orden se restauran los sistemas (no todos son igual de críticos), cuánto tiempo y cuántos datos de pérdida son aceptables para cada uno, dónde se restaura si tu oficina o centro de datos principal no está disponible, y cómo se comunica la situación a empleados, clientes y proveedores. Si ya tienes definida tu estrategia de respaldo, nuestra guía sobre backup en la nube vs. backup local es el punto de partida técnico; el DRP es el plan completo que le da sentido operativo a esos backups.

RTO y RPO: las dos preguntas que definen tu plan

Todo DRP serio se construye alrededor de dos métricas, definidas sistema por sistema (no son iguales para el correo corporativo que para el ERP de facturación):

• RTO (Recovery Time Objective): cuánto tiempo máximo puede estar un sistema caído antes de que el daño al negocio sea inaceptable. Si tu RTO para el sistema de facturación es de 4 horas, tu plan — y tu proveedor, si lo tienes externalizado — debe estar diseñado para cumplir ese número, no para “intentarlo”.
• RPO (Recovery Point Objective): cuántos datos puedes permitirte perder, medidos en tiempo. Un RPO de 1 hora significa que, en el peor caso, perderás como máximo la última hora de información antes de la falla — lo que determina cada cuánto necesitas respaldar o replicar esos datos.

Un error común es definir estos números “a ojo” o copiarlos de internet. Deberían salir de un ejercicio real: un análisis de impacto al negocio (BIA, Business Impact Analysis) donde identificas qué sistemas son realmente críticos para seguir operando, facturando o atendiendo clientes, y cuáles pueden esperar un día o dos sin romper nada. Si tu empresa tiene un contrato de soporte TI externalizado, estos mismos tiempos deberían quedar explícitos en el SLA — justamente uno de los puntos que cubrimos en nuestra guía sobre qué debe incluir un contrato SLA de soporte TI.

Tipos de sitio de recuperación

Una vez tienes claros tus RTO/RPO, necesitas decidir dónde vas a restaurar la operación si tu infraestructura principal queda fuera de servicio:

• Sitio frío (cold site): espacio e infraestructura básica lista, pero sin los sistemas activos — hay que instalarlos y configurarlos durante la crisis. El más económico, pero el más lento (días).
• Sitio tibio (warm site): sistemas replicados y configurados, pero no corriendo en tiempo real. Recuperación más rápida que el frío (horas), a un costo intermedio.
• Sitio caliente (hot site): una réplica operativa que puede tomar el control casi de inmediato (minutos). El más caro, reservado normalmente para los sistemas con el RTO más exigente.
• DRaaS (Disaster Recovery as a Service): un proveedor gestiona la infraestructura de recuperación en la nube bajo demanda, con RTO/RPO definidos contractualmente. Para la mayoría de pymes en Bogotá, esta es hoy la opción con mejor relación costo-beneficio frente a mantener un sitio físico propio.

Cómo crear un plan de recuperación ante desastres: 6 pasos

1. Análisis de impacto al negocio (BIA): identifica qué sistemas, datos y procesos son críticos, y qué pasaría —en tiempo y en dinero— si cada uno dejara de funcionar.
2. Define RTO y RPO por sistema: no uses el mismo número para todo; el correo y el ERP de facturación casi nunca tienen la misma criticidad.
3. Diseña la estrategia de respaldo y replicación: con base en esos RPO, decide la frecuencia de backup, si necesitas replicación casi en tiempo real para algún sistema, y dónde se almacenan las copias (la regla 3-2-1 sigue siendo el estándar mínimo).
4. Define roles y plan de comunicación: quién declara la emergencia, quién ejecuta la restauración, quién avisa a clientes y proveedores, y por qué canal — todo esto escrito antes de la crisis, no decidido en caliente.
5. Documenta el plan completo: pasos exactos de restauración, contactos, accesos y dependencias entre sistemas (de nada sirve restaurar la aplicación si la base de datos que necesita sigue caída).
6. Prueba el plan periódicamente: un DRP que nunca se ha simulado es, en la práctica, una suposición. Haz simulacros al menos una vez al año, y cada vez que cambie infraestructura importante.

Errores comunes que vuelven inútil un DRP

• Confundir backup con DRP: tener copias de seguridad no garantiza que sepas restaurarlas rápido, en orden, y sin perder dependencias entre sistemas.
• Nunca probarlo: un plan sin simulacro es solo un documento. La prueba real es la que revela los pasos que faltaban.
• No actualizarlo tras cambios de infraestructura: si renovaste servidores, migraste un sistema a la nube o cambiaste de proveedor de red, el DRP debe reflejarlo. Si tu red o tus equipos ya están mostrando señales de estar quedándose atrás, conviene revisar primero nuestra guía sobre señales de que tu empresa necesita renovar su infraestructura de red, porque un DRP construido sobre infraestructura obsoleta hereda esa misma fragilidad.
• Dejar todo en manos de una sola persona: si la única persona que sabe restaurar el sistema crítico está de vacaciones o ya no trabaja en la empresa, el plan colapsa con ella.
• No definir RTO/RPO reales: sin esos números, ni tu equipo interno ni tu proveedor de TI saben contra qué objetivo están trabajando.

Checklist rápido

• ✅ Identificaste los sistemas críticos y su impacto si fallan (BIA)
• ✅ Tienes RTO y RPO definidos por sistema, no un número genérico
• ✅ Tu estrategia de backup/replicación cumple esos RPO
• ✅ Sabes dónde restaurarías la operación (sitio frío/tibio/caliente o DRaaS)
• ✅ Hay roles y un plan de comunicación escritos, no improvisados
• ✅ El plan está documentado y accesible aunque el sistema principal esté caído
• ✅ Se ha probado con un simulacro en el último año

Un plan de recuperación ante desastres no elimina el riesgo de que algo falle — eso es imposible — pero sí elimina la peor parte: no saber qué hacer cuando falla. En Ecolcomputo ayudamos a empresas en Bogotá a construir ese plan como parte de nuestra línea de backup corporativo, con respaldo, RTO/RPO claros y pruebas reales, no solo una copia de seguridad en la nube que nadie ha verificado.