Architecture du datastore immuable Cloud-PBS

Dernière mise à jour: 12 mai 2026

Introduction

L’offre datastore immuable Cloud-PBS repose sur un principe simple : un second datastore PBS, dédié à la copie immuable, reste démonté du système de fichiers la plupart du temps. Il ne se monte que pendant la fenêtre de synchronisation où il tire les données depuis le datastore de production, puis se démonte à nouveau dès la fin du sync.

Cette architecture casse plusieurs vecteurs d’attaque sans nécessiter de matériel spécialisé (LTO, WORM, S3 Object Lock). Elle est disponible sur les plans qui incluent une copie immuable.

Architecture

[Datastore A]  --- pull (PBS sync job, planifié) --->  [Datastore B]
   monté                                                 démonté la plupart du temps,
   accessible                                            monté uniquement pendant le sync

Deux datastores PBS coexistent au sein de votre tenant Cloud-PBS :

  • Datastore A est la cible de production. Vos jobs de sauvegarde Proxmox VE écrivent dedans. Il est monté en permanence et accessible via votre token API.
  • Datastore B est la copie immuable. Il vit sur un volume séparé, démonté du système de fichiers du serveur PBS la plupart du temps. Il n’est ni listé dans la GUI PBS, ni atteignable via votre token API tant qu’il n’est pas monté.

À une fréquence définie (typiquement une fois par jour, paramétrable), un sync job PBS en mode pull s’exécute du côté de B :

  1. Le volume hébergeant B est monté par notre couche d’orchestration.
  2. PBS exécute le sync job en mode pull, qui copie les nouveaux chunks depuis A vers B et applique la politique de rétention propre à B.
  3. Une fois le sync terminé et la vérification d’intégrité complétée, le volume est démonté.

Entre deux cycles, B existe mais reste inaccessible côté logiciel : impossible de lister les snapshots, d’écrire, de modifier ou de supprimer son contenu sans passer par notre couche d’orchestration qui contrôle le mount.

Modèle de menace couvert

Cette architecture protège contre les vecteurs d’attaque suivants :

  • Compromission du compte API client. Le token livré au client n’a accès qu’au datastore A. Il n’a aucune visibilité sur B et ne peut ni lire, ni écrire, ni supprimer son contenu. Une fuite de token n’expose pas la copie immuable.
  • Compromission de Proxmox VE. Un attaquant qui prend la main sur votre PVE et utilise vos credentials peut endommager A, mais B est dans un autre périmètre dont votre PVE n’a pas connaissance.
  • Suppression accidentelle ou erreur d’opération. Une erreur humaine sur A (mauvais prune, mauvaise commande, mauvaise rétention) n’affecte pas B avant le prochain cycle de sync, et même alors le sync est unidirectionnel et conserve les snapshots historiques selon la rétention propre de B.
  • Ransomware ciblant les fichiers PBS. Un ransomware qui aurait obtenu un accès au shell du serveur PBS hébergeant A ne trouve pas le filesystem de B monté. Les chunks de B sont sur un volume non exposé au scan filesystem au moment de l’attaque.

Limites à connaître

L’architecture est honnête sur ce qu’elle ne couvre pas :

  • Compromission root de l’hôte qui héberge B. Un attaquant disposant de root sur le serveur PBS peut techniquement remonter le volume B. La protection vient du fait que cet hôte est durci et opéré séparément du périmètre client, mais ce n’est pas une garantie cryptographique comme S3 Object Lock.
  • Fenêtre de synchronisation. Pendant les quelques minutes où B est monté, son filesystem est techniquement accessible depuis l’hôte. Une attaque très précisément timée pourrait théoriquement l’exploiter. La fenêtre de risque est de l’ordre de 0,1 à 1 % du temps total selon la fréquence de sync.
  • Pas un vrai air-gap physique. Les disques restent connectés et alimentés. Le démontage filesystem est un air-gap logiciel, pas un air-gap électrique. Pour un vrai air-gap (LTO en coffre), la prochaine offre Cloud-PBS Sauvegarde hors ligne au troisième trimestre 2026 cible ce besoin.

Vérification d’intégrité

À chaque cycle de sync, après le démontage, un job proxmox-backup-manager verify peut être planifié sur le contenu de B (ce qui suppose un re-mount temporaire en lecture seule). Le résultat est remonté dans le rapport d’opération régulier envoyé au client. Si une erreur de vérification apparaît, l’incident est traité comme une priorité haute par notre support.

Comment souscrire

L’option datastore immuable est disponible sur les plans Dedicated et sur certains plans Shared sur demande. Pour activer cette option sur votre compte Cloud-PBS existant ou pour l’inclure dans une nouvelle souscription, contactez-nous en précisant en sujet “datastore immuable” et la fréquence de sync souhaitée (quotidienne par défaut).

Pour une vue d’ensemble du contexte ransomware et des autres couches d’immuabilité disponibles côté Proxmox, voir l’article Sauvegarde immuable Proxmox 2026.