Unité 5.7 : Protection des données et cycle de vie

Introduction

Il n'existe pas de produit unique de "sauvegarde de tout" sur IONOS Cloud, et traiter un primitive comme si elle couvrait chaque charge de travail est l'erreur de conception de protection des données la plus courante sur la plateforme. Chaque primitive protège une classe d'erreur spécifique, et trois d'entre elles comportent des limites qui, si elles sont manquées, laissent un niveau silencieusement non protégé. Le Backup Service ne touche pas les bases de données gérées. Un Snapshot est un point de restauration, et non une sauvegarde de base de données cohérente. Et le Backup Service n'offre pas d'immuabilité. Cette unité traite ces limites comme les entrées de conception qu'elles sont, puis compose les primitives en un plan de continuité unique pour FinCorp.

1. Les quatre primitives et les limites qui les séparent

Chacun des quatre mécanismes de protection des données répond à une question de récupération différente. La compétence consiste à associer le mécanisme à la charge de travail, et non à utiliser celui qui est le plus familier.

1.1 Le Backup Service : portée et ce qu'il n'est pas

Le Backup Service est le produit de protection basé sur un agent, étayé par Acronis Cyber Protect. Vous installez un agent sur la charge de travail, définissez un plan de protection, et l'agent envoie des données chiffrées à une cible de stockage. Pour les charges de travail dans le cloud, les cibles de charge de travail sont les machines virtuelles IONOS Cloud Compute Engine (Dedicated Core, vCPU, et Cubes), provisionnées à partir d'images publiques (installation automatique de l'agent) ou d'images privées (installation manuelle). Le même produit, dans sa variante d'agent externe, protège également les serveurs sur site, les postes de travail, les machines virtuelles dans d'autres clouds publics, les machines virtuelles Hyper-V et VMware, ainsi que les appareils macOS, ce qui en fait l'outil naturel pour protéger un patrimoine hybride à partir d'une seule console pendant une migration.

Le chiffrement est solide : les données en transit utilisent HTTPS et TLS, et les données au niveau de REST utilisent un chiffrement de serveur AES-256, avec un chiffrement facultatif du côté client AES-256 que vous activez par plan de protection avec un mot de passe. La cible de stockage par défaut est le stockage de sauvegarde, mais vous pouvez également diriger les sauvegardes vers Object Storage (IONOS Cloud, S3-compatible, ou d'autres fournisseurs préconfigurés) ou Network File Storage.

Deux limites doivent être énoncées clairement. Premièrement, le Backup Service ne prend pas en charge les sauvegardes immutables. Si votre objectif de contrôle est la preuve de non-altération, la rétention d'écriture unique (le type d'exigence de récupération après ransomware ou de preuve d'audit), le Backup Service seul ne le fournit pas ; vous composez l'immutabilité séparément, sur Object Storage verrouillage d'objet (Unité 5.2). Deuxièmement, en ce qui concerne la portée de conformité : le Backup Service est couvert par le certificat BSI IT-Grundschutz ISO 27001 (centres de données allemands) mais n'est pas dans la portée de l'attestation BSI C5. Le type 1 C5 (2023-11-07) couvre uniquement Compute Engine, Cloud Cubes, et Object Storage. Pour FinCorp sous BSI, cette distinction est contractuelle, et non cosmétique : une sauvegarde d'une charge de travail dans la portée de C5 n'hérite pas de C5 simplement parce que la source l'a fait.

1.2 Instantanés : restauration au niveau VM, et non sauvegarde de base de données

Un instantané Block Storage Snapshot capture l'état d'un appareil Block Storage provisionné à un moment donné. Les instantanés fonctionnent sur tout type de Block Storage (HDD, SSD Standard, SSD Premium, et DAS NVMe) et sont créés rapidement. Ils constituent l'outil approprié pour un point de restauration rapide avant un changement risqué in situ, tel qu'une correction de système d'exploitation ou une mise à niveau d'application, et ils s'associent naturellement aux portes de validation de la vague de migration enseignées dans le Module 7.

Trois propriétés définissent la façon dont vous concevez avec les instantanés, et chacune constitue une contrainte :

• Non incrémentiel. Chaque Snapshot est une instance distincte et indépendante représentant l'état complet de la source Volume. Il n'y a pas de chaîne incrémentielle ; un Snapshot d'un Volume de 100 GiB contenant 10 GiB de données produit toujours un Snapshot de 100 GiB, y compris les blocs sans données écrites. Un Volume restauré plus grand peut nécessiter une extension de partition manuelle après le démarrage de VM et le montage de Volume.
• Local à la région. Un Snapshot vit dans la région de sa source Volume. Il ne protège pas contre un événement au niveau de la région et ne peut pas, par lui-même, amorcer une récupération inter-régions. Pour la durabilité inter-régions, vous copiez les données protégées vers Object Storage.
• Cycle de vie manuel. Les instantanés sont conservés jusqu'à ce que vous les supprimiez. Il n'y a pas d'expiration automatique, donc une population d'instantanés non gérée devient une ligne de coûts discrète (les instantanés consomment des quotas HDD) et un écart de gouvernance.

La limite qui compte le plus ici : un Snapshot est une image de bloc de dispositif cohérente en cas de panne, et non une sauvegarde cohérente d'application ou de base de données. Prendre un Snapshot du Volume sous une base de données gérée en cours d'exécution n'est pas un mécanisme de sauvegarde de base de données pris en charge, et il ne restaurera pas de manière fiable à un état transactionnellement cohérent. La continuité de la base de données a sa propre primitive, couverte ci-dessous.

1.3 La limite de la base de données : PITR plus dump/restore

La limite la plus importante dans cette unité : le Backup Service ne sauvegarde pas les bases de données gérées. Les instantanés ne servent pas non plus de sauvegarde pour celles-ci. La continuité de la base de données sur IONOS est livrée à l'intérieur du service de base de données lui-même, à travers deux mécanismes natifs.

Le premier est la récupération à un moment donné (PITR). Managed PostgreSQL automatise les sauvegardes continues vers un seau chiffré IONOS Cloud Object Storage dans la même région (les bases de données dans les régions sans IONOS Object Storage sont sauvegardées vers eu-central-2), et l'emplacement de stockage de sauvegarde est immuable. La fenêtre PITR est de 7 jours pour PostgreSQL par défaut, et sur PostgreSQL la rétention est configurable de 1 à 365 jours via backup.retentionDays ; n'enseignez pas 7 comme limite stricte, c'est la valeur par défaut. Managed MariaDB fournit une rétention PITR de 7 jours. La restauration est régie par des contraintes réelles que vous devez concevoir : seule une sauvegarde peut être restaurée à la fois, le Cluster doit être DISPONIBLE, vous pouvez restaurer à partir de la même version majeure ou d'une version plus ancienne, une restauration peut déplacer une base de données vers une autre région, et recoveryTargetTime est non inclusif. La cible de récupération n'est pas sans perte dans le pire des cas : si toutes les répliques perdent des données simultanément, la fenêtre potentielle de perte de données est d'au plus 30 minutes ou 16 MB.

Le second est le dump/restore logique, le même mécanisme qui sert de chemin de migration vers ces services. Pour PostgreSQL, les outils sont pg_dump, pg_restore, et psql ; pour MariaDB, c'est mariadb-dump. Un dump logique périodique atterri dans Object Storage vous donne une copie portable, tolérante aux versions du moteur, qui survive en dehors de Cluster, ce qui est exactement ce que le PITR (lié au magasin de sauvegarde immuable de Cluster) ne fournit pas.

Ainsi, la conception de récupération de base de données est en couches : PITR pour le retour arrière à grain fin dans la fenêtre de rétention, et des dumps logiques planifiés vers Object Storage pour la rétention à long horizon, portable, et (avec verrouillage d'objet) à preuve de non-altération.

2. Composition d'un plan de continuité des données

Aucun primitif unique ne constitue un plan de continuité. Le plan émerge lorsque vous attribuez à chaque niveau de charge de travail le mécanisme qui convient à sa classe de défaillance et à son objectif de récupération, puis que vous ajoutez Object Storage comme couche d'archive et d'immuabilité commune en dessous.

Le tableau suivant mappe la classe de défaillance que chaque primitif couvre réellement.

Deux règles de composition découlent de ce tableau. Premièrement, l'immuabilité est une propriété de Object Storage, et non de Backup Service : lorsque un niveau nécessite une rétention à écriture unique, la copie de récupération doit atterrir dans un bucket verrouillé par objet, que cette copie soit une cible Backup Service, des données exportées Snapshot, ou un dump de base de données. Le verrouillage d'objet prend en charge les modes GOVERNANCE et COMPLIANCE, avec une rétention allant jusqu'à 365 jours dans le DCD et jusqu'à 100 ans via le API. Deuxièmement, la durabilité inter-régions est obtenue en plaçant une copie dans Object Storage, car à la fois les magasins de sauvegarde de snapshots et de PITR sont liés à la région.

Étude de cas d'entreprise (FinCorp)

L'ensemble réglementé de FinCorp s'étend aux charges de travail VMware migrées, un Managed PostgreSQL Cluster derrière le niveau application, et les archives d'audit établies dans le Module 2. En vertu de la BSI et du GDPR, l'exigence n'est pas de « sauvegarder tout » mais une posture de récupération défendable, par niveau, avec des preuves tangibles là où elle est requise.

Le niveau de calcul (les machines virtuelles migrées et natives IONOS) est protégé par le Backup Service. Pendant la migration, cela est doublement utile : la variante d'agent externe protège les machines virtuelles sur site via la coupure à partir de la même console qui protégera les machines virtuelles IONOS par la suite. Puisque le Backup Service n'offre pas d'immutabilité, FinCorp dirige les copies de récupération des rançongiciels vers une cible Object Storage avec un verrou d'objet en mode CONFORMITÉ, de sorte que la copie de preuve ne puisse pas être modifiée ou supprimée dans son délai de conservation. Les étapes risquées sur place pendant la coupure obtiennent un point de restauration Snapshot immédiatement avant, en acceptant que les instantanés soient des artefacts régionaux et éphémères, et non des archives.

Le PostgreSQL Cluster est délibérément exclu du Backup Service, car il s'agit de la limite de la plateforme. Sa continuité est assurée par la récupération in-place (PITR) pour la fenêtre opérationnelle de 7 jours, ainsi que par un pg_dump nocturne expédié vers un seau à verrouillage d'objet pour la copie d'audit de longue durée, portable et de qualité. La fenêtre de perte de 30 minutes / 16 Mo dans le pire des cas est documentée comme la RPO acceptée du Cluster et réconciliée avec la RPO commerciale portée dans l'Unité 7.1. L'archive d'audit elle-même est déjà située dans un Object Storage à verrouillage d'objet à partir de l'Unité 2.3. Le résultat est un plan de continuité : des mécanismes distincts par niveau, Object Storage en tant que plancher immuable partagé, et aucun niveau ne repose silencieusement sur un primitif qui ne le couvre pas.

Résumé de la décision

Choisissez le mécanisme de protection en fonction du niveau de charge de travail et de l'objectif de reprise, et non en fonction de la familiarité.

Contraintes strictes à appliquer : le Backup Service exclut les bases de données gérées et n'offre pas de sauvegardes immuables ; les instantanés sont non incrémentiels, locaux à la région, retenus manuellement et non cohérents avec la base de données ; PITR est délimité par la fenêtre et local à la région ; l'immuabilité et la durabilité inter-région sont atteintes sur Object Storage.

Résumé

La protection des données IONOS est un ensemble de primitives à objet unique, chacune avec une limite stricte, que vous composez en un plan de continuité plutôt qu'en un seul produit de sauvegarde. Le Backup Service protège les machines virtuelles et les Block Storage (et les domaines hybrides) mais pas les bases de données gérées et pas avec des sauvegardes immuables ; les instantanés sont des points de restauration rapides et locaux à la région, et non des sauvegardes de base de données ; les bases de données gérées se rétablissent grâce à leur propre PITR plus un dump/restore portable ; et l'object lock du Object Storage fournit la couche d'immutabilité et d'archivage inter-région qui manque aux autres. Attribuez un mécanisme par niveau en fonction de la classe de défaillance, et laissez le Object Storage être le plancher partagé.

Points clés :

• Le Backup Service (Acronis) couvre les machines virtuelles et les Block Storage, y compris les machines virtuelles sur site et d'autres nuages via l'agent externe, mais ne sauvegarde explicitement pas les bases de données gérées et ne prend pas en charge les sauvegardes immuables.
• Les instantanés de Block Storage sont des points de restauration régionaux, manuels, non incrémentiels, et de niveau VM, et non des sauvegardes de base de données cohérentes.
• La continuité des bases de données gérées est native : PITR (PostgreSQL 7 jours par défaut, configurable 1-365 ; MariaDB 7 jours) pour la récupération dans la fenêtre, ainsi que le dump/restore logique pour les copies portables à long terme.
• L'immutabilité et la durabilité inter-région sont des propriétés de Object Storage (verrouillage d'objet GOVERNANCE / COMPLIANCE), composées sous la copie de récupération qui en a besoin.
• La conformité est par service : le Backup Service est sous IT-Grundschutz ISO 27001, et non sous l'attestation BSI C5, donc une sauvegarde n'hérite pas de la portée de la charge de travail source.

Terminologie importante :

• Récupération à un moment donné (PITR) : Sauvegarde continue de la base de données dans un magasin Object Storage immuable et de la même région, permettant la restauration à n'importe quel horodatage dans la fenêtre de rétention ; la fenêtre est limitée et n'est pas une copie portable.
• Verrouillage d'objet : Rétention Object Storage en mode GOVERNANCE ou COMPLIANCE (jusqu'à 365 jours via DCD, 100 ans via API) ; la couche d'immutabilité de la plateforme.
• Dump/restore logique : Exportation/importation au niveau du moteur (pg_dump/pg_restore/psql, mariadb-dump) qui produit une copie de base de données portable et tolérante aux versions, servant également de seul chemin de migration pour les bases de données gérées.

Lecture supplémentaire

• Unité 5.2 : Object Storage (verrouillage d'objet, cycle de vie, la couche d'immutabilité et d'archive)
• Unité 5.3 : Bases de données relationnelles (fenêtre PITR, dump/restauration, mode de réplication RPO)
• Unité 7.1 : Résilience et continuité des activités (séparation du plan de continuité des données du plan de direction du trafic ; ancrages RTO/RPO)