Unidad 5.7: Protección de datos y ciclo de vida

Introducción

No existe un único producto de "copia de seguridad de todo" en IONOS CLOUD, y tratar una primitiva como si cubriera todas las cargas de trabajo es el error de diseño de protección de datos más común en la plataforma. Cada primitiva protege una clase de fallo específica, y tres de ellas tienen límites que, si se pasan por alto, dejan una capa protegida de forma silenciosa. El Backup Service no toca las bases de datos administradas. Una instantánea es un punto de reversión, no una copia de seguridad coherente de la base de datos. Y el Backup Service no ofrece inmutabilidad. Esta unidad trata esos límites como las entradas de diseño que son, y luego compone las primitivas en un solo plano de continuidad para FinCorp.

1. Los cuatro primitivos y las fronteras que los separan

Cada uno de los cuatro mecanismos de protección de datos responde a una pregunta de recuperación diferente. La habilidad reside en asociar el mecanismo con la carga de trabajo, no en recurrir a aquel que resulte más familiar.

1.1 El Backup Service: alcance y lo que no es

El Backup Service es el producto de protección basado en agentes, respaldado por Acronis Cyber Protect. Usted instala un agente en la carga de trabajo, define un plan de protección y el agente envía datos cifrados a un destino de almacenamiento. Para las cargas de trabajo en la nube, los destinos son las máquinas virtuales del Compute Engine de IONOS CLOUD (Dedicated Core, vCPU y Cubes), aprovisionadas desde imágenes públicas (instalación automática del agente) o imágenes privadas (instalación manual). El mismo producto, en su variante de agente externo, también protege servidores en las instalaciones, estaciones de trabajo, máquinas virtuales en otras nubes públicas, máquinas virtuales Hyper-V y VMware, y dispositivos macOS, lo que lo convierte en la herramienta natural para proteger un entorno híbrrido desde una sola consola durante una migración.

El cifrado es sólido: los datos en tránsito utilizan HTTPS y TLS, y los datos en reposo utilizan cifrado AES-256 del lado del servidor, con cifrado AES-256 opcional del lado del cliente que usted activa por plan de protección mediante una contraseña. El destino de almacenamiento predeterminado es Backup Storage, pero también puede dirigir las copias de seguridad a Object Storage (IONOS CLOUD, compatible con S3, u otros proveedores preconfigurados) o a Network File Storage.

Deben enunciarse con claridad dos fronteras. Primero, el Backup Service no admite copias de seguridad inmutables. Si su objetivo de control es una retención inmutable y a prueba de manipulación (el tipo que exige un requisito de recuperación ante ransomware o de evidencia de auditoría), el Backup Service por sí solo no lo proporciona; usted compone la inmutabilidad por separado, mediante object lock en Object Storage (Unidad 5.2). Segundo, en cuanto al alcance de cumplimiento: el Backup Service está cubierto por el certificado BSI IT-Grundschutz ISO 27001 (centros de datos alemanes), pero no se encuentra dentro del alcance de la certificación C5 de BSI. C5 Type 1 (2023-11-07) cubre únicamente Compute Engine, Cloud Cubes y Object Storage. Para FinCorp bajo BSI, esa distinción es contractual, no cosmética: una copia de seguridad de una carga de trabajo con alcance C5 no hereda C5 solo porque la fuente lo tuviera.

1.2 Snapshots: reversión a nivel de máquina virtual, no copia de seguridad de base de datos

Una instantánea de Block Storage captura el estado de un dispositivo de Block Storage aprovisionado individual en un momento dado. Las instantáneas funcionan con cualquier tipo de Block Storage (HDD, SSD Standard, SSD Premium y DAS NVMe) y se crean rápidamente. Son la herramienta adecuada para un punto de reversión rápido antes de un cambio arriesgado in situ, como un parche del sistema operativo o una actualización de aplicación, y se combinan de forma natural con las puertas de validación de las olas de migración enseñadas en el Módulo 7.

Tres propiedades definen cómo usted diseña con instantáneas, y cada una es una restricción:

• No incrementales. Cada instantánea es una instancia separada e independiente que representa el estado completo del volumen de origen. No existe una cadena incremental; una instantánea de un volumen de 100 GiB que contiene 10 GiB de datos sigue produciendo una instantánea de 100 GiB, incluyendo bloques sin datos escritos. Un volumen restaurado de mayor tamaño puede requerir la extensión manual de la partición después de iniciar la máquina virtual y montar el volumen.
• Locales a la región. Una instantánea reside en la región de su volumen de origen. No protege contra un evento a nivel de región y no puede, por sí sola, iniciar una recuperación entre regiones. Para la durabilidad entre regiones, usted copia los datos protegidos a Object Storage.
• Ciclo de vida manual. Las instantáneas se conservan hasta que usted las elimine. No existe una expiración automática, por lo que una población de instantáneas no gestionada se convierte en una línea de coste silenciosa (las instantáneas consumen cuota de HDD) y en una brecha de gobernanza.

