RPO y RTO: decide qué recuperar primero antes de una caída

Cuando se pregunta cuánto puede estar parado un sistema, la primera respuesta suele ser que nada. Sin embargo, recuperar todos los servicios de forma inmediata exigiría recursos que pocas organizaciones pueden justificar. La conversación útil consiste en identificar qué consecuencias aparecen con el paso de las horas, cuánta información se puede reconstruir y qué actividades deben volver primero. RPO y RTO permiten expresar esas decisiones de manera que negocio y tecnología puedan trabajar sobre ellas.

Distingue pérdida de información y tiempo de interrupción

El objetivo de punto de recuperación, RPO, indica la pérdida de datos tolerable expresada como un intervalo temporal. Si se acepta un RPO de cuatro horas, el diseño debe permitir volver a un estado que no exceda esa pérdida en el escenario previsto. El objetivo de tiempo de recuperación, RTO, expresa cuánto se pretende tardar en restablecer el servicio. Son objetivos de diseño y operación; no garantías automáticas derivadas de contratar una herramienta.

Imagina un proceso que recibe solicitudes continuamente. Recuperar el servidor en treinta minutos puede cumplir un RTO corto y, aun así, perder toda la jornada si la última copia válida es de la noche anterior. En el caso inverso, la información puede estar casi al día y permanecer inaccesible durante horas. Medir las dos dimensiones evita dar por buena una solución que solo responde a la mitad del problema.

Describe el impacto con quienes realizan el trabajo

Reúne a responsables de cada actividad y pregunta qué sucede tras una hora, una mañana y un día de interrupción. Considera compromisos de entrega, trabajo acumulado, personal bloqueado y alternativas manuales. No hace falta asignar cifras precisas donde no existen, pero sí distinguir consecuencias verificables de impresiones. Anota también si hay épocas especiales: un servicio tolerable en una semana normal puede resultar crítico durante un cierre o una campaña.

Dibuja las dependencias que condicionan el orden

El servicio prioritario puede necesitar identidad, red, resolución de nombres, almacenamiento y una base de datos compartida. Recuperarlo antes que esas piezas no acelera el retorno. Construye un mapa sencillo que muestre qué debe estar disponible para que cada actividad funcione. Incluye proveedores externos y personas con acceso imprescindible. Una dependencia administrada por un tercero sigue siendo parte del recorrido de recuperación, aunque no controles su infraestructura.

• Define el servicio en términos de la actividad que debe poder realizarse.
• Acuerda el máximo de información que sería viable reconstruir y quién lo haría.
• Identifica dependencias técnicas, contactos externos y permisos necesarios.
• Determina una forma provisional de trabajar mientras se recupera el funcionamiento completo.

Contrasta los objetivos con el diseño disponible

La frecuencia de copias, el ancho de banda, la capacidad de destino y los tiempos de aprovisionamiento condicionan el resultado. La replicación puede mejorar disponibilidad, pero también trasladar una corrupción o un borrado; no sustituye por sí sola al historial de copias. Examina además la capacidad de recuperar si falla la ubicación principal o las credenciales habituales. Las soluciones deben evaluarse para escenarios concretos y con sus limitaciones explícitas.

Si el coste de cumplir un objetivo resulta excesivo, vuelve a la conversación de impacto. Tal vez una función reducida permita operar temporalmente, o una exportación controlada resuelva consultas urgentes. La alternativa debe ensayarse y tener instrucciones claras. Rebajar un objetivo sin informar al responsable del servicio crea una expectativa falsa; acordar un modo degradado documentado permite tomar una decisión consciente sobre coste, complejidad y continuidad.

Prueba el recorrido completo y registra desviaciones

Los ejercicios deben incluir detección, decisión, acceso a copias, restauración y aceptación funcional. Una medición que solo cuenta la copia de archivos deja fuera gran parte de la interrupción. Compara los tiempos observados y la antigüedad de los datos con los objetivos aprobados. La guía de contingencia NIST SP 800-34 proporciona una referencia para estructurar este trabajo; cada organización debe adaptarlo a su tamaño y a sus servicios.

Mantén las prioridades vivas

Revisa el plan cuando cambie una aplicación, se incorpore un proveedor o crezca el volumen de información. Guarda una versión accesible durante una caída y comprueba que los contactos siguen vigentes. El resultado no debería ser una clasificación olvidada, sino una secuencia que permita decidir con rapidez. Saber qué se recupera primero, por qué y con qué límites ayuda a concentrar recursos y comunicar expectativas realistas durante una interrupción.