Diseño de objetivos de copia de seguridad y recuperación en la nube

Diferenciar la copia de seguridad de la recuperación ante desastres

La copia de seguridad y la recuperación ante desastres están relacionadas, pero son disciplinas distintas, y confundirlas genera lagunas en la protección. La copia de seguridad consiste en conservar copias separadas de los datos para poder restaurar archivos, registros o sistemas concretos tras un borrado, una corrupción o un error. La recuperación ante desastres es una capacidad más amplia que permite reanudar las operaciones tras un suceso grave, lo que puede implicar reconstruir la infraestructura, redirigir a los usuarios y restaurar los servicios en un orden definido.

En un entorno de nube ambas se solapan, pero no coinciden. Una copia replicada de una base de datos puede servir bien para la recuperación ante desastres y, aun así, replicar un borrado erróneo, por lo que no puede sustituir a una copia de seguridad independiente. A la inversa, un archivo de copia de seguridad puede contener todos los ficheros, pero no ofrecer una vía práctica para volver a poner una aplicación en marcha con rapidez. Tratarlas como requisitos separados, cada uno con su responsable y sus pruebas, mantiene el diseño realista.

Conviene plantearse pronto dos preguntas: qué debe poder recuperarse tras un error lógico y qué debe poder recuperarse tras la pérdida de una región o una cuenta completa. Las respuestas difieren y suelen exigir copias distintas, ubicaciones distintas y controles de acceso diferentes. Documentar ambas evita la suposición habitual de que un único mecanismo lo cubre todo.

Definir los objetivos de punto de recuperación

El objetivo de punto de recuperación, habitualmente abreviado RPO, describe la cantidad máxima de datos que una organización puede permitirse perder, medida en tiempo transcurrido. Si el RPO de un sistema es de cuatro horas, las copias o réplicas deben realizarse con la frecuencia suficiente para que la copia utilizable más reciente nunca tenga más de cuatro horas en el momento del fallo. El objetivo expresa una tolerancia, no una descripción de la tecnología existente.

Definir un RPO requiere la aportación de las personas que comprenden el valor de los datos. Los registros transaccionales, los pedidos de clientes y los registros de auditoría suelen justificar intervalos cortos, mientras que los documentos de referencia o los informes archivados pueden tolerar capturas diarias o semanales. Cada sistema debe evaluarse por separado, porque un intervalo único y general gasta de más en datos de poco valor o deja expuestos los datos críticos.

Una vez acordado el RPO, este condiciona el método de copia. Las capturas frecuentes en un momento concreto pueden requerir protección incremental o continua de datos en lugar de copias completas, y aumentan tanto el consumo de almacenamiento como la carga sobre los sistemas de origen. Por ello, el RPO debe revisarse junto con el coste, ya que un objetivo más exigente solo merece la pena cuando el impacto empresarial de la pérdida de datos justifica el gasto adicional.

• Determinar la pérdida de datos que el negocio puede aceptar para cada sistema, expresada en horas o minutos.
• Asignar los RPO según la criticidad de los datos, en lugar de aplicar un mismo intervalo a todo.
• Confirmar que el método de captura elegido puede cumplir el RPO establecido con una carga normal.
• Registrar los objetivos acordados para que los cambios posteriores sean deliberados y visibles.

Definir los objetivos de tiempo de recuperación

El objetivo de tiempo de recuperación, o RTO, es la duración máxima aceptable entre una interrupción y el restablecimiento del servicio. Mientras que el RPO se refiere a cuántos datos se pierden, el RTO se refiere a cuánto tiempo espera la gente. Un RTO de dos horas significa que el proceso de restauración, incluidas la recuperación, la validación y la reconexión, debe completarse dentro de ese plazo, lo que supone un requisito exigente cuando los datos residen en un nivel de archivo profundo.

Los RTO dependen de algo más que de la velocidad del medio de almacenamiento. La recuperación desde almacenamiento en frío puede llevar bastante tiempo, los volúmenes de datos afectan a la duración de las transferencias y los sistemas dependientes, como los servicios de identidad, la red y las bases de datos, deben restaurarse en la secuencia correcta. Un RTO realista refleja, por tanto, toda la ruta de recuperación, y un objetivo que ignore estas dependencias no se cumplirá cuando haga falta.

Tiempos de recuperación más cortos suelen requerir almacenamiento más accesible, capacidad preaprovisionada y procedimientos ensayados, todo lo cual eleva el coste. Las organizaciones suelen comprobar que un enfoque por niveles funciona mejor: asignar los RTO más exigentes a los sistemas esenciales para las operaciones y aceptar periodos de restauración más largos para los datos de archivo o de uso poco frecuente. Los RTO claros y documentados hacen visibles estas compensaciones para quienes toman las decisiones.

Elegir los niveles de almacenamiento para los datos de copia de seguridad

La selección del nivel de almacenamiento para los datos de respaldo es una decisión de costo y de recuperación, no solo una cuestión de precios. Las copias recientes que podrían necesitarse en cuestión de horas suelen corresponder a un almacenamiento de restauración rápida, mientras que las copias de archivo antiguas pueden residir en niveles de menor costo, donde la recuperación es más lenta y a veces se factura por solicitud. Como los retrasos de recuperación varían entre niveles, el nivel elegido para cada conjunto de respaldo debe verificarse frente al objetivo de tiempo de recuperación que debe cumplir. Un nivel barato de mantener pero lento de recuperar puede no ser adecuado para los datos que con mayor probabilidad se restaurarán primero.

