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

Introducción

No hay un solo producto "copia de seguridad de todo" en IONOS Cloud, y tratar a un primitivo como si cubriera cada Workload es el error de diseño de protección de datos más común en la plataforma. Cada primitivo protege una clase de fallo específica, y tres de ellos llevan límites que, si se pasan por alto, dejan un nivel silenciosamente sin protección. El Backup Service no afecta a las bases de datos gestionadas. Un Snapshot es un punto de reversión, no una copia de seguridad de base de datos coherente. Y el Backup Service no ofrece inmutabilidad. Esta unidad trata a esos límites como las entradas de diseño que son, y luego compone los primitivos en un plano de continuidad para FinCorp.

1. Los cuatro primitivos y los límites que los separan

Cada uno de los cuatro mecanismos de protección de datos responde a una pregunta de recuperación diferente. La habilidad es emparejar el mecanismo con el Workload, no alcanzar el que es 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 agente, respaldado por Acronis Cyber Protect. Usted instala un agente en el Workload, define un plan de protección y el agente envía datos cifrados a un objetivo de almacenamiento. Para cargas de trabajo en la nube, los objetivos de carga de trabajo son máquinas virtuales de IONOS Cloud Compute Engine (Dedicated Core, vCPU y Cubes), provisionadas a partir de imágenes públicas (instalación de agente automática) o imágenes privadas (instalación manual). El mismo producto, en su variante de agente externo, también protege servidores locales, 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 patrimonio híbrido desde una consola durante una migración.

El cifrado es sólido: los datos en tránsito utilizan HTTPS y TLS, y los datos en REST utilizan cifrado de servidor AES-256, con cifrado de cliente AES-256 opcional que se habilita por plan de protección con una contraseña. El objetivo de almacenamiento predeterminado es Almacenamiento de copias de seguridad, pero también puede dirigir las copias de seguridad a Object Storage (IONOS Cloud, S3-compatible o otros proveedores preconfigurados) o Network File Storage.

Dos límites deben establecerse claramente. Primero, el Backup Service no admite copias de seguridad inmutables. Si su objetivo de control es evidencia de manipulación, retención de escritura única (el tipo de requisito de recuperación de ransomware o evidencia de auditoría), el Backup Service solo no lo proporciona; usted compone la inmutabilidad por separado, en Object Storage objeto bloqueado (Unidad 5.2). Segundo, en el ámbito de la cumplimiento: el Backup Service está cubierto por el certificado BSI IT-Grundschutz ISO 27001 (centros de datos alemanes) pero no está en el ámbito de acreditación BSI C5. El tipo 1 de C5 (2023-11-07) cubre Compute Engine, Cloud Cubes y Object Storage solo. Para FinCorp bajo BSI, esa distinción es contractual, no cosmética: una copia de seguridad de un C5-ámbito Workload no hereda C5 solo porque la fuente lo hizo.

1.2 Instantáneas: reversión a nivel de VM, no copia de seguridad de base de datos

