ES 
PT 
EN 
Un DRP, o Disaster Recovery Plan, es el plan que define cómo la operación vuelve a funcionar después de una parada grave: qué se levanta primero, en cuánto tiempo, con cuánta pérdida de datos aceptable, quién lo ejecuta y cómo se confirma que el entorno está en pie otra vez. Sin ese plan, la recuperación depende de quien esté disponible y de lo que esa persona recuerde en el momento de la crisis.
Casi toda empresa mediana y grande tiene backup. Aun así, pocas pueden decir, con un número, en cuánto tiempo vuelven a operar después de un incidente serio. Esa distancia entre tener copia de los datos y lograr retomar la operación es exactamente lo que resuelve un DRP.
Si su duda todavía está en la capa anterior, la de las copias y la retención, el artículo sobre las ventajas del backup en la nube trata la regla 3-2-1 y lo que diferencia backup de recuperación.
Por qué la recuperación demora más de lo que la empresa imagina
El escenario se repite. El incidente ocurre, el backup está íntegro, y aun así la operación tarda días en volver. No por falta de datos, sino por falta de secuencia.
El equipo empieza a restaurar por el sistema que alguien recordó primero, descubre a mitad de camino que depende de un servicio de autenticación que todavía no se levantó, retrocede, levanta el servicio de autenticación, y entonces advierte que falta un certificado que estaba guardado en el entorno que se cayó. Cada uno de esos descubrimientos cuesta horas, y mapear las dependencias antes revelaría todas ellas.
Es la misma lógica de una mudanza de oficina. En la práctica, tener todas las cajas es distinto de saber cuál abrir primero para que la empresa vuelva a trabajar mañana por la mañana. El DRP es el orden de las cajas.
RTO y RPO, los dos números que define el negocio
Todo plan se apoya en dos números, y no son una decisión de TI.
oh RTO, Recovery Time Objective, es el tiempo máximo aceptable entre la parada y el retorno del servicio. La pregunta que responde es: cuánto tiempo aguanta la empresa sin ese sistema.
oh RPO, Recovery Point Objective, es la pérdida máxima de datos aceptable, medida en tiempo. La pregunta es: si perdemos las últimas transacciones, cuántas horas de trabajo se rehacen a mano.
Quien responde es el negocio. TI dimensiona la arquitectura que atiende esas respuestas, y el costo acompaña de cerca esa elección.
En la primera conversación, es común que todos los sistemas se clasifiquen como críticos, con un RTO de una hora para todo. La priorización real aparece cuando el costo de la arquitectura correspondiente entra en la mesa. Ahí el ERP que sostiene la facturación sigue con un RTO de horas, y el sistema interno de tickets acepta volver al día siguiente sin que nadie pierda dinero por ello.
Qué incluye un DRP
Hecho el relevamiento, el plan se organiza básicamente en cuatro frentes:
- Clasificación y dependencias. La lista de sistemas con criticidad definida por el negocio, y el mapa de lo que cada uno necesita para funcionar. Es la parte más barata del trabajo y la que más reduce el tiempo de retorno.
- Estrategia por carga de trabajo. La decisión de cómo se recupera cada sistema. No todo sistema justifica la misma inversión.
- Procedimiento ejecutable. El paso a paso real, con orden de levantamiento, comandos, credenciales accesibles fuera del entorno caído y un criterio objetivo para decir que el sistema volvió. Un documento genérico no recupera un entorno.
- Roles y comunicación. Quién declara el desastre, quién ejecuta, quién habla con los clientes y quién autoriza el retorno a la operación normal, con contactos alternativos, porque la crisis puede alcanzar el propio correo de la empresa.
Cómo elegir la estrategia de recuperación
Cuatro modelos cubren la mayoría de los casos, y la diferencia entre ellos es siempre el mismo intercambio: cuanto más rápido el retorno, mayor el costo de mantener la estructura en espera.
En el backup y restauración, hay copias de los datos y el entorno se levanta de nuevo cuando es necesario. Es el más barato y el más lento, con retorno en horas o días.
En el pilot light, lo esencial queda activo en escala mínima, normalmente la base de datos replicada, y el resto se levanta al activarse. Retorno en horas.
En el warm standby, una copia reducida del entorno funciona todo el tiempo y asume la operación con escala ampliada. Retorno en minutos.
En el activo-activo, dos entornos operan en paralelo y el tráfico se redirecciona. Retorno casi inmediato, y el modelo más caro.
La elección se hace por sistema, no para toda la empresa. El diseño más común combina los extremos: activo-activo en lo que sostiene los ingresos, backup y restauración en lo que puede esperar.
La nube cambió esa cuenta para mejor. Mantener un segundo entorno dejó de exigir un data center ocioso, porque la nube provisiona los recursos cuando son necesarios y la replicación entre regiones resuelve buena parte del diseño. Lo que no cambió es la necesidad del plan: replicación sin procedimiento, sin RTO acordado y sin prueba es infraestructura, no continuidad.
Por qué el plan falla en el momento crítico
Incluso con un buen diseño inicial, los planes fallan por motivos conocidos.
El primero es el plan escrito para la auditoría. Atiende al cuestionario, queda bien en el informe y no sirve en la madrugada del incidente, porque no tiene el detalle de ejecución.
El segundo es la documentación guardada dentro del entorno que debería ser recuperado. Cuando el entorno se cae, el plan se cae con él.
El tercero es el acceso concentrado en una sola persona. Si la recuperación depende de quien está de vacaciones o fuera de alcance, el RTO acordado se vuelve una estimación optimista.
Y el cuarto es el plan desactualizado. El entorno cambia todos los meses, el plan se escribió una vez, y la recuperación se intenta con un mapa antiguo.
La prueba, que es la parte que casi nadie hace
Un plan que nunca fue ejecutado es una hipótesis. La prueba es lo que transforma el RTO de intención en número medido, y tiene tres niveles.
A simulación de mesa recorre el plan verbalmente frente a un escenario, sin interrumpir nada. Parece poco, y es donde aparecen los vacíos de responsabilidad y los contactos equivocados.
oh prueba parcial recupera un sistema en el entorno alternativo, en una ventana programada. Valida el procedimiento y mide el tiempo real.
oh failover completo transfiere la operación al entorno secundario. Es el único que comprueba el RTO en la práctica, y el que exige más preparación.
La cadencia que funciona es una revisión anual del plan y una prueba parcial semestral en los sistemas críticos, con un registro que anote el tiempo medido, y no el tiempo estimado. La diferencia entre esos dos números suele ser la información más útil del ejercicio.
Cómo conduce Integrity-UX este trabajo
Comenzamos por la clasificación de los sistemas junto a las áreas de negocio, porque RTO y RPO son decisiones del negocio, y mapeamos las dependencias entre las aplicaciones, que es donde se pierde tiempo en la recuperación. A partir de ahí, definimos la estrategia de cada carga de trabajo, escribimos el procedimiento en formato ejecutable y asignamos los roles.
Después vienen las pruebas, con registro del tiempo real de retorno, y la revisión periódica que mantiene el plan alineado a un entorno que no deja de cambiar.
Conozca el servicio de DRP de Integrity-UX o hable con un especialista.
Próximos pasos
Si su empresa tiene backup pero no sabe decir en cuánto tiempo vuelve a operar, el primer paso no es comprar tecnología. Es responder, junto al negocio, cuánto tiempo puede estar detenido cada sistema y cuánta información puede perderse. Esos dos números definen todo lo demás, incluida la inversión.
Preguntas frecuentes
¿Qué es un DRP?
El DRP, o Disaster Recovery Plan, es el plan de recuperación ante desastres: el documento que define cómo la operación de TI vuelve a funcionar después de una parada grave, con prioridades, plazos, procedimientos y responsables.
¿Cuál es la diferencia entre DRP y backup?
El backup es la copia de los datos. El DRP es el plan que pone la operación nuevamente en línea, con orden de recuperación, entorno alternativo, responsables y criterio de validación. El backup es un insumo del plan, no el plan.
¿Qué son RTO y RPO?
El RTO es el tiempo máximo aceptable hasta que el servicio vuelva. El RPO es la pérdida máxima de datos aceptable, medida en tiempo. Ambos los define el negocio y determinan el costo de la solución.
¿Con qué frecuencia debe probarse el DRP?
Revisión del plan al menos una vez por año y prueba parcial semestral en los sistemas críticos. Todo cambio relevante de arquitectura pide una nueva validación.
¿Es obligatorio el DRP?
No existe una ley brasileña que exija un plan con ese nombre. La LGPD obliga a adoptar medidas de seguridad que preserven la disponibilidad de los datos, y la norma ISO 22301 trata de la continuidad de negocio. Los sectores regulados, como el financiero, tienen exigencias propias.
¿Cuánto tiempo lleva elaborar un DRP?
Depende del número de sistemas y de la madurez del entorno. Lo que define el plazo es el relevamiento de dependencias y la definición de RTO y RPO con las áreas de negocio, no la parte técnica.
Este contenido fue producido por el equipo de Integrity-UX, consultoría de TI especializada en infraestructura, continuidad y nube para medianas y grandes empresas.
Fuente: ABNT NBR ISO 22301, sistemas de gestión de continuidad de negocio.
