Introducing G2.ai, the future of software buying.Try now

Objetivo de Punto de Recuperación: Un Elemento Crítico de la Recuperación de Datos

3 de Junio de 2022
por Keerthi Rangan

Un desastre de datos puede ocurrir en cualquier momento. ¿Crees que tu negocio puede sobrevivir perdiendo un día, una semana o incluso un mes de datos?

Cuando se trata de copias de seguridad de datos y recuperación ante desastres, determinar tu objetivo de punto de recuperación (RPO) es crítico. El RPO es la métrica que estableces para la cantidad de datos que tu negocio puede permitirse perder en un desastre de datos.

Tu RPO ayuda a decidir con qué frecuencia necesitas respaldar tus sistemas de datos y la infraestructura necesaria para sostener tu plan de respaldo. En la mayoría de los casos, una solución de recuperación ante desastres como servicio (DRaaS) de un proveedor de servicios gestionados puede ayudarte a cumplir con tus objetivos de punto de recuperación.

El RPO es una métrica empresarial crucial que toda organización debería rastrear. Cuando se combina con un objetivo de tiempo de recuperación (RTO), el RPO proporciona una lista priorizada de todos los sistemas, aplicaciones y datos a proteger.

La tolerancia a la pérdida de un negocio, o cuánto puede perder sin sufrir daños severos, está conectada al RPO y se describe en su estrategia de continuidad del negocio. Como el RPO se refiere al último período en que los datos de la empresa se conservaron en un estado viable, también especifica procesos para la planificación de recuperación ante desastres, incluido el intervalo de respaldo adecuado. Por ejemplo, los RPO con una duración de 60 minutos necesitan un respaldo continuo cada 60 minutos.

El RPO se combina típicamente con el objetivo de tiempo de recuperación (RTO), o el tiempo estimado que toma para que las actividades de una empresa reanuden operaciones regulares después de un desastre de datos. Estas mediciones apoyan el plan de recuperación ante desastres de la empresa, principalmente para mantenerse operativa durante y después de una crisis. Las soluciones de recuperación ante desastres que utilizan RTO y RPO a menudo garantizan que la información vital se copie, conserve y esté rápidamente accesible cuando se necesite.

RPO y RTO

Puedes definir diferentes RPO para diferentes partes de tu negocio. Por ejemplo, plataformas como servidores de correo electrónico, sistemas ERP, herramientas CRM y HRMS pueden tener varios valores de RPO y RTO.

Importancia del RPO

Una sola interrupción no planificada puede ser catastrófica para tu negocio. El riesgo de pérdida de datos tiene repercusiones significativas para las empresas. Dado que las operaciones comerciales son cruciales para la existencia de cualquier organización, muchas tienen estándares estrictos para mantener una seguridad óptima para los valiosos activos de datos.

Un objetivo de punto de recuperación es crucial porque puede impactar enormemente en cómo opera una organización y cuesta dinero. Por ejemplo, si estableces un RPO de 6 horas en todos tus sistemas y te enfrentas a un evento digital paralizante, lo más probable es que pierdas 6 horas de datos ya que el último punto más reciente desde el cual puedes recuperar datos almacenados es hace 6 horas.

El RPO establece:

  • La frecuencia mínima del programa de respaldo
  • Cuántos datos se pueden perder después de un desastre que cause un daño sustancial a la empresa
  • Hasta qué punto el equipo de TI debe implementar estrategias de recuperación sin retrasar la pérdida de datos contra el RTO esperado

¿Qué es el RPO Cero? El RPO Cero denota una pérdida de datos inaceptable. Los datos designados como RPO Cero son datos que tu organización no puede perder ni siquiera por un segundo sin graves repercusiones. Mantener un RPO Cero requiere protección y replicación de datos continuas para asegurar que los datos nunca se pierdan. Los datos médicos digitales en un hospital o las transacciones financieras en un banco son dos ejemplos de posibles datos de RPO Cero.

¿Quieres aprender más sobre Soluciones de Recuperación ante Desastres como Servicio (DRaaS)? Explora los productos de Recuperación de Desastres como Servicio (DRaaS).

Beneficios del RPO

La información electrónica y el software impulsan el desarrollo empresarial. Adoptar una estrategia de recuperación ante desastres protege a las empresas de la pérdida de datos y sus efectos dañinos. Los RPO y RTO son componentes críticos de un plan superior de protección de datos y recuperación ante desastres.