Las políticas de ciclo de vida pueden trasladar automáticamente los datos de respaldo de niveles más rápidos a más lentos a medida que envejecen. Estas reglas reducen el esfuerzo manual y mantienen el gasto en almacenamiento alineado con la frecuencia real de lectura de cada generación. Sin embargo, las duraciones mínimas de almacenamiento y los cargos por eliminación anticipada en algunos niveles pueden hacer que las copias de corta vida cuesten más de lo esperado. Por ello, los periodos de retención y las transiciones entre niveles deben diseñarse en conjunto, para que los datos no se trasladen a un lugar del que se eliminarán antes de terminar el periodo mínimo.

El cifrado y la ubicación geográfica también forman parte de la decisión sobre el nivel. Las copias de respaldo suelen contener el mismo contenido sensible que los datos de producción, por lo que requieren los mismos estándares de cifrado y controles de acceso, sea cual sea el nivel. Los requisitos de residencia pueden limitar qué regiones pueden alojar copias, lo que a su vez reduce el conjunto de niveles disponibles. Documentar estas restricciones junto con el rendimiento y el costo ofrece una base más clara para elegir dónde reside cada generación de respaldo.

• Asigne a cada nivel el objetivo de tiempo de recuperación que debe cumplir.
• Tenga en cuenta las duraciones mínimas de almacenamiento y los cargos por eliminación anticipada.
• Aplique reglas de ciclo de vida que reflejen los patrones reales de restauración.
• Mantenga coherentes el cifrado y los controles de acceso en todos los niveles.
• Confirme que se cumplen los requisitos de residencia de datos en cada región utilizada.

Protección de las copias de respaldo contra la eliminación

Las copias de respaldo solo son útiles si no pueden eliminarse ni alterarse silenciosamente cuando un error, un script mal configurado o un actor malintencionado afecta al entorno principal. La protección frente a la eliminación suele basarse en funciones de inmutabilidad que impiden modificar o borrar una copia durante un periodo definido, incluso para los administradores. El bloqueo de objetos y la retención de escritura única son mecanismos habituales, y deben activarse de forma deliberada y no darse por supuestos como activos por defecto. Una vez aplicado, el periodo de retención debe ser lo bastante largo para cubrir el margen en el que normalmente se descubre un problema.

El control de acceso constituye la segunda capa de defensa. Los derechos de eliminación de los almacenes de respaldo deben estar separados de las cuentas de uso diario empleadas para gestionar las cargas de producción, y debe exigirse autenticación multifactor para cualquier cambio en los ajustes de retención o de bloqueo. Cuando la plataforma lo permita, exigir la aprobación de una segunda persona antes de acortar un periodo de retención añade una salvaguarda adicional. Registrar cada intento de modificar la configuración de los respaldos hace visible la actividad inusual y facilita la investigación posterior.

Una tercera capa es la separación de cuentas o suscripciones. Mantener una copia de las copias de respaldo dentro de un límite administrativo distinto significa que el compromiso de la cuenta de producción no compromete automáticamente las copias de recuperación. La replicación entre cuentas o entre regiones puede lograrlo, aunque añade costos de transferencia y almacenamiento que conviene sopesar frente al riesgo. En conjunto, la inmutabilidad, el acceso restringido y la separación dan a las copias de respaldo una posibilidad realista de sobrevivir a los sucesos para los que existen.

Pruebas de restauración programadas

Una restauración que nunca se ha probado es una suposición y no una capacidad de recuperación. Las pruebas de restauración programadas verifican que los trabajos de respaldo se completan, que los datos pueden leerse y que las aplicaciones que dependen de ellos arrancan correctamente. La frecuencia de las pruebas debe reflejar la criticidad de cada sistema y la rapidez con que cambia su configuración, examinándose con más frecuencia las cargas de trabajo más importantes. Cada prueba debe registrarse con su hora de inicio, hora de fin, alcance y resultado, de modo que las tendencias en la duración de las restauraciones sean visibles con el tiempo.

El diseño de las pruebas es tan importante como su frecuencia. Un ejercicio útil restaura los datos en un entorno aislado y no sobre producción, y comprueba la integridad, no solo que un archivo haya aparecido. Medir el tiempo transcurrido de una restauración frente al objetivo de tiempo de recuperación muestra si ese objetivo es realista en las condiciones probadas. Cuando una prueba revela una brecha, su causa debe rastrearse hasta el origen, ya sea una dependencia que falta, una credencial caducada o un paso de configuración no documentado, y la corrección debe verificarse en una ejecución posterior.

Las pruebas también mantienen actualizado el conocimiento operativo. El personal que pueda tener que ejecutar una recuperación bajo presión se beneficia de haber practicado los pasos, y los manuales operativos quedan obsoletos si no se ponen en práctica. Las pruebas pueden combinarse con revisiones de mesa, en las que el equipo recorre un escenario e identifica los puntos de decisión. Los resultados deben comunicarse a quien sea responsable de los objetivos de recuperación, de modo que los ajustes en los objetivos, niveles o procedimientos se basen en pruebas reales.