La frontera que más importa aquí: una instantánea es una imagen de dispositivo de bloques consistente ante fallos, no una copia de seguridad consistente a nivel de aplicación o de base de datos. Tomar una instantánea del volumen bajo una base de datos administrada en ejecución no es un mecanismo de copia de seguridad de base de datos admitido, y no restaurará de forma fiable a un estado transaccionalmente consistente. La continuidad de la base de datos tiene su propio primitivo, cubierto a continuación.

1.3 La frontera de la base de datos: PITR más volcado/restauración

La frontera más importante de esta unidad: el Backup Service no realiza copias de seguridad de bases de datos administradas. Las instantáneas tampoco sirven como su copia de seguridad. La continuidad de la base de datos en IONOS CLOUD se proporciona dentro del propio servicio de base de datos, a través de dos mecanismos nativos.

El primero es la recuperación en un punto en el tiempo (PITR). Managed PostgreSQL automatiza copias de seguridad continuas a un cubo de IONOS Cloud Object Storage cifrado en la misma región (las bases de datos en regiones sin IONOS CLOUD Object Storage se copian de seguridad a eu-central-2), y la ubicación de almacenamiento de la copia de seguridad es inmutable. La ventana de PITR es de 7 días para PostgreSQL por defecto, y en PostgreSQL la retención es configurable de 1 a 365 días mediante backup.retentionDays; no enseñe 7 como un límite rígido, es el valor predeterminado. Managed MariaDB proporciona una retención de PITR de 7 días. La restauración está gobernada por restricciones reales con las que usted debe diseñar: solo se puede restaurar una copia de seguridad a la vez, el clúster debe estar en estado AVAILABLE, usted puede restaurar desde la misma versión principal o una anterior, una restauración puede mover una base de datos a otra región, y recoveryTargetTime no es inclusivo. El objetivo de recuperación no está libre de pérdidas en el peor caso: si todas las réplicas pierden datos simultáneamente, la ventana potencial de pérdida de datos es de hasta los últimos 30 minutos o 16 MB.

El segundo es el volcado/restauración lógico, el mismo mecanismo que sirve como la única vía de migración hacia estos servicios. Para PostgreSQL, las herramientas son pg_dump, pg_restore y psql; para MariaDB, es mariadb-dump. Un volcado lógico periódico almacenado en Object Storage le proporciona una copia portátil y tolerante a la versión del motor que sobrevive fuera del clúster, lo cual es exactamente lo que PITR (vinculado al almacén de copias de seguridad inmutable propio del clúster) no proporciona.

Por lo tanto, el diseño de recuperación de la base de datos es por capas: PITR para reversión de grano fino dentro de la ventana de retención, y volcados lógicos programados a Object Storage para retención de largo plazo, portátil y (con object lock) a prueba de manipulación.

2. Composición de un plano de continuidad de datos

Ninguna primitiva por sí sola constituye un plano de continuidad. El plano surge al asignar a cada nivel de carga de trabajo el mecanismo que se ajusta a su clase de fallo y objetivo de recuperación, y añadiendo Object Storage como capa común de archivo e inmutabilidad en la base.

La siguiente tabla muestra la clase de fallo que cada primitiva cubre realmente.

De esta tabla se derivan dos reglas de composición. En primer lugar, la inmutabilidad es una propiedad de Object Storage, no de Backup Service: cuando un nivel requiere retención de solo una escritura, la copia de recuperación debe almacenarse en un cubo con bloqueo de objetos, ya sea que esa copia sea un destino de Backup Service, datos exportados de una instantánea o un volcado de base de datos. El bloqueo de objetos admite los modos GOVERNANCE y COMPLIANCE, con retención de hasta 365 días en el DCD y de hasta 100 años a través de la API. En segundo lugar, la durabilidad entre regiones se logra obteniendo una copia en Object Storage, porque tanto las instantañas como los almacenes de copias de seguridad de PITR están limitados a la región.

Estudio de caso empresarial (FinCorp)

El patrimonio regulado de FinCorp abarca las cargas de trabajo de VMware migradas, un clúster administrado de PostgreSQL detrás de la capa de aplicaciones y el archivo de auditoría establecido en la Unidad 2. Bajo BSI y el RGPD, el requisito no es "hacer una copia de seguridad de todo", sino una postura de recuperación por capa, defendible, con evidencia que muestre alteraciones donde esté mandado.

La capa de cómputo (las VM migradas y las VM nativas de IONOS CLOUD) está protegida por el Backup Service. Durante la migración, esto resulta doblemente útil: la variante con agente externo protege las VM en las instalaciones a través del corte desde la misma consola con la que protegerá las VM de IONOS CLOUD después. Dado que el Backup Service no ofrece inmutabilidad, FinCorp dirige las copias de recuperación ante ransomware a un destino de Object Storage con bloqueo de objetos en modo COMPLIANCE, de modo que la copia de evidencia no pueda ser alterada ni eliminada dentro de su período de retención. Los pasos arriesgados in situ durante el corte reciben un punto de reversión mediante instantánea inmediatamente antes, aceptando que las instantáneas son locales a la región y son artefactos de trabajo de vida corta, no el archivo.

