Política de retención de copias de seguridad: cómo elegir los períodos de retención y las reglas de eliminación

Una política de retención de copias de seguridad define qué estados de datos permanecen disponibles, durante cuánto tiempo los conserva y qué ocurre cuando la retención finaliza. Su propósito va más allá del ahorro de espacio. Una historia demasiado corta puede caducar antes de que alguien detecte un error. Una historia demasiado larga aumenta el volumen, los costos y la cantidad de datos sensibles que necesitan protección.

Una política útil establece la historia de recuperación requerida, la granularidad del punto de recuperación, las ubicaciones de almacenamiento, las excepciones de eliminación y un propietario para cada sistema. Un número predefinido de días tomado de un ejemplo de otra persona no puede reemplazar estas decisiones.

Separe cuatro preguntas de retención diferentes

Un programa de respaldo no define toda la política de retención

Un período de retención prolongado no proporciona automáticamente un historial detallado. Si solo conserva un punto de recuperación por mes, no puede garantizar la restauración en cualquier día de ese mes. Por el contrario, las copias de seguridad frecuentes no le ayudarán a encontrar un estado anterior si la historia completa expira antes de que alguien descubra el problema.

Una copia de seguridad y un archivo sirven para propósitos relacionados pero diferentes. Una copia de seguridad restaura un estado seleccionado de un sistema o sus datos. Un archivo puede apoyar una retención prolongada y búsquedas de registros individuales. En lugar de aplicar automáticamente un período de retención de archivo a cada copia de seguridad completa del sistema, clarifique el resultado requerido.

Para una aplicación en la nube, verifique la historia de versiones nativa, la papelera, las reglas de retención de contenido y las funciones de copia de seguridad por separado. Su alcance y operaciones disponibles pueden ser diferentes. Una política de retención no prueba que la recuperación requerida es posible, y el nombre del proveedor no establece que es imposible.

Recopile los requisitos para cada grupo de datos

Defina la profundidad y el nivel de detalle necesarios.

Pregunte al propietario del sistema qué errores necesitan ser corregidos y cuándo las personas suelen descubrirlos. Una eliminación detectada inmediatamente y una corrupción silenciosa descubierta durante una posterior conciliación requieren diferentes registros. Tenga en cuenta los ciclos de negocio completados, las comprobaciones de datos y la capacidad de restaurar un estado anterior utilizable.

Especifique con qué precisión debe seleccionar un estado: una transacción específica, un momento cercano, un día o un punto histórico menos frecuente. Compare esto con los cambios de datos y el RPO acordado. El RPO describe la pérdida aceptable de cambios recientes, pero no determina automáticamente la profundidad de todo el historial.

Enumere los datos y las dependencias que deben restaurarse juntos. Una aplicación puede necesitar su base de datos, archivos, configuraciones y versiones de componentes compatibles. Mantener un elemento durante mucho tiempo no ayudará si un componente relacionado ya ha caducado o no se puede utilizar.

Verifique las restricciones y responsabilidades

Clasifique los datos según su valor, sensibilidad y las reglas aplicables. El propietario del proceso confirma la necesidad de un historial. El propietario técnico verifica las capacidades del producto y los costos. Acuerde los requisitos para documentos, datos personales y excepciones de eliminación con las personas responsables en la organización.

No asigne un período de retención único a todos los datos simplemente porque alguien menciona HIPAA, GDPR, regulaciones financieras u otra ley de otro país. Cada requisito se aplica a datos, organizaciones y actividades específicas. Registre el resultado acordado de esa evaluación en la política de copia de seguridad, en lugar de una suposición basada en el nombre de una ley.

Diseñe niveles de historial y verifique los límites del producto

Mantenga los puntos de recuperación que necesita, en lugar de simplemente más archivos

Puede dividir la política en un historial reciente detallado y puntos más antiguos menos frecuentes. Un esquema GFS generalmente describe una combinación de copias de seguridad diarias, semanales y mensuales. Ayuda a organizar el historial, pero no prescribe períodos de retención obligatorios ni garantiza cada estado intermedio.

Para cada nivel, defina cómo seleccionar los puntos de recuperación, cuánto tiempo conservarlos y cómo se mueven entre los niveles. Confirme qué evento utiliza el producto para calcular la antigüedad: inicio de la tarea, creación del punto de recuperación, u otro evento. Verifique la zona horaria y las reglas de superposición. El conjunto de datos realmente conservado es más importante que un nombre de horario fácil de entender.

Si utiliza copias completas e incrementales, establezca qué datos requiere el punto de recuperación seleccionado. Eliminar manualmente un archivo individual de una cadena de copias es arriesgado. Utilice la gestión del ciclo de vida compatible y verifique que preserva las dependencias de otros puntos de recuperación. Verifique la implementación antes de confiar en una afirmación de que cada punto es independiente.

Separe la retención, el tipo de almacenamiento y la disponibilidad de recuperación.

Mover los datos históricos más antiguos a una clase de almacenamiento más económica puede cambiar el tiempo de recuperación, los costos de recuperación y las restricciones de eliminación. Antes de moverlos, confirme que puede recuperar los datos dentro del tiempo requerido. Un precio de almacenamiento bajo no puede compensar una ruta de recuperación inadecuada.