Adoptar y ejecutar RPOs apropiados beneficia la protección de datos y las estrategias de recuperación ante desastres y otros procesos empresariales de diversas maneras:

  • Restauración granular: Un RPO eficiente proporciona recuperación de datos granular. Restaurar una pieza específica de datos de un respaldo ahorra dinero y esfuerzo a las empresas sin añadir complejidad. La restauración granular permite a los usuarios localizar y recuperar rápidamente un archivo o documento particular. Este método de recuperación reduce la necesidad de restaurar un sistema o dispositivo de almacenamiento completo simplemente para recuperar un solo archivo.
  • Seguridad de datos y cumplimiento: Las empresas necesitan mantener el cumplimiento en todos los niveles, y los datos confiables son un componente crítico. Una estrategia de recuperación ante desastres con objetivos de punto de recuperación apropiados asegura respaldos adecuados sin riesgo de perder datos importantes. Las empresas pueden usar cifrado de datos y gestión de acceso con soluciones basadas en la nube. Solo protegiendo los datos actuales se puede asegurar el cumplimiento normativo.

    Las soluciones basadas en la nube dan a las empresas acceso a una amplia gama de capacidades para cumplir con regulaciones clave de privacidad de datos, incluyendo el Reglamento General de Protección de Datos (GDPR), Control de Organización de Servicio 2 (SOC2), y ISO 27001.
  • Operaciones rentables: Las empresas pueden proteger las inversiones existentes en TI con una política de respaldo efectiva que incorpore RPOs apropiados para respaldos seguros y regulares. Expandir la seguridad de datos a la nube ofrece beneficios adicionales ya que libera inversiones en tecnología local y convierte los costos de capital iniciales en gastos operativos asequibles.

¿Cómo funciona el objetivo de punto de recuperación?

Los RPO especifican la cantidad de tiempo que puede transcurrir antes de que la magnitud de la pérdida de datos exceda el límite permisible bajo un plan de continuidad del negocio (BCP). La tolerancia a la pérdida varía según el proceso empresarial y la carga de trabajo, influyendo en el RPO asociado para esa carga de trabajo.

Las aplicaciones de alta prioridad a menudo tienen RPOs más estrictos que requieren respaldos más frecuentes. En tales casos, el equipo de TI necesita preparar soluciones de respaldo para cumplir con ciertos RPOs, como una mezcla de instantáneas y replicación (también conocida como protección de datos casi continua (CDP)).

Cuando el RPO está cerca de cero, TI combina servicios de conmutación por error con replicación continua o un sistema de protección de datos continua para lograr casi un 100% de disponibilidad de aplicaciones y datos.

Establecer una frecuencia de respaldo de datos adecuada asegura un respaldo continuo dentro del límite de tolerancia a la pérdida. Los administradores de sistemas pueden definir automáticamente un RPO como una opción de política dentro del software de respaldo o almacenamiento y servicios en la nube.

Otras métricas clave:

  • Punto de Recuperación Real (RPA): El RPA indica el volumen real de datos que una empresa perdería durante un desastre y recuperación desde un respaldo local o fuera del sitio. Tu RPA debería ser menor que el RPO para cumplir con tu política de RPO.
  • Tiempo de Recuperación Real (RTA): El RTA denota el tiempo tomado para recuperar datos y hacer que la copia de almacenamiento esté disponible para el acceso de aplicaciones. Para una gobernanza de datos y cumplimiento efectivos, el RTA debe ser menor que el RTO definido en la estrategia de continuidad del negocio y recuperación ante desastres.

Cómo definir RPOs

Los RPOs a menudo se eligen dependiendo de la frecuencia de actualización de datos. Esto garantiza que, en caso de una interrupción del servicio, todas las operaciones reanudadas tengan la versión más reciente de los datos. Por ejemplo, los archivos que cambian regularmente requieren un RPO corto (no más de unos pocos minutos). Esto implica que las empresas pueden reanudar operaciones con una pérdida mínima de datos después de una interrupción.

Una vez establecidos, los RPOs deberían convertirse en los pilares de tu estrategia de continuidad del negocio, actuando como objetivos para las operaciones que definen. Tu programa debería delinear diferentes RPOs para diferentes unidades de negocio. Una actividad de datos crítica para la misión, como las transacciones financieras, requiere un RPO más corto que los archivos menos actualizados regularmente, como la información de los empleados.