Una instantánea de Block Storage Snapshot captura el estado de un dispositivo Block Storage único provisionado en un momento dado. Las instantáneas funcionan en cualquier tipo de Block Storage (HDD, SSD Estándar, 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 riesgoso en su lugar, como un parche de sistema operativo o una actualización de aplicación, y se emparejan naturalmente con las puertas de validación de la ola de migración enseñadas en el Módulo 7.

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

• No incremental. Cada Snapshot es una instancia separada e independiente que representa el estado completo del origen Volume. No hay cadena incremental; una instantánea de un Volume de 100 GiB que contiene 10 GiB de datos aún produce una instantánea de 100 GiB, incluyendo bloques con ningún dato escrito. Un Volume más grande restaurado puede necesitar una extensión de partición manual después de arrancar el VM y montar el Volume.
• Local de la región. Una instantánea vive en la región de su origen Volume. No protege contra un evento a nivel de región y no puede, por sí solo, sembrar una recuperación entre regiones. Para la durabilidad entre regiones, copie los datos protegidos a Object Storage.
• Ciclo de vida manual. Las instantáneas se conservan hasta que usted las elimina. No hay expiración automática, por lo que una población de Snapshot no administrada se convierte en una línea de costo silenciosa (las instantáneas consumen cuota de HDD) y una brecha de gobernanza.

El límite que más importa aquí: una instantánea es una imagen de dispositivo de bloque coherente con fallos, no una copia de seguridad coherente con aplicaciones o bases de datos. Tomar una instantánea del Volume bajo una base de datos administrada en ejecución no es un mecanismo de copia de seguridad de base de datos compatible, y no restaurará de manera fiable a un estado transaccionalmente coherente. La continuidad de la base de datos tiene su propia primitiva, que se cubre a continuación.

1.3 El límite de la base de datos: PITR más volcado/restaurado

El límite más importante en esta unidad: el Backup Service no respalda bases de datos administradas. Tampoco las instantáneas sirven como su copia de seguridad. La continuidad de la base de datos en IONOS se entrega dentro del servicio de base de datos en sí, a través de dos mecanismos nativos.

El primero es la recuperación en un momento dado (PITR). Managed PostgreSQL automatiza copias de seguridad continuas a un cubo cifrado IONOS Cloud Object Storage en la misma región (bases de datos en regiones sin IONOS Object Storage se respaldan en eu-central-2), y la ubicación de almacenamiento de copias de seguridad es inmutable. La ventana PITR es de 7 días para PostgreSQL por defecto, y en PostgreSQL la retención es configurable desde 1 hasta 365 días a través de backup.retentionDays; no enseñe 7 como un límite duro, es el valor predeterminado. Managed MariaDB proporciona una retención PITR de 7 días. La restauración está gobernada por restricciones reales que debe diseñar alrededor: solo se puede restaurar una copia de seguridad a la vez, el Cluster debe estar DISPONIBLE, puede restaurar desde la misma o una versión principal 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 es libre de pérdida en el peor de los casos: si todos los réplicas pierden datos simultáneamente, la ventana de pérdida de datos potencial es de hasta los últimos 30 minutos o 16 MB.

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

Así que el diseño de recuperación de la base de datos es en capas: PITR para reversión granular dentro de la ventana de retención, y volcados lógicos programados a Object Storage para retención de horizonte largo, portátil y (con bloqueo de objeto) evidencia de manipulación.

2. Componiendo un plano de continuidad de datos

Ningún primitivo es un plano de continuidad. El plano emerge cuando usted asigna a cada nivel de Workload el mecanismo que se adapta a su clase de fallo y objetivo de recuperación, y luego agrega Object Storage como la capa común de archivo y capa de inmutabilidad subyacente.

La siguiente tabla asigna la clase de fallo que cada primitivo cubre en realidad.

Dos reglas de composición se derivan de esta tabla. Primero, la inmutabilidad es una propiedad de Object Storage, no de Backup Service: donde un nivel necesita retención de solo escritura, la copia de recuperación debe aterrizar en un bucket bloqueado por objeto, ya sea que la copia sea un objetivo de Backup Service, datos exportados de Snapshot o un volcado de base de datos. El bloqueo de objeto admite los modos GOBERNANZA y CUMPLIMIENTO, con retención de hasta 365 días en el DCD y de hasta 100 años a través del API. Segundo, la durabilidad entre regiones se logra obteniendo una copia en Object Storage, porque tanto las tiendas de copias de seguridad de instantáneas como las de recuperación de base de datos en un punto en el tiempo están limitadas a la región.

Estudio de caso empresarial (FinCorp)

El patrimonio regulado de FinCorp abarca las cargas de trabajo de VMware migradas, un Managed PostgreSQL Cluster detrás del nivel de aplicación, y el archivo de auditoría establecido en el Módulo 2. Bajo BSI y GDPR, el requisito no es "respaldar todo" sino una postura de recuperación defensible, por nivel, con evidencia de integridad donde esté mandada.

El nivel de cómputo (las máquinas virtuales migradas y nativas de IONOS) está protegido por el Backup Service. Durante la migración, esto es doblemente útil: la variante de agente externo protege las máquinas virtuales locales a través del corte desde la misma consola que protegerá las máquinas virtuales de IONOS después. Dado que el Backup Service no ofrece inmutabilidad, FinCorp dirige las copias de recuperación de ransomware a un objetivo Object Storage con bloqueo de objeto en modo COMPLIANCE, para que la copia de evidencia no pueda ser alterada o eliminada dentro de su retención. Los pasos riesgosos en el lugar durante el corte obtienen un punto de reversión Snapshot inmediatamente antes, aceptando que las instantáneas son artefactos de trabajo regionales y de corta duración, no el archivo.

El PostgreSQL Cluster está excluido 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 pg_dump enviada a un cubo bloqueado de objeto para la copia de auditoría portátil de largo plazo. La ventana de pérdida de 30 minutos / 16 MB en el peor de los casos se documenta como el RPO aceptado de Cluster y se reconcilia con el RPO empresarial transportado a la Unidad 7.1. El archivo de auditoría en sí ya se encuentra en Object Storage bloqueado de objeto desde la Unidad 2.3. El resultado es un plano de continuidad: mecanismos distintos por nivel, Object Storage como el piso inmutable compartido, y ningún nivel confía silenciosamente en un primitivo que no lo cubre.

Resumen de la decisión

Elija el mecanismo de protección según el nivel de Workload y el objetivo de recuperación, no por familiaridad.

Restricciones difíciles de llevar adelante: el Backup Service excluye las bases de datos gestionadas y no ofrece copias de seguridad inmutables; las instantáneas no son incrementales, son locales de la región, se retienen manualmente y no son coherentes con la base de datos; PITR está limitado por la ventana y es local de la región; la inmutabilidad y la durabilidad entre regiones se logran en Object Storage.

Resumen

La protección de datos de IONOS es un conjunto de primitivas de propósito único, cada una con un límite rígido, que se componen en un plano de continuidad en lugar de un solo producto de copia de seguridad. El Backup Service protege las máquinas virtuales y Block Storage (y estados híbridos) pero no las bases de datos gestionadas y no con copias de seguridad inmutables; las instantáneas son puntos de reversión rápidos y locales de la región, no copias de seguridad de bases de datos; las bases de datos gestionadas se recuperan a través de su propio PITR más un volcado y restauración portátiles; y el bloqueo de objeto Object Storage suministra la inmutabilidad y la capa de archivo de cruz de región que los demás carecen. Asigne un mecanismo por nivel por clase de fallo, y deje que Object Storage sea el piso compartido.

Puntos clave:

• El Backup Service (Acronis) cubre las máquinas virtuales y Block Storage, incluyendo las máquinas virtuales locales y de otras nubes a través del agente externo, pero explícitamente no respalda las bases de datos gestionadas y no admite copias de seguridad inmutables.
• Las instantáneas de Block Storage son puntos de reversión de estado completo, no incrementales, locales de la región, retenidos manualmente a nivel de VM, no copias de seguridad coherentes de bases de datos.
• La continuidad de la base de datos gestionada es nativa: PITR (PostgreSQL con un valor predeterminado de 7 días, configurable entre 1-365; MariaDB con un valor de 7 días) para la recuperación en la ventana, más el volcado y restauración lógicos para copias portátiles de largo horizonte.
• La inmutabilidad y la durabilidad de cruz de región son propiedades de Object Storage (bloqueo de objeto GOVERNANCE / COMPLIANCE), compuestas bajo la copia de recuperación que las necesita.
• El cumplimiento es por servicio: el Backup Service se encuentra bajo IT-Grundschutz ISO 27001, no bajo la acreditación BSI C5, por lo que una copia de seguridad no hereda el alcance de la fuente Workload.

Terminología importante:

• Recuperación en un momento determinado (PITR): Copia de seguridad continua de la base de datos a una tienda inmutable de la misma región Object Storage, que permite restaurar a cualquier marca de tiempo dentro de la ventana de retención; limitada por la ventana y no es una copia portátil.
• Bloqueo de objeto: Retención de Object Storage de solo lectura después de escritura 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 y restauración lógicos: Exportación e importación a nivel de motor (pg_dump/pg_restore/psql, mariadb-dump) que produce una copia de base de datos portátil y tolerante a versiones, que también sirve como el único camino de migración de base de datos gestionada.

Lectura adicional

• Unidad 5.2: Object Storage (bloqueo de objeto, ciclo de vida, la capa de inmutabilidad y archivo)
• Unidad 5.3: Bases de datos relacionales (ventana PITR, volcado/restauración, modo de replicación RPO)
• Unidad 7.1: Resiliencia y continuidad empresarial (separando el plano de continuidad de datos del plano de dirección de tráfico; anclajes RTO/RPO)