El clúster de PostgreSQL se excluye deliberadamente del Backup Service, porque ese es el límite de la plataforma. Su continuidad es PITR para la ventana operativa de 7 días, más una copia nocturna de pg_dump enviada a un cubo con bloqueo de objetos para la copia de largo plazo, portable y de grado de auditoría. La ventana de pérdida en el peor caso de 30 minutos / 16 MB está documentada como el RPO aceptado del clúster y se concilia con el RPO de negocio llevado a la Unidad 7.1. El propio archivo de auditoría ya se encuentra en Object Storage con bloqueo de objetos desde la Unidad 2.3. El resultado es un plano de continuidad único: mecanismos distintos por capa, Object Storage como piso inmutable compartido y ninguna capa que dependa silenciosamente de un primitivo que no la cubra.

Resumen de la decisión

Elija el mecanismo de protección según la capa del Workload y el objetivo de recuperación, no según la familiaridad con la herramienta.

Restricciones duras a considerar: el Backup Service excluye las bases de datos administradas y no ofrece copias de seguridad inmutables; los Snapshots no son incrementales, son locales a la región, se retienen manualmente y no son consistentes a nivel de base de datos; el PITR está ligado a una ventana de tiempo y es local a la región; la inmutabilidad y la durabilidad entre regiones se logran en Object Storage.

Resumen

La protección de datos de IONOS CLOUD es un conjunto de primitivas de un solo propósito, cada una con un límite estricto, que se combinan en un único plano de continuidad en lugar de un solo producto de copia de seguridad. El Backup Service protege las VM y el Block Storage (y los entornos híbridos), pero no las bases de datos administradas ni con copias de seguridad inmutables; las instantáneas son puntos de reversión locales a la región y de rápida ejecución, no copias de seguridad de bases de datos; las bases de datos administradas se recuperan mediante su propio PITR más volcado/restauración portátil; y el bloqueo de objetos de Object Storage proporciona la capa de inmutabilidad y archivo entre regiones que las demás carecen. Asigne un mecanismo por nivel según la clase de fallo, y deje que Object Storage sea la base compartida.

Puntos clave:

• El Backup Service (Acronis) cubre las VM y el Block Storage, incluidas las VM en las instalaciones y en otras nubes a través del agente externo, pero no realiza copias de seguridad de las bases de datos administradas y no admite copias de seguridad inmutables.
• Las instantáneas de Block Storage son puntos de reversión a nivel de VM con estado completo, no incrementales, locales a la región y retenidos manualmente, no copias de seguridad consistentes con la base de datos.
• La continuidad de las bases de datos administradas es nativa: PITR (PostgreSQL con un valor predeterminado de 7 días, configurable de 1 a 365; MariaDB de 7 días) para la recuperación dentro de la ventana, más volcado/restauración lógica para copias portátiles de largo plazo.
• La inmutabilidad y la durabilidad entre regiones son propiedades de Object Storage (bloqueo de objetos GOVERNANCE / COMPLIANCE), compuestas bajo la copia de recuperación que las necesite.
• El cumplimiento es por servicio: el Backup Service se encuentra bajo IT-Grundschutz ISO 27001, no bajo la certificación BSI C5, por lo que una copia de seguridad no hereda el alcance de la carga de trabajo de origen.

Terminología importante:

• Recuperación en un punto en el tiempo (PITR): Copia de seguridad continua de la base de datos en un almacén de Object Storage inmutable y de la misma región, que permite la restauración a cualquier marca de tiempo dentro de la ventana de retención; está limitada por la ventana y no es una copia portátil.
• Bloqueo de objetos: Retención de escritura única y lectura múltiple de Object Storage en modo GOVERNANCE o COMPLIANCE (hasta 365 días a través de DCD, 100 años a través de API); la capa de inmutabilidad de la plataforma.
• Volcado/restauración lógica: Exportación/importación a nivel de motor (pg_dump/pg_restore/psql, mariadb-dump) que produce una copia portátil y tolerante a versiones de la base de datos, que también sirve como la única ruta de migración de bases de datos administradas.

Lectura adicional

• Unidad 5.2: Object Storage (bloqueo de objetos, ciclo de vida, capa de inmutabilidad y archivo)
• Unidad 5.3: Bases de datos relacionales (ventana de PITR, volcado/restauración, RPO en modo de replicación)
• Unidad 7.1: Resiliencia y continuidad del negocio (separación del plano de continuidad de datos del plano de enrutamiento de tráfico; puntos de referencia de RTO/RPO)