Los siguientes son algunos niveles de muestra que deberías considerar al determinar los RPOs apropiados para tus unidades organizacionales:

  • 0 - 1 hora: Estos son servicios críticos para la misión que no pueden perder más de una hora de datos. Las transacciones comerciales y de datos son típicamente más grandes en volumen y más variables, lo que hace que la reconstrucción sea desafiante debido a la cantidad de variables involucradas. Esta categoría incluye transacciones financieras, sistemas CRM y registros de pacientes.
  • 1 - 4 horas: Esta categoría incluye unidades de negocio semi-críticas que pueden tolerar hasta cuatro horas de pérdida de datos. Ejemplos son los registros de chat de clientes y los servidores de archivos.
  • 4 - 12 horas: Este grupo de unidades de negocio no puede tolerar sacrificar más de 12 horas de datos. Ejemplos son los datos de marketing y ventas.
  • 13 -24 horas: Las unidades de negocio en este grupo gestionan datos semi-importantes y necesitan un RPO de no más de 24 horas. Esto puede incluir divisiones de personal y compras que actualizan datos con menos frecuencia que otras áreas de negocio.

Ejemplo de objetivo de punto de recuperación

Si bien el RTO y el RPO están vinculados de muchas maneras, los RPOs se relacionan específicamente con los datos retenidos. Hay un RPO para todo, ya sea una base de datos de clientes, transacciones financieras o una lista de cumpleaños del personal. Las empresas con planes efectivos de recuperación ante desastres (DR) incorporan RPOs en su enfoque y planificación.

Aquí hay un ejemplo de objetivos de punto de recuperación en acción.

Un gran sitio web de comercio electrónico global con varios servidores para diversas tareas desarrolla objetivos de punto de recuperación dependiendo del uso único de un servidor y los datos que mantiene. Como opera a nivel mundial y vende las 24 horas del día, partes clave de su sistema de gestión de datos requieren replicación continua en lugar de respaldos diarios o semanales. Los ejecutivos pueden resaltar los siguientes objetivos de punto de recuperación:

  • RPOs de un minuto: Sistemas y procesos como pasarelas de pago, niveles de stock de inventario, servidores de correo electrónico, registros de confirmación y bases de datos de envío tienen RPOs de un minuto en curso.
  • RPOs de una hora: Componentes como la interfaz del sitio web, información del cliente, paneles de productos y autenticación de contraseñas de usuarios pueden requerir RPOs de una hora.
  • RPOs de 24 horas: Las bases de datos de creación de contenido, los registros de conversaciones de clientes y las reseñas de clientes pueden tener RPOs más extendidos de 24 horas.

Si ocurre un incidente masivo de datos, la información crítica de la empresa de comercio electrónico, como evidencia de cosas vendidas, se revierte a la información más actualizada ya que se registra cada 60 segundos.

La información ligeramente menos crítica, como una reseña de producto de un cliente publicada poco antes de la pérdida de datos, no estaría en el sitio después de la restauración. Sin embargo, las de días anteriores permanecerán porque TI estableció el RPO en 24 horas.

Objetivo de tiempo de recuperación vs. objetivo de punto de recuperación

El objetivo de punto de recuperación está estrechamente vinculado al objetivo de tiempo de recuperación. Es la cantidad máxima de tiempo que los recursos informáticos y aplicaciones empresariales pueden permanecer inoperativos después de un mal funcionamiento o desastre. Estas métricas pueden ayudar a guiar la selección de estrategias de respaldo de datos adecuadas. También proporcionan una base para descubrir y evaluar soluciones viables que permitirán a una empresa reanudar las operaciones comerciales dentro de un plazo cercano al RPO y RTO.

RTO vs. RPO

Las dos técnicas permiten la planificación de continuidad del negocio (BCP) y un plan de DR. Aunque están interrelacionadas, entender la diferencia entre RTO y RPO ayuda a la línea de fondo de una empresa.

Objetivo de punto de recuperación

RPO gobierna la tolerancia a la pérdida y la cantidad de datos que una empresa puede permitirse perder. Es un objetivo de planificación que especifica con qué frecuencia los equipos de TI deben respaldar los datos para permitir la recuperación.

Una empresa apoya los RPOs implementando una estrategia de DR que respalda los datos en intervalos apropiados, asegurando que la pérdida de datos nunca exceda la tolerancia a la pérdida predefinida de la empresa.

Objetivo de tiempo de recuperación

