Puede existir una copia de seguridad mientras la empresa aún no puede retomar el trabajo. Sus datos pueden ser demasiado antiguos. O la recuperación puede tardar más de lo que los empleados y los clientes pueden esperar. Para gestionar estos límites por separado, la empresa establece dos objetivos: RPO para la pérdida de datos y RTO para el tiempo de recuperación.
Estas medidas se aplican a un servicio o sistema empresarial específico. Defínelas a partir de las consecuencias de una interrupción, y luego compárelas con las capacidades de TI. Un estado de copia de seguridad exitoso o una promesa de un proveedor no confirman por sí solos que los objetivos pueden cumplirse.
Distinguir la pérdida de datos del tiempo de inactividad
¿Qué significa RPO?
El objetivo de recuperación (RPO), expresa la pérdida aceptable de datos recientes como un intervalo de tiempo. La pregunta para el responsable del proceso es: ¿qué cambios recientes podría perder o recrear la empresa a partir de otras fuentes sin consecuencias inaceptables?
El RPO no mide el tamaño de los archivos. El mismo intervalo podría representar unos pocos documentos modificados o muchas órdenes. Además del tiempo, registre qué información cambia, con qué frecuencia y si los registros faltantes pueden recrearse de forma fiable.
¿Qué significa RTO?
El objetivo de tiempo de recuperación (RTO) establece el tiempo objetivo para devolver un sistema o servicio a un estado operativo acordado después de una interrupción. Defina ese estado con antelación. Una máquina virtual en funcionamiento no significa necesariamente que un empleado pueda iniciar sesión, acceder a los datos y realizar la operación requerida.
AWS distingue estos objetivos de la siguiente manera: El RTO limita el retraso aceptable en la restauración de un servicio, mientras que el RPO define el intervalo aceptable de pérdida de datos antes de la interrupción. La organización establece ambos objetivos para sus propios procesos.
Un objetivo y un resultado medido tienen propósitos diferentes
|
Medir |
La pregunta que responde |
Qué verificar |
|---|---|---|
|
RPO |
¿Con qué frecuencia deben estar disponibles los datos preservados? |
El último punto de datos utilizable y consistente |
|
RTO |
¿Cuándo debe estar disponible el servicio para el trabajo acordado? |
Tiempo hasta la realización de pruebas y la aceptación |
|
Resultado real |
¿Qué se logró en una prueba o incidente específico? |
Marcas de tiempo, preservación de datos y acciones completadas |
No confunda el objetivo con el resultado
Establezca el objetivo antes de cualquier interrupción. Mida el tiempo real de recuperación después o durante una prueba. Si el equipo restaura el servicio más lentamente de lo que permite el objetivo, aborde la diferencia o consulte con el responsable del negocio para que tome una decisión. No reasigne retroactivamente la duración real como el nuevo tiempo de recuperación (RTO) y declare que la prueba fue exitosa.
Un tiempo medio de recuperación informado, a veces llamado MTTR, tampoco reemplaza el RTO. Un promedio describe un conjunto de observaciones. Puede ocultar interrupciones individuales prolongadas. Evaluar el objetivo requiere resultados de escenarios relevantes y razones para las desviaciones.
Defina límites de medición claros
Identifique el punto de datos y el tiempo de recuperación del servicio
Para evaluar la pérdida de datos, compare el tiempo de interrupción con el último punto desde el cual se restauró realmente el estado requerido. Utilice los datos y las transacciones en ese punto, no solo la hora de inicio del trabajo de copia de seguridad. Un trabajo fallido, un retraso en la replicación o una copia inconsistente pueden aumentar la diferencia real. Considere un ejemplo hipotético: la interrupción ocurre a las 12:00, el último punto de datos utilizable contiene datos a las 11:45 y la operación de trabajo se confirma a las 13:00. La diferencia de datos es de 15 minutos y el tiempo de inactividad es de una hora. Compare cada valor con su objetivo aprobado. Son intervalos diferentes, incluso cuando se miden en las mismas unidades.
Para evaluar el tiempo de inactividad, contabilice desde el evento de interrupción acordado hasta que se confirme la disponibilidad del servicio. Incluya la detección, la decisión de recuperación, el acceso y la preparación de recursos, la transferencia de datos, el inicio de las dependencias y la verificación de resultados. Registre cualquier tiempo excluido de forma explícita, o los equipos deberán comparar diferentes cantidades.
En caso de corrupción de datos oculta, el último punto utilizable puede ser anterior a la última copia de seguridad. Por lo tanto, la antigüedad de la última tarea no siempre refleja la pérdida real. Durante las pruebas, asegúrese de que la versión elegida contenga datos utilizables en lugar de un error guardado.
Defina el resultado mínimo de funcionamiento
Registre una acción específica que confirme la recuperación. Para el correo electrónico, podría ser iniciar sesión y enviar un mensaje. Para un servicio de archivos, importan las carpetas y permisos requeridos. Una base de datos empresarial necesita comprobaciones de datos y una operación de aplicación, no solo la disponibilidad del servidor. Acuerden si la funcionalidad limitada temporalmente es aceptable.
Restaurar los sistemas de IT no siempre restaura todo el proceso inmediatamente. Después del inicio, el equipo puede necesitar reconciliar registros, gestionar las solicitudes acumuladas y contactar con socios empresariales. Permita tiempo para estas acciones en el plan de continuidad más amplio. No sustituya el tiempo de inicio técnico por el tiempo de inactividad aceptable del proceso empresarial.
Acuerden los objetivos para cada sistema importante
Comiencen por las consecuencias para el negocio
El responsable del proceso explica qué se detendrá durante una falla, quién se verá afectado y cómo cambian las consecuencias con el tiempo. Un servicio de pago, un sistema de archivo interno y de preparación de documentos tendrán diferentes respuestas. La importancia depende de cuándo se utiliza la aplicación, las obligaciones y las posibles soluciones alternativas, no solo su nombre.
- ¿Qué operaciones no se pueden realizar sin este sistema?
- ¿Qué datos aparecerán o cambiarán entre los puntos de recuperación utilizables?
- ¿Se pueden recrear los cambios faltantes a partir de una fuente verificada, y cuánto tiempo requerirá eso?
- ¿Existe un proceso temporal acordado, y cuándo dejará de funcionar?
- ¿Qué obligaciones internas o externas afectan a la pérdida aceptable y al tiempo de recuperación?
No se deben asignar objetivos de una tabla de otra industria. El mismo sistema puede soportar diferentes tareas en diferentes empresas. Verifique los requisitos aplicables por separado. Una afirmación de que una ley específica establece el mismo RPO y RTO para todas las organizaciones de una industria no reemplaza este trabajo.
Completar la matriz de objetivos
Copiar el formulario y rellenar los corchetes con las decisiones de los propietarios. Incluir no solo las aplicaciones finales, sino también los servicios de autenticación, redes y formas de acceder a las copias de seguridad necesarios.
Matriz de objetivos sin plazos predefinidos
|
Sistema |
Resultado del trabajo |
Pérdida de datos aceptable |
Tiempo de inactividad aceptable |
Propietario de la decisión |
Verificación de viabilidad |
|---|---|---|---|---|---|
|
Correo electrónico corporativo |
[Inicio de sesión y operaciones de correo electrónico confirmadas] |
[Intervalo y correspondencia cubiertos] |
[Hora objetivo] |
[Responsable del proceso] |
[Punto de uso, prueba de inicio de sesión y intercambio de correo electrónico] |
|
Archivos de trabajo |
[Carpetas necesarias con permisos correctos] |
[Cambiar el intervalo y el método de conciliación] |
[Hora objetivo] |
[Propietario de los datos] |
[Versión del archivo, acceso y acción de trabajo] |
|
Aplicación principal |
[Operación acordada utilizando datos verificados] |
[Intervalo de transacción] |
[Hora objetivo] |
[Propietario de la aplicación] |
[Secuencia de dependencias y aceptación de operaciones] |
Mantener la fecha de aprobación, el escenario de fallo y los responsables de las pruebas técnicas. Si varias aplicaciones comparten una categoría, necesitan consecuencias y dependencias de inactividad compatibles. Las etiquetas como «nivel crítico» no definen por sí mismas los minutos aceptables.
Verificar las dependencias, los costos y los límites
Recuperar el servicio junto con su entorno
Una aplicación puede depender de un directorio de usuarios, DNS, la red, una base de datos, certificados, claves e integraciones externas. La pérdida de cualquier enlace necesario altera el resultado. Verificar el orden de inicio y el acceso del equipo a las herramientas de recuperación, especialmente si la autenticación corporativa normal no está disponible.
En la nube, también verificar la disponibilidad del entorno, los permisos, las cuotas, los recursos y los mecanismos de recuperación para la carga de trabajo seleccionada. Para SaaS, aclarar el alcance de los datos, las operaciones disponibles y los límites del servicio. La velocidad de exportación de la API, la disponibilidad de las claves y el ancho de banda de la conexión pueden alterar el resultado. La disponibilidad general de la plataforma no garantiza que los datos o las aplicaciones específicos se recuperen dentro del tiempo elegido.
Si el proceso depende de un proveedor, comparar sus compromisos y capacidades verificadas con su objetivo. Permitir tiempo para contactar al proveedor, obtener acceso y restaurar la integración. La promesa de un proveedor no cubre automáticamente toda la cadena de la empresa.
Alinear el requisito con una opción viable
Objetivos más estrictos pueden requerir recursos adicionales, una protección de datos más frecuente, un entorno de recuperación preparado y pruebas regulares. Comparar las opciones en función del resultado de trabajo requerido y el costo total de soporte. No elegir el tiempo más corto simplemente para que un informe parezca bueno.
Si una opción adecuada excede los recursos disponibles, informe a la dirección sobre la brecha. Puede modificar el alcance de la función recuperada, mejorar la tecnología, preparar un proceso temporal o acordar un nuevo objetivo. El propietario del negocio decide si acepta el riesgo. El departamento de TI no debe prometer silenciosamente un resultado inalcanzable.
Un RPO (Recovery Point Objective) de cero significa que no se perderán los cambios protegidos dentro del escenario acordado. Una etiqueta que diga «respaldo continuo» no lo confirma. Verifique la preservación de las transacciones confirmadas, el método de replicación, los retrasos en la comunicación y el comportamiento de conmutación. Una pérdida mínima de datos tampoco significa una recuperación de servicio instantánea: el RPO y el RTO siguen siendo objetivos separados.
Valide los objetivos a través de la recuperación y manténgalos actualizados.
Verifique más allá del horario de respaldo.
Un horario indica una intención, no una prueba. Para el RPO, verifique la antigüedad del punto de uso y la preservación de los cambios requeridos. Para el RTO, mida el tiempo necesario para que un usuario pueda realizar una acción de trabajo. Mantenga las condiciones de prueba: volumen de datos, recursos disponibles, escenario y dependencias. Sin ellas, no se puede comparar correctamente el siguiente resultado.
La documentación de AWS recomienda probar la implementación de la recuperación y mantener la configuración del entorno de recuperación actualizada. Los cambios en el volumen de datos, las cuotas o los recursos pueden invalidar las suposiciones anteriores.
La redundancia, la replicación y la automatización pueden ayudar, pero no demuestran de forma independiente que se puede alcanzar un objetivo. La replicación puede contener cambios erróneos. Recuperar datos de una copia protegida puede llevar tiempo. Evalúe una prueba automatizada exitosa por su cobertura, en lugar de considerarla como una prueba contra todas las posibles fallas.
Registre las desviaciones y revise la decisión.
Si se excede un objetivo, registre la causa, el responsable de la solución y la fecha límite para la re-prueba. Si una dependencia causó el retraso, no se debe centrar únicamente en acelerar la carga del respaldo. La solución debe acortar la etapa que realmente retrasó el resultado del trabajo.
Revise los objetivos y la evidencia después de cambios significativos: una nueva aplicación, crecimiento de datos, un cambio de proveedor, un cambio de proceso o un incidente. También establezca una fecha programada para revisar las condiciones de su empresa. La recomendación de otra organización de probar todo cada trimestre no crea un horario obligatorio para cada entorno.
Para completar la discusión, necesita una matriz aprobada, límites de medición claros, dependencias verificadas y un resultado de recuperación reciente. El RPO y el RTO se convierten entonces en criterios prácticos para seleccionar cambios y tomar decisiones, en lugar de ser simplemente dos acrónimos en un contrato.
¿Necesita comparar objetivos con su sistema de respaldo? Póngase en contacto con DKs Enterprises sobre respaldo y recuperación ante desastres. Prepare una lista de los servicios importantes, sus dependencias y los resultados de las pruebas recientes para discutir el trabajo necesario.
