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

Introduction

Il n'existe pas de produit unique « sauvegarde de tout » sur IONOS CLOUD, et le fait de considérer une primitive comme couvrant l'ensemble des charges de travail constitue l'erreur de conception la plus courante en matière de protection des données sur la plateforme. Chaque primitive protège une classe de défaillance spécifique, et trois d'entre elles comportent des limites qui, si elles sont ignorées, laissent un niveau silencieusement non protégé. Le Backup Service ne gère pas les bases de données managées. Un instantané est un point de retour arrière, et non une sauvegarde cohérente de base de données. De plus, le Backup Service n'offre aucune immuabilité. Cette unité traite ces limites comme des entrées de conception à part entière, puis compose les primitives en un plan de continuité unique pour FinCorp.

1. Les quatre primitives et les frontières 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 réside à associer le mécanisme à la charge de travail, plutôt qu'à recourir à celui qui est le plus familier.

1.1 Le Backup Service : périmètre et ce qu'il n'est pas

Le Backup Service est le produit de protection basé sur un agent, soutenu par Acronis Cyber Protect. Vous installez un agent sur la charge de travail, définissez un plan de protection, et l'agent transmet les données chiffrées vers une cible de stockage. Pour les charges de travail dans le cloud, les cibles sont des VM Compute Engine d'IONOS CLOUD (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 à agent externe, protège également les serveurs sur site, les postes de travail, les VM 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 parc hybride depuis une seule console lors d'une migration.

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

Deux frontières doivent être énoncées clairement. Premièrement, le Backup Service ne prend pas en charge les sauvegardes immuables. Si votre objectif de contrôle est une rétention à écriture unique, détectable en cas de manipulation (le type exigé par une récupération après rançongiciel ou une preuve d'audit), le Backup Service seul ne le fournit pas ; vous composez l'immuabilité séparément, sur le verrouillage d'objet d'Object Storage (Unité 5.2). Deuxièmement, concernant le périmètre de conformité : le Backup Service est couvert par le certificat ISO 27001 BSI IT-Grundschutz (centres de données allemands) mais n'est pas dans le périmètre d'attestation BSI C5. C5 Type 1 (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 le périmètre C5 n'hérite pas de C5 simplement parce que la source le faisait.

1.2 Les Snapshots : retour arrière au niveau de la VM, pas une sauvegarde de base de données

Un snapshot Block Storage capture l'état d'un seul dispositif Block Storage provisionné à un instant donné. Les snapshots fonctionnent sur tout type de Block Storage (HDD, SSD Standard, SSD Premium et DAS NVMe) et sont créés rapidement. Ils sont l'outil approprié pour un point de retour rapide avant une modification risquée sur place, telle qu'un correctif système d'exploitation ou une mise à niveau d'application, et ils s'associent naturellement aux portes de validation des vagues de migration enseignées dans le Module 7.

Trois propriétés définissent la manière dont vous concevez avec les snapshots, et chacune est une contrainte :

• Non incrémentiel. Chaque snapshot est une instance séparée et indépendante représentant l'état complet du volume source. 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 manuelle de la partition après le démarrage de la VM et le montage du volume.
• Local à la région. Un snapshot réside dans la région de son volume source. Il ne protège pas contre un événement au niveau de la région et ne peut pas, à lui seul, amorcer une récupération inter-régions. Pour une durabilité inter-régions, vous copiez les données protégées vers Object Storage.
• Cycle de vie manuel. Les snapshots sont conservés jusqu'à ce que vous les supprimiez. Il n'y a pas d'expiration automatique, donc une population de snapshots non gérée devient une ligne de coût silencieuse (les snapshots consomment le quota HDD) et un manque de gouvernance.

La frontière qui compte le plus ici : un snapshot est une image de dispositif de bloc cohérente en cas de crash, et non une sauvegarde cohérente au niveau de l'application ou de la 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é des bases de données a sa propre primitive, abordée ensuite.

1.3 La frontière des bases de données : PITR plus dump/restauration

La frontière la plus importante de cette unité : le Backup Service ne sauvegarde pas les bases de données gérées. Les snapshots ne servent pas non plus de sauvegarde pour elles. La continuité des bases de données sur IONOS CLOUD est assurée au sein du service de base de données lui-même, par deux mécanismes natifs.

Le premier est la récupération à un instant donné (PITR). Managed PostgreSQL automatise les sauvegardes continues vers un bucket IONOS Cloud Object Storage chiffré dans la même région (les bases de données dans les régions sans IONOS CLOUD Object Storage sont sauvegardées vers eu-central-2), et l'emplacement de stockage des sauvegardes est immuable. La fenêtre PITR est de 7 jours par défaut pour PostgreSQL, et sur PostgreSQL, la rétention est configurable de 1 à 365 jours via backup.retentionDays ; n'enseignez pas 7 comme une 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 auxquelles vous devez concevoir autour : une seule sauvegarde peut être restaurée à la fois, le cluster doit être AVAILABLE, vous pouvez restaurer depuis la même version majeure ou une version plus ancienne, une restauration peut déplacer une base de données vers une autre région, et recoveryTargetTime n'est pas inclusif. La cible de récupération n'est pas sans perte dans le pire des cas : si tous les répliques perdent les données simultanément, la fenêtre potentielle de perte de données est d'au maximum les 30 dernières minutes ou 16 Mo.

Le second est le dump/restauration logique, le même mécanisme qui sert de seule voie 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 déposé dans Object Storage vous donne une copie portable, tolérante aux versions du moteur, qui survit en dehors du cluster, ce que le PITR (lié au magasin de sauvegarde immuable propre au cluster) ne fournit pas.

Ainsi, la conception de la récupération des bases de données est stratifiée : PITR pour un retour arrière granulaire dans la fenêtre de rétention, et des dumps logiques planifiés vers Object Storage pour une rétention à long terme, portable et (avec le verrouillage d'objet) détectable en cas de manipulation.

2. Composer un plan de continuité des données

Aucune primitive isolée ne constitue un plan de continuité. Le plan émerge lorsque vous attribuez à chaque niveau de charge de travail le mécanisme adapté à sa classe de défaillance et à son objectif de récupération, puis que vous ajoutez Object Storage comme couche d'archivage commune et d'immuabilité sous-jacente.

Le tableau suivant associe la classe de défaillance réellement couverte par chaque primitive.

Deux règles de composition découlent de ce tableau. Premièrement, l'immuabilité est une propriété d'Object Storage, et non de Backup Service : lorsqu'un niveau nécessite une rétention en écriture unique, la copie de récupération doit être déposée dans un bucket avec object lock, que cette copie soit une cible Backup Service, des données exportées d'un instantané, ou un vidage de base de données. L'object lock prend en charge les modes GOVERNANCE et COMPLIANCE, avec une rétention allant jusqu'à 365 jours dans le DCD et jusqu'à 100 ans via l'API. Deuxièmement, la durabilité multi-région est obtenue en plaçant une copie dans Object Storage, car les instantanés et les magasins de sauvegarde PITR sont liés à une région.

Étude de cas d'entreprise (FinCorp)

Le patrimoine réglementé de FinCorp couvre les charges de travail VMware migrées, un cluster PostgreSQL managé situé derrière la couche applicative, et l'archive d'audit établie dans le Module 2. Conformément aux exigences de BSI et du RGPD, l'objectif n'est pas de « tout sauvegarder », mais d'adopter une posture de récupération par couche, défendable, avec des preuves infalsifiables là où cela est obligatoire.

La couche de calcul (les VM migrées et les VM natives d'IONOS CLOUD) est protégée par le Backup Service. Lors de la migration, cela présente un double avantage : la variante avec agent externe protège les VM sur site pendant la bascule depuis la même console qui protégera ensuite les VM d'IONOS CLOUD. Étant donné que le Backup Service ne propose pas d'immutabilité, FinCorp dirige les copies de récupération en cas de rançongiciel vers une cible Object Storage avec verrouillage d'objets en mode COMPLIANCE, afin que la copie de preuve ne puisse être modifiée ni supprimée pendant sa période de rétention. Les étapes à risque en place lors de la bascule sont précédées immédiatement d'un point de retour par instantané, en acceptant que les instantanés sont locaux à la région et constituent des artefacts de travail à durée courte, et non l'archive.

Le cluster PostgreSQL est délibérément exclu du Backup Service, car il s'agit de la limite de la plateforme. Sa continuité repose sur le PITR pour la fenêtre opérationnelle de 7 jours, ainsi que sur un pg_dump quotidien envoyé vers un bucket verrouillé par objet pour la copie à long terme, portable et de qualité d'audit. La fenêtre de perte maximale de 30 minutes / 16 Mo est documentée comme le RPO accepté du cluster et conciliée avec le RPO métier repris dans l'Unité 7.1. L'archive d'audit elle-même se trouve déjà dans un Object Storage verrouillé par objet depuis l'Unité 2.3. Le résultat est un plan de continuité unique : des mécanismes distincts par couche, l'Object Storage comme socle immuable partagé, et aucune couche ne reposant silencieusement sur une primitive qui ne la couvre pas.

Résumé de la décision

Choisissez le mécanisme de protection en fonction de la couche de charge de travail et de l'objectif de récupération, et non en fonction de la familiarité.

Contraintes rigoureuses à retenir : le Backup Service exclut les bases de données managées et n'offre pas de sauvegardes immuables ; les Snapshots sont non incrémentiels, locaux à la région, conservés manuellement et non cohérents pour les bases de données ; le PITR est limité par la fenêtre et local à la région ; l'immuabilité et la durabilité inter-régions sont obtenues sur Object Storage.

Résumé

La protection des données IONOS CLOUD est un ensemble de primitives à usage unique, chacune dotée d'une limite stricte, que vous composez en un plan de continuité unique plutôt qu'en un simple produit de sauvegarde. Le Backup Service protège les VM et le Block Storage (ainsi que les environnements hybrides), mais pas les bases de données managées, et ce sans sauvegardes immuables ; les instantanés sont des points de retour arrière rapides et locaux à la région, et non des sauvegardes de base de données ; les bases de données managées sont restaurées via leur propre PITR ainsi que des déchargements/restaurations portables ; et le verrouillage d'objet du Object Storage fournit la couche d'immutabilité et d'archivage inter-régions que les autres mécanismes ne possèdent pas. Assignez un mécanisme par niveau selon la classe de défaillance, et faites du Object Storage le socle commun.

Points clés :

• Le Backup Service (Acronis) couvre les VM et le Block Storage, y compris les VM sur site et dans d'autres clouds via l'agent externe, mais n'effectue explicitement pas de sauvegarde des bases de données managées et ne prend pas en charge les sauvegardes immuables.
• Les instantanés du Block Storage sont des points de retour arrière au niveau de la VM, représentant l'état complet, non incrémentiels, locaux à la région et conservés manuellement, et non des sauvegardes cohérentes pour une base de données.
• La continuité des bases de données managées est native : PITR (7 jours par défaut pour PostgreSQL, configurable de 1 à 365 jours ; 7 jours pour MariaDB) pour la restauration dans la fenêtre de rétention, ainsi que des déchargements/restaurations logiques pour des copies portables à long terme.
• L'immutabilité et la durabilité inter-régions sont des propriétés du Object Storage (verrouillage d'objet GOVERNANCE / COMPLIANCE), composées sous la copie de restauration qui en a besoin.
• La conformité est propre à chaque service : le Backup Service relève de l'ISO 27001 IT-Grundschutz, et non de l'attestation BSI C5, de sorte qu'une sauvegarde n'hérite pas du périmètre de la charge de travail source.

Terminologie importante :

• Restauration à un instant donné (PITR) : Sauvegarde continue de la base de données vers un stockage Object Storage immuable et local à la région, permettant la restauration à n'importe quel horodatage dans la fenêtre de rétention ; limitée par la fenêtre et non une copie portable.
• Verrouillage d'objet : Rétention en écriture unique et lecture multiple du Object Storage en mode GOVERNANCE ou COMPLIANCE (jusqu'à 365 jours via DCD, 100 ans via API) ; la couche d'immutabilité de la plateforme.
• Déchargement/restauration logique : Export/import au niveau du moteur (pg_dump/pg_restore/psql, mariadb-dump) qui produit une copie portable et tolérante aux versions de la base de données, servant également de seule voie de migration pour les bases de données managées.

Lectures complémentaires

• Unité 5.2 : Object Storage (verrouillage des objets, cycle de vie, couche d'immuabilité et d'archivage)
• Unité 5.3 : Bases de données relationnelles (fenêtre PITR, déchargement/restauration, RPO en mode réplication)
• Unité 7.1 : Résilience et continuité d'activité (séparation du plan de continuité des données du plan de routage du trafic ; repères RTO/RPO)