RTO entra en la ecuación después de un "evento de pérdida". Ayuda a una empresa a evaluar cuán pronto puede recuperarse de una pérdida de datos debido a un mal funcionamiento, desastre natural o mala conducta. El RTO explica además, "¿Cuánto tiempo debería tomar restaurar las operaciones normales después de una interrupción del proceso empresarial?". El RPO y el RTO trabajan juntos, con el RPO asegurando que una empresa tenga los procedimientos de respaldo de datos adecuados y el RTO garantizando que los respaldos se recuperen rápidamente.

Los RPOs y RTOs varían según la aplicación y la importancia de los datos. El RPO y RTO cercanos a cero son increíblemente costosos ya que la única forma de evitar la pérdida de datos cero y el tiempo de actividad del 100% es la replicación continua de datos en entornos de conmutación por error virtual.

Debido al costo de alcanzar un RPO cercano a cero y seleccionar los datos y sistemas correctos, el costo de lograr un RPO y RTO adecuados depende del propósito, el riesgo y los gastos. El RTO se centra en sistemas y aplicaciones, lo que significa que principalmente calcula restricciones de tiempo en el tiempo de inactividad del servicio en lugar de la recuperación de datos.

Esta es otra forma de entender el debate RTO vs. RPO: el RPO se refiere a cuántos datos pierde una empresa después de una falla. El RTO aborda la mala experiencia del usuario y los consumidores descontentos, mientras que el RPO aborda situaciones catastróficas como perder cientos de miles de dólares en transacciones de clientes.


Factores que influyen en el RPO

Hay varios factores a considerar al desarrollar una estrategia de RPO, incluyendo:

  • Industria: Las empresas que manejan datos que evolucionan rápidamente o son sensibles (por ejemplo, datos de salud o transacciones bancarias) actualizan sus bases de datos más regularmente que las empresas que trabajan con archivos estáticos.
  • Almacenamiento de datos: Dónde residen tus datos (por ejemplo, en dispositivos físicos, la nube, etc.) influye en qué tan rápido puedes restaurarlos durante una falla del servicio.
  • Desafíos de cumplimiento: Muchos sistemas de cumplimiento incluyen secciones relacionadas con la recuperación ante desastres y la disponibilidad de datos. Por ejemplo, la acreditación SOC 2 exige un grado particular de accesibilidad de datos e integridad de procesamiento, afectando la cantidad permisible de datos perdidos durante una falla del servicio.

Cómo calcular el RPO

Cómo deseas que funcione la recuperación dicta la frecuencia con la que respaldas datos, aplicaciones y sistemas clave. Hay dos objetivos clave de recuperación ante desastres al planificar una estrategia de DR: RTO y RPO. Considera los siguientes cinco pasos al calcular los objetivos de punto de recuperación para tu empresa o industria.

1. Revisa con qué frecuencia se actualizan los archivos

Puedes controlar la periodicidad de la actualización de archivos estableciendo un objetivo de RPO. Esto hace que tus datos más recientes sean accesibles. Por ejemplo, tienes copias digitales y operaciones que se actualizan cada 30 minutos. Establecer un RPO cada 30-40 minutos asegura que accedas consistentemente a los datos más actualizados con poca pérdida de información.

En contraste, si tu empresa definió un RPO para un respaldo semanal guardado cada sábado por la noche, una falla técnica que ocurra el sábado por la tarde resultaría en la pérdida de una semana completa de datos ya que el respaldo del sistema aún no se había realizado ese día. Puedes modificar tu RPO, así que intenta evaluar regularmente tus períodos de actualización de archivos para ver si el RPO necesita cambiar.

2. Examina tus objetivos de BCP

Los objetivos de punto de recuperación complementan tus objetivos de plan de continuidad del negocio. Así que evalúa cuidadosamente cada aspecto para definir RPOs con diferentes asignaciones de tiempo para cada segmento de negocio, dependiendo de los datos que contienen y cuán cruciales son si ocurre una pérdida de datos.

Por ejemplo, las transacciones financieras y las operaciones de datos necesarias de un banco nacional son críticas y necesitan tiempos de RPO significativamente más cortos que los documentos de recursos humanos con registros de personal que se actualizan con menos regularidad y pueden soportar un tiempo de RPO más largo.

3. Considera las normas de la industria

Si bien los requisitos de RPO de cada empresa podrían ser únicos, puedes usar los estándares de la industria para guiarte al establecer RPOs para las unidades organizacionales en tu negocio. La mayoría de las transacciones comerciales encajan dentro de los parámetros generales de tiempo de RPO de la industria. Sin embargo, dependiendo del tamaño de tu empresa o su objetivo, puedes emplear configuraciones de datos semanales.