Por ejemplo, AWS Backup utiliza configuraciones separadas para los horarios, el ciclo de vida y las transiciones al almacenamiento en frío. El soporte para las transiciones depende del recurso, y se aplican límites a la retención mínima y a los cambios de configuración. Verifique las condiciones actuales de su servicio. No transfiera los números y límites de un producto a otro.

Para copias almacenadas en otro lugar, verifique las propias reglas del destino. La retención, la clase de almacenamiento y el comportamiento después de la eliminación de la copia principal pueden diferir de la fuente. Registre qué copias controla la política, incluyendo copias manuales más antiguas y datos retenidos después de que un sistema deje de estar en servicio.

Acuerde sobre los bloqueos y excepciones antes de la eliminación.

La inmutabilidad puede impedir la eliminación temprana. Su duración no siempre coincide con todo el período de retención. Verifique ambos valores, los permisos para cambiarlos y la configuración irreversible. Extender un período puede comprometerle a costos adicionales, mientras que acortarlo mediante controles normales puede ser imposible.

Una investigación u otra excepción acordada puede requerir que suspenda la eliminación de un conjunto de datos específico. Especifique la razón, el alcance, el propietario de la decisión, la fecha de revisión y el proceso para eliminar la excepción. Verifique exactamente cómo lo soporta el producto. No asuma que cada copia de seguridad proporciona automáticamente una retención legal.

Complete la matriz de políticas de retención.

Utilice una fila separada para cada sistema o clase de datos con los mismos requisitos. Complete los campos entre corchetes una vez que se haya llegado a un acuerdo. Si los datos dentro de un sistema tienen diferentes restricciones, separe las filas y verifique si el producto puede aplicar diferentes reglas sin comprometer una recuperación completa.

Matriz de retención con campos para acordar

Añadir la versión de la política y la configuración que la implementa a la matriz. Registrar las excepciones aprobadas y el proceso de cambio por separado. Esto le permite comparar la decisión acordada con la configuración real, en lugar de buscar en correos electrónicos y trabajos antiguos.

Verificar la aplicación de la política y la finalización de la retención

Después de la configuración, compare los puntos de recuperación esperados y reales en los límites de la capa. Asegúrese de que el historial más antiguo requerido permanezca y de que las reglas no entren en conflicto. Verifique cómo se comportan los puntos de recuperación existentes después de un cambio de política: el producto puede aplicar nuevas configuraciones de manera diferente a ellos que a las nuevas copias.

Restaurar un punto de recuperación más antiguo y uno reciente. Verifique la disponibilidad de la aplicación, las dependencias requeridas y los datos en la clase de almacenamiento correspondiente. Para una copia encriptada, confirme el acceso a las claves de descifrado. Mida el tiempo de recuperación y verifique que los datos restaurados soporten la tarea empresarial.

La expiración debe desencadenar la acción prevista, siempre que se tengan en cuenta los bloqueos y las excepciones. Verifique los resultados de la eliminación, los errores y las copias restantes en otras ubicaciones. Eliminar una entrada de catálogo no siempre libera inmediatamente todos los bloques físicos. Los datos compartidos, las cadenas y los mecanismos de almacenamiento pueden afectar esto. Confirme cómo el servicio y el tipo de medio verifican la eliminación.

No prometa eliminar un registro individual de forma inmediata de todas las copias de respaldo completas e inmutables. Si las reglas de acceso o eliminación requieren un manejo especial, acuerde un proceso técnicamente viable con antelación. Destruir los medios tampoco es una acción universal para todos los puntos de recuperación en la nube que han expirado.

Revise los costos, la protección y las excepciones.

• Compare la profundidad y la granularidad reales con la matriz.
• Supervise el crecimiento del volumen, los trabajos fallidos y los errores del ciclo de vida.
• Verifique los permisos, la protección del inicio de sesión administrativo y la disponibilidad de las claves.
• Incluya los costos de almacenamiento, recuperación, transferencia y mantenimiento de la compatibilidad.
• Revise los períodos de retención después de que cambien los ciclos de negocio, los sistemas, las amenazas o los requisitos acordados.
• Confirme la necesidad continua de excepciones extendidas y finalícelas de acuerdo con la decisión aprobada.
• Mantenga los resultados de verificación, los propietarios de la remediación y el historial de cambios de la política.

La automatización ayuda a aplicar horarios y eliminaciones de forma consistente. También aplicará una regla incorrecta de forma consistente. Rastrear las excepciones y verificar el resultado. Mantener indefinidamente, solo por si acaso, y un período para toda la empresa requiere la misma justificación que reducir el historial.

¿Necesita acordar la profundidad del historial y verificar su implementación? Póngase en contacto con DKs Enterprises sobre respaldo y recuperación ante desastres. Prepare su matriz de sistema, los períodos de retención actuales y las excepciones conocidas para discutir el trabajo necesario.

Fuentes

• Documentación oficial de la vida útil de las copias de seguridad de AWS