De todos los planes de continuidad, el de recuperación ante desastres es el que más se nombra y el que menos se entiende. Casi cualquier empresa dirá que tiene uno; muy pocas tienen lo que el nombre promete. La confusión de raíz es tratarlo como "la parte técnica del respaldo", cuando en realidad es una disciplina completa —mitad ingeniería, mitad proceso— que arranca mucho antes de comprar tecnología y no termina nunca, porque se mantiene viva. Esta es la guía de sus piezas, en el orden en que se construyen, con el detalle de cada una a un clic.
Los respaldos son un ingrediente, no el plato. Lo que convierte una caja de herramientas en un plan es todo lo que rodea al respaldo: saber qué recuperar primero, a dónde, en cuánto tiempo, con qué procedimiento, y haberlo ensayado antes de necesitarlo. Vamos fase por fase.
1. Entender qué proteger: el BIA
Todo empieza por una pregunta que no es técnica: ¿qué le pasa al negocio, con el tiempo, cuando cada proceso se detiene? Eso es el Análisis de Impacto al Negocio (BIA), y es el cimiento de todo lo demás. Sin él, cada área jura que lo suyo va primero y gana quien grita más fuerte. El BIA convierte esa discusión en una lista de prioridades con números detrás —empezando por cuánto cuesta de verdad una hora sin sistemas— y en un mapa de dependencias que dice en qué orden se recupera. Si te saltas esta fase, todo lo que viene después se dimensiona a ciegas.
2. Fijar los objetivos: las métricas
Del BIA salen los números que gobiernan el plan. Los dos famosos son el RPO y el RTO —cuántos datos puedes perder y cuánto puedes esperar—, pero el mapa completo incluye el MTD y el WRT: el máximo tiempo tolerable de caída y el tramo, casi siempre olvidado, entre "el sistema ya está arriba" y "el negocio ya opera". Estos números no se copian de nadie ni se eligen por lo que suena bien: se derivan del impacto real, y son los que después justifican cada peso que se gasta en recuperación.
3. Decidir a dónde recuperar: el DR site
Con los objetivos claros aparece la pregunta física: si el sitio primario deja de existir, ¿a dónde levantas la operación? Esa es la decisión del DR site, que viene en tres temperaturas —hot, warm y cold— según qué tan rápido necesitas recuperar y cuánto puedes pagar por tenerlo esperando. Aquí también se decide la separación geográfica (que el mismo desastre no tumbe ambos sitios) y la forma: datacenter propio, colocation o nube. Un sitio de recuperación en la nube que solo se enciende cuando lo necesitas es, en esencia, lo que ofrece el DRaaS; en la nube pública, la misma decisión se traduce en elegir entre zonas y regiones.
4. Proteger los datos: el respaldo bien hecho
Ahora sí, la pieza que todos creían que era todo el plan —y que sin las anteriores no sabía a qué apuntar. Un respaldo que sirve para recuperación cumple varias cosas: sigue una estrategia como 3-2-1-1-0, tiene una copia inmutable que el ransomware no puede cifrar, y —esto es lo que casi nadie hace— se prueba restaurando, porque un backup sin restauración probada no es un backup. Conviene además no confundir los snapshots con respaldos: son cosas distintas con propósitos distintos. Y todo esto se apoya en algo aún más básico: que haya energía para operar y para apagar ordenadamente.
5. Escribir cómo: el documento y los runbooks
Un plan que solo vive en la cabeza de una persona no es un plan. El documento del DRP reúne el inventario, los objetivos, los contactos y el mapa de dependencias; y para el día del desastre se baja a runbooks: el paso a paso ejecutable a las tres de la mañana por quien esté de guardia, aunque no lo haya escrito. Ahí también vive el failback —cómo volver al sitio primario sin perder lo que el negocio generó durante la contingencia—, el movimiento que casi todos olvidan planear.
6. Ubicarlo en el mapa: DRP, BCP e incidentes
El DRP no vive solo. Es una pieza de algo más grande, y confundirlo con sus vecinos deja huecos. El DRP recupera la tecnología, el BCP mantiene al negocio operando y la respuesta a incidentes contiene el ataque. En un ransomware los tres se usan a la vez: uno contiene, otro recupera los sistemas, el tercero sostiene la operación mientras tanto. Tener solo el DRP y creer que tienes los tres es el hueco que se descubre en pleno incidente.
7. Probarlo y mantenerlo vivo
Y llegamos a la fase que convierte todo lo anterior en algo real o lo deja en teoría: un DRP que nunca se probó no es un plan, es una hipótesis. Se ensaya por niveles —del repaso en papel al tabletop, de la simulación a la interrupción real— y cada prueba encuentra los huecos mientras cuestan poco: procedimientos obsoletos, respaldos que no restauran, decisiones sin dueño. Y como la infraestructura cambia, el plan se revisa tras cada cambio importante y al menos una vez al año. Un DRP es un proceso, no un entregable con fecha de cierre.
La pregunta que lo resume todo
Si tuvieras que responder una sola cosa, que sea esta: si mañana el peor escenario se vuelve real, ¿el equipo sabría qué recuperar primero, a dónde, en cuánto tiempo y con qué procedimiento —y lo han practicado— o solo tienen respaldos y buenas intenciones? La distancia entre esas dos respuestas es exactamente este plan. Ayudar a recorrerla —levantar el BIA, dimensionar los objetivos, diseñar el sitio de recuperación, respaldar con DRaaS real, escribir los runbooks y probarlos con simulacros— es, entera, la disciplina que ofrecemos. Porque el día que arde, un plan vivo es la diferencia entre una mala tarde y una mala noticia.