Por ejemplo, una aerolínea global con empleados repartidos en cientos de ubicaciones probablemente actualizará sus registros de recursos humanos con frecuencia. En contraste, un proveedor de seguros de oficina única con 30 empleados puede optar por actualizar los archivos de personal una vez a la semana porque son menos propensos a cambiar que los registros de recursos humanos de la aerolínea.

4. Desarrolla y autoriza cada RPO

Desarrolla RPOs después de examinar todos los riesgos para cada aspecto de tu gestión de datos y haz que sean aceptados por los ejecutivos para la implementación de TI o socios. Documenta el proceso a fondo y mantén registros para referirte y usar como referencia para revisar o ajustar un RPO.

5. Evalúa regularmente tus parámetros de RPO

Tus objetivos de punto de recuperación pueden evolucionar a medida que tu empresa se desarrolla o cambian tus estrategias de continuidad del negocio. Considera introducir un análisis sistemático y frecuente y evaluar qué tan bien funcionan tus configuraciones actuales de RPO y si necesitan ser ajustadas.

Aunque viene al final, este es un paso vital. Si tienes un evento de pérdida de datos o una falla del sistema, una evaluación ad hoc y un examen en profundidad de cómo funcionaron tu RPO y RTO pueden proporcionar información valiosa sobre todo tu sistema de gestión de datos.

Conmutación por error y RPO

Conmutación por error es el cambio entre tus sistemas primarios y de respaldo durante una interrupción o tiempo de inactividad programado del sistema. Es esencial considerar los RPOs de tu empresa al seleccionar una solución de conmutación por error para evitar perder datos excesivos mientras se mueve a un servidor de respaldo. Por ejemplo, un RPO de 10 minutos indica que tu solución de conmutación por error debe responder dentro de ese plazo para asegurar que no pierdas más de 10 minutos de datos.

Los métodos de conmutación por error pueden incluir:

  • Un sistema de nombres de dominio (DNS) dirige el tráfico desde una solución de hardware a un centro de datos fuera del sitio. Los servidores DNS son esenciales para la recuperación entre centros de datos de fallas de centros de datos. Sin embargo, este enfoque tiene varios posibles inconvenientes, incluyendo retrasos relacionados con el Tiempo de Vida (TTL) y pérdida de servicio, lo que puede aumentar el tiempo de recuperación de datos. Además, el método de enrutamiento puede causar una conmutación por error desigual ya que los proveedores de servicios de internet (ISPs) pueden continuar enviando tráfico al servidor incorrecto hasta que su caché DNS se restaure.
  • Dispositivos físicos que se mantienen en el sitio como soluciones de hardware. Si un dispositivo falla, el tráfico se desvía a un servidor de respaldo. Este enfoque elimina las preocupaciones de latencia vinculadas con la conmutación por error de DNS. Sin embargo, requiere alojar tu sitio de respaldo en la misma ubicación física que tu servidor principal. Esto a menudo es una mala técnica ya que expone la ubicación de respaldo a muchos riesgos que afectarán a tu clúster de servidores principal (por ejemplo, falla de la red eléctrica local o desastres naturales).
  • Servicios en el borde que combinan las ventajas de las soluciones basadas en DNS y hardware. El mantenimiento de dispositivos físicos no implica retrasos de TTL ni gastos adicionales. Esto asegura poca pérdida de datos, permitiendo a las empresas cumplir con sus objetivos de RPO.

¿Cuántos datos puedes permitirte perder?

Planificar la recuperación ante desastres puede ser difícil y llevar mucho tiempo. Si no tienes las herramientas o la experiencia adecuadas, es fácil pasar por alto cosas. Pero con un buen equipo de TI y capacitación regular en su lugar, puedes evitar algunos de los errores que podrían costar caro a tu empresa en ingresos perdidos.

Lleva tu recuperación ante desastres al siguiente nivel con DRaaS.

Keerthi Rangan
KR

Keerthi Rangan

Keerthi Rangan is a Senior SEO Specialist with a sharp focus on the IT management software market. Formerly a Content Marketing Specialist at G2, Keerthi crafts content that not only simplifies complex IT concepts but also guides organizations toward transformative software solutions. With a background in Python development, she brings a unique blend of technical expertise and strategic insight to her work. Her interests span network automation, blockchain, infrastructure as code (IaC), SaaS, and beyond—always exploring how technology reshapes businesses and how people work. Keerthi’s approach is thoughtful and driven by a quiet curiosity, always seeking the deeper connections between technology, strategy, and growth.