Plan de recuperación ante desastres (DRP): qué es, RTO, RPO y cómo armarlo
Cómo preparar a tu empresa para volver a operar después de una falla grave, un ciberataque o la pérdida de un centro de datos, con objetivos claros y pruebas reales.
Un plan de recuperación ante desastres, o DRP por su sigla en inglés (Disaster Recovery Plan), es un documento que describe cómo recuperar tus sistemas de información después de una falla grave: la caída de un centro de datos, un ransomware, un error humano que borra una base de datos o un corte prolongado de un proveedor. El NIST, en su guía SP 800-34 Rev. 1, lo define como un plan escrito para recuperar uno o más sistemas de información en una instalación alternativa ante una falla mayor de hardware o software o la destrucción de instalaciones.
En esta guía te explicamos en qué se diferencia de un plan de continuidad del negocio, qué son el RTO y el RPO, qué estrategias de recuperación existen y cómo armar y probar un DRP que funcione cuando de verdad lo necesites.
Para qué sirve un DRP
Todas las empresas tienen respaldos de algo. Lo que muchas no tienen es una respuesta clara a estas preguntas:
- Si mañana se cae nuestro sistema principal, ¿cuánto tiempo podemos estar sin él?
- ¿Cuántas horas de datos podemos perder sin que sea grave?
- ¿Quién decide activar la recuperación y quién la ejecuta?
- ¿Dónde vamos a levantar los sistemas si el lugar original no está disponible?
- ¿Alguna vez probamos que los respaldos se pueden restaurar?
Un DRP responde esas preguntas antes de que ocurra el problema, cuando hay tiempo para pensar. Durante una crisis, nadie toma buenas decisiones improvisando.
DRP vs BCP: cuál es la diferencia
Se confunden a menudo, pero cumplen funciones distintas y complementarias.
El plan de continuidad del negocio (BCP, Business Continuity Plan) es más amplio. El glosario del NIST lo describe como la documentación de instrucciones o procedimientos que indican cómo se mantendrán los procesos del negocio durante y después de una interrupción significativa. Incluye personas, oficinas, proveedores, comunicaciones y procedimientos manuales alternativos.
El DRP se enfoca en la tecnología: cómo recuperar sistemas, aplicaciones y datos.
| Aspecto | DRP | BCP |
|---|---|---|
| Foco | Sistemas de información y datos | Procesos de negocio completos |
| Pregunta central | ¿Cómo recuperamos la tecnología? | ¿Cómo seguimos operando? |
| Responsable habitual | TI e infraestructura | Gerencia y áreas de negocio, con TI |
| Ejemplos de contenido | Respaldos, sitio alterno, orden de restauración | Trabajo remoto, proveedores alternativos, comunicación con clientes |
| Relación | Es una pieza del BCP | Contiene o se apoya en el DRP |
Dicho simple: el BCP asegura que la empresa siga funcionando; el DRP asegura que la tecnología vuelva a estar disponible para que eso sea posible.
RTO y RPO: los dos números que definen tu plan
RTO: cuánto tiempo puedes estar detenido
El RTO (Recovery Time Objective, objetivo de tiempo de recuperación) es, según el NIST, el tiempo total que los componentes de un sistema pueden estar en fase de recuperación antes de afectar negativamente la misión o los procesos del negocio. En simple: cuánto tiempo puede estar caído un sistema.
RPO: cuántos datos puedes perder
El RPO (Recovery Point Objective, objetivo de punto de recuperación) es, según el NIST, el punto en el tiempo al que deben recuperarse los datos después de una interrupción. En simple: hasta qué momento debes poder volver. Si respaldas una vez al día, en el peor caso podrías perder casi un día completo de información.
Cómo definirlos
El RTO y el RPO no los decide TI sola. Se definen con las áreas de negocio, a partir de un análisis de impacto en el negocio (BIA): qué procesos son críticos, cuánto cuesta cada hora de detención y qué pasa si se pierden datos. Un ejemplo de cómo podría quedar una clasificación:
| Tipo de sistema | Ejemplo | RTO orientativo | RPO orientativo |
|---|---|---|---|
| Crítico | Ventas en línea, sistema de pagos | Horas | Minutos |
| Importante | ERP, correo | Un día | Horas |
| Secundario | Intranet, reportes históricos | Varios días | Un día |
Estos valores son solo ilustrativos. Cada empresa debe fijar los suyos, y mientras más exigentes son, más cuesta lograrlos. Ese equilibrio entre costo y riesgo es una decisión de negocio.
Estrategias de recuperación
Según el RTO y RPO que necesites, hay distintas formas de prepararte:
- Respaldo y restauración: copias periódicas que se restauran cuando hay un problema. Es la opción más económica, pero también la de recuperación más lenta.
- Sitio alterno en frío o tibio: infraestructura preparada en otro lugar, con parte de los sistemas listos, que se completa al activarse el plan.
- Réplica activa o en caliente: sistemas duplicados y sincronizados que pueden tomar el control en poco tiempo. Es la más rápida y la más costosa.
- Recuperación en la nube: usar un proveedor como AWS, Microsoft Azure o Google Cloud como sitio alterno, pagando principalmente por la capacidad que se usa cuando se activa el plan.
Una regla que vale en todos los casos: los respaldos deben estar fuera del alcance de un atacante. Un ransomware que llega a tus copias de seguridad convierte un mal día en una crisis. Lo explicamos en detalle en nuestra guía sobre ransomware.
Qué debe incluir un DRP
- Alcance y objetivos: qué sistemas cubre y con qué RTO y RPO.
- Inventario y dependencias: qué servidores, bases de datos, servicios en la nube y proveedores necesita cada sistema para funcionar.
- Roles y contactos: quién declara el desastre, quién ejecuta cada paso y cómo ubicar a proveedores clave, incluso fuera de horario.
- Criterios de activación: qué situaciones disparan el plan y quién lo autoriza.
- Procedimientos de recuperación: pasos concretos y en orden para restaurar cada sistema.
- Orden de prioridad: qué se levanta primero según su criticidad.
- Comunicación: cómo se informa a gerencia, trabajadores, clientes y, si corresponde, a la autoridad.
- Retorno a la normalidad: cómo volver al sitio principal sin perder datos.
- Pruebas y mantención: cada cuánto se prueba, quién lo revisa y cuándo se actualiza.
Cómo probar tu plan
Un DRP que nunca se ha probado es una hipótesis. Existen distintos niveles de prueba:
- Revisión de escritorio: el equipo lee el plan paso a paso y detecta vacíos.
- Simulacro guiado: se plantea un escenario, por ejemplo "se cifró el servidor de base de datos", y cada persona explica qué haría.
- Restauración parcial: se restaura un sistema real en un ambiente aislado y se mide cuánto tardó.
- Prueba completa: se activa el sitio alterno y se opera desde ahí por un tiempo definido.
Compara siempre el tiempo y los datos recuperados con tus RTO y RPO. Si no los cumples, ajusta el plan o la estrategia.
DRP, continuidad operacional e ISO 22301
Para quienes necesiten un marco formal, ISO 22301:2019 establece los requisitos de un sistema de gestión de la continuidad del negocio: cómo prepararse, responder y recuperarse de incidentes disruptivos. El DRP encaja dentro de ese sistema como la pieza tecnológica.
En Chile, además, la Ley Marco de Ciberseguridad exige a los operadores de importancia vital elaborar e implementar planes de continuidad operacional y ciberseguridad, certificarlos y revisarlos con una frecuencia mínima de dos años. Si tu empresa está en ese grupo, el DRP deja de ser una buena práctica y pasa a ser parte del cumplimiento. Más detalles en nuestra guía de la Ley 21.663.
Errores comunes
- Tener respaldos pero nunca haber restaurado uno completo.
- Guardar el plan solo en el servidor que se va a caer. Debe existir una copia accesible fuera de la infraestructura principal.
- Definir RTO y RPO sin consultar al negocio.
- Olvidar dependencias: el sistema se restaura, pero no funciona porque falta el servicio de identidad o la conexión a un proveedor.
- No actualizar el plan después de cambios importantes, como una migración a la nube.
Cómo te acompañamos en Vitis Origins
Un buen DRP combina decisiones de negocio con trabajo técnico: definir objetivos realistas, diseñar respaldos protegidos, preparar un sitio alterno en la nube y probarlo. En Vitis Origins te ayudamos a levantar el análisis de impacto, elegir la estrategia adecuada a tu presupuesto, implementar los respaldos y ejecutar pruebas de recuperación periódicas. Conoce el servicio de respaldo y recuperación ante desastres y conversemos sobre cuánto tiempo puede estar detenida tu operación.
Preguntas frecuentes
¿Qué es un DRP?
Es un plan de recuperación ante desastres: un documento que describe cómo recuperar los sistemas de información y los datos después de una falla grave, como un ransomware, la caída de un centro de datos o la pérdida de un proveedor. Define objetivos de tiempo y de datos, responsables, estrategias de recuperación y un calendario de pruebas.
¿Cuál es la diferencia entre RTO y RPO?
El RTO es el tiempo máximo que un sistema puede estar detenido antes de afectar seriamente al negocio. El RPO indica hasta qué punto en el tiempo debes poder recuperar los datos, es decir, cuánta información puedes perder. Por ejemplo, un RPO de una hora exige respaldos o réplicas al menos cada hora.
¿Cuál es la diferencia entre DRP y BCP?
El BCP, o plan de continuidad del negocio, abarca todos los procesos de la empresa: personas, oficinas, proveedores y comunicaciones. El DRP es la parte tecnológica de ese esfuerzo y se enfoca en recuperar sistemas y datos. Lo ideal es que ambos estén alineados y usen los mismos objetivos de recuperación.
¿Cada cuánto se debe probar un plan de recuperación ante desastres?
Depende de cuánto cambian tus sistemas y de lo crítico que sea tu servicio. Lo recomendable es probarlo de forma periódica y después de cambios importantes, como una migración. Si tu empresa es operador de importancia vital, la Ley 21.663 exige revisar los planes de continuidad al menos cada dos años.
¿Sirve la nube como sitio alterno de recuperación?
Sí. Proveedores como AWS, Microsoft Azure o Google Cloud permiten preparar un entorno de recuperación sin mantener un segundo centro de datos propio. Para que funcione, hay que diseñar la replicación de datos, documentar los pasos de activación y probar el proceso, porque la nube no recupera los sistemas por sí sola.
