Lorsqu’une infrastructure s’étend pour inclure plusieurs clusters Proxmox VE et quelques nœuds indépendants, il peut être tentant de créer un datastore Proxmox Backup Server (PBS) pour chacun d’eux. C’est simple à comprendre et cela offre une certaine isolation, mais cela divise également le domaine de déduplication. Les espaces de noms (namespaces) de sauvegarde permettent d’envisager une architecture différente : organiser les copies selon le cluster au sein d’un même datastore et partager le réservoir de chunks utilisé par la déduplication.

Les clés de PBS avec plusieurs clusters en 20 secondes

• Un datastore peut recevoir des copies provenant de plusieurs clusters Proxmox VE.
• Les espaces de noms (namespaces) séparent logiquement les sauvegardes sans créer des stocks de chunks indépendants.
• La déduplication peut réutiliser des chunks identiques entre différentes sauvegardes situées dans le même datastore.
• Les politiques de rétention peuvent être définies par namespace.
• Centraliser tout cela augmente également le domaine de défaillance, il n’est donc pas toujours avantageux d’utiliser un seul datastore.

Cette architecture est particulièrement intéressante dans des organisations où la production, la préproduction, le développement et d’autres clusters exécutent des systèmes d’exploitation, modèles ou applications similaires. Proxmox définit précisément les namespaces comme un moyen de réutiliser un seul domaine de déduplication pour différentes sources, tout en évitant les conflits de noms et en permettant un contrôle d’accès plus granulaire.

Pourquoi plusieurs datastores peuvent réduire la déduplication

Pour comprendre la différence, il faut d’abord examiner comment Proxmox Backup Server stocke réellement les données.

Un datastore n’est pas simplement un dossier contenant des fichiers complets de chaque machine virtuelle. C’est l’unité logique dans laquelle sont stockés les snapshots, les index et les chunks contenant les données.

PBS divise les données sauvegardées en blocs identifiés par leur contenu. Les chunks utilisent une fonction SHA-256, ce qui signifie qu’un contenu identique génère le même identifiant. Les index de différents snapshots peuvent faire référence aux mêmes chunks.

La documentation technique de Proxmox décrit cette structure sous la forme :

/
├── .chunks/
├── vm/
├── ct/
└── host/

Les chunks se trouvent dans le dossier .chunks, tandis que les snapshots maintiennent les références nécessaires pour reconstruire chaque sauvegarde.

Cela explique une caractéristique importante de PBS : les copies sont envoyées de manière incrémentielle et dédupliquées sur le serveur, mais chaque snapshot représente toujours une sauvegarde complète. Il n’est pas nécessaire de restaurer une chaîne traditionnelle de full + incrementaux pour récupérer un état précis.

Supposons une infrastructure avec la répartition suivante :

Cluster Production
 ├── 25 VM Debian
 └── 10 VM Ubuntu

Cluster Développement
 ├── 15 VM Debian
 └── 5 VM Ubuntu

Cluster Préproduction
 └── 12 VM Debian

Nœud PVE indépendant
 └── 4 VM Debian

Une partie significative de ces machines utilise exactement les mêmes noyaux, bibliothèques, paquets et fichiers système.

Si chaque environnement a son propre datastore :

datastore-prod
datastore-dev
datastore-pre
datastore-edge

alors chaque datastore possède son propre stock de chunks.

Mais si l’on utilise :

datastore-flotte

avec des sources organisées dans différents namespaces :

prod
dev
pre
edge

les sauvegardes restent séparées logiquement, mais partagent le même domaine de déduplication.

Cela ne garantit pas une économie énorme dans toutes les infrastructures. L’efficacité dépend de la quantité de contenu réellement identique entre les charges. Bases de données, fichiers chiffrés, données compressées ou machines avec des contenus très variés offriront moins de réutilisation que dans un environnement où de nombreuses images sont similaires.

Qu’est-ce que les espaces de noms (namespaces) dans Proxmox Backup Server

Les namespaces ont été créés pour organiser plusieurs sources dans un seul datastore.

Ils peuvent être compris comme une hiérarchie logique pour les sauvegardes, sans pour autant constituer des datastores indépendants au sens strict.

Par exemple :

datastore : entreprise
├── production
│   ├── vm/100
│   ├── vm/101
│   └── vm/102
│
├── développement
│   ├── vm/100
│   └── vm/103
│
├── préproduction
│   └── vm/100
│
└── délégation-madrid
    └── vm/200

La présence de plusieurs clusters avec des VM portant le même identifiant, comme vm/100, ne pose plus problème puisque chaque sauvegarde appartient à un namespace différent.

PBS supporte également des namespaces imbriqués jusqu’à huit niveaux d’imbrication, avec le namespace racine comptant comme le premier niveau. Chaque niveau peut contenir des sauvegardes de machines virtuelles, containers, hôtes, ou d’autres namespaces.

Cela pourrait permettre une organisation très fine, comme :

entreprise
└── madrid
    ├── production
    └── développement

Ou encore :

infra
├── pve-cluster-01
├── pve-cluster-02
├── pve-cluster-03
├── edge-node-01
└── edge-node-02

Le fait que PBS supporte jusqu’à huit niveaux ne suggère pas qu’il soit conseillé de tous les utiliser. En général, pour une infrastructure gérée par une même équipe, il est préférable de garder une hiérarchie courte, claire et facile à identifier.

Configurer chaque cluster Proxmox VE pour utiliser son namespace

La prochaine étape consiste à configurer chaque environnement Proxmox VE pour qu’il envoie ses sauvegardes au namespace correspondant.

Concrètement, cela ressemble à :

                 ┌── Cluster Production ──> namespace : prod
                 │
                 ├── Cluster Développement ──> namespace : dev
                 │
pbs datastore ───┼── Cluster Test ─────> namespace : test
                 │
                 └── Nœud indépendant ──> namespace : edge

                     │
                     ▼

               stockage de chunks partagé

Depuis Proxmox VE, il est possible d’ajouter PBS comme stockage en spécifiant le namespace à utiliser pour chaque connexion.

Par exemple :

pvesm add pbs backup-pbs 
    --server pbs.example.net 
    --datastore entreprise 
    --namespace production 
    --username backup@pbs!cluster-prod 
    --password '' 
    --fingerprint ''

Dans un autre cluster, la même configuration peut être répliquée en changeant simplement le namespace :

pvesm add pbs backup-pbs 
    --server pbs.example.net 
    --datastore entreprise 
    --namespace développement 
    --username backup@pbs!cluster-dev 
    --password '' 
    --fingerprint ''

Dès lors, les travaux de sauvegarde des deux clusters seront logiquement séparés, tout en utilisant le même datastore sous-jacent.

Il est également recommandé de ne pas partager sans précaution une seule crédentiale avec accès complet, même si tous les systèmes appartiennent à la même organisation. PBS permet d’appliquer des permissions spécifiques à chaque namespace, ce qui limite l’impact en cas de compromission d’une crédentiale. La documentation explique explicitement comment gérer les droits au niveau des namespaces.

Rétention différenciée sans créer plusieurs datastores

Partager un datastore ne signifie pas que tous les backups doivent être conservés pendant la même durée.

Les tâches de pruning de PBS peuvent cibler un namespace précis via le paramètre ns, en limitant notamment la profondeur d’action.

Par exemple, la production pourrait conserver :

14 sauvegardes quotidiennes
8 sauvegardes hebdomadaires
12 sauvegardes mensuelles

Alors que le développement pourrait ne garder que :

2 dernières
3 quotidiennes

Exemple de commandes :

proxmox-backup-manager prune-job create prod-prune 
    --store entreprise 
    --ns production 
    --keep-daily 14 
    --keep-weekly 8 
    --keep-monthly 12 
    --schedule "daily"

proxmox-backup-manager prune-job create dev-prune 
    --store entreprise 
    --ns développement 
    --keep-last 2 
    --keep-daily 3 
    --schedule "daily"

Il est important de distinguer pruning et garbage collection (GC).

Le pruning supprime les snapshots conformément aux règles fixées. Cependant, un chunk ne peut disparaître physiquement tant qu’il reste référencé par un autre snapshot. La collecte des déchets (GC) s’occupe par la suite d’identifier les chunks non référencés et de libérer l’espace correspondant.

Dans une architecture consolidée, cette étape est cruciale : un bloc utilisé par la production ne doit pas être éliminé simplement parce que la sauvegarde de développement qui l’utilisait a été supprimée.

Un datastore unique facilite la gestion mais augmente le risque de défaillance

Consolider dans un seul datastore présente un avantage opérationnel : cela réduit le nombre de datastores à gérer.

La dernière ligne est probablement la plus critique.

Améliorer la déduplication ne doit pas devenir le seul critère pour la conception d’une plateforme de sauvegarde.

Si quatre clusters dépendent du même datastore et que ce stockage devient indisponible, tous perdent temporairement l’accès à leurs sauvegardes. Un problème majeur de stockage a également une portée plus grande.

C’est pourquoi il peut être pertinent dans certains cas de maintenir des datastores séparés.

Un environnement soumis à des exigences réglementaires peut nécessiter une séparation. Certains clusters peuvent aussi nécessiter des technologies différentes ou des niveaux de performance spécifiques. Enfin, une infrastructure critique pourrait mériter une indépendance vis-à-vis des autres, même si cela réduit la possibilité de déduplication.

De plus, la capacité de gestion doit être prise en compte. La documentation PBS indique qu’un datastore peut contenir de nombreux backups, à condition que le stockage sous-jacent soit suffisant en capacité et en performance. La consolidation n’élimine pas les exigences en termes d’IOPS, de bande passante, de CPU, de mémoire ou de fenêtres de maintenance.

Une architecture hybride est souvent la solution la plus équilibrée

Il n’est pas nécessaire de choisir entre deux extrêmes.

Une entreprise pourrait par exemple opter pour :

PBS
├── datastore-général
│   ├── namespace : développement
│   ├── namespace : test
│   ├── namespace : services-internes
│   └── namespace : edge
│
└── datastore-critique
    └── namespace : production

Ainsi, des systèmes similaires partagent la déduplication tandis que les charges sensibles ou critiques restent isolées.

Il est également essentiel de rappeler qu’un datastore PBS ne doit pas être confondu avec une stratégie globale de protection des données.

PBS permet la configuration de serveurs distants et de tâches de synchronisation pour échanger du contenu entre plusieurs PBS. Il supporte également le chiffrement côté client ; Proxmox précise que cet encryption supplémentaire n’est pas activé par défaut.

Une architecture plus avancée pourrait ressembler à :

Cluster Proxmox VE 1 ──> PBS principal ──> PBS distant
Cluster Proxmox VE 2 ──> PBS principal ──> PBS distant
Cluster Proxmox VE 3 ──> PBS principal ──> 
Nœud indépendant ──────> 
                   │
                   ├─ namespaces
                   ├─ déduplication
                   ├─ pruning
                   ├─ vérification
                   └─ collecte des déchets (GC)

La déduplication permet d’optimiser l’utilisation du stockage. Les namespaces facilitent la gestion de l’organisation. Les tâches de vérification contrôlent l’intégrité, et la synchronisation vers un autre PBS peut assurer une double localisation. Ces éléments sont liés, mais ne se substituent pas l’un à l’autre.

Quand privilégier un seul datastore avec namespaces

Cette architecture est particulièrement adaptée lorsque plusieurs clusters appartiennent à la même organisation, utilisent des systèmes d’exploitation et des modèles similaires, et peuvent partager un même domaine de stockage raisonnablement.

Le partage de datastores reste préférable si :

• un isolement physique ou administratif est requis ;
• les exigences de performance ou de stockage diffèrent ;
• une règlementation impose une séparation des données ;
• un environnement critique doit limiter sa dépendance vis-à-vis des autres ;
• la taille d’une charge rend difficile la gestion d’un datastore partagé.

En conclusion, il ne s’agit pas de créer systématiquement un datastore par cluster ni de tout centraliser. PBS offre les outils pour concevoir une solution intermédiaire : datastores comme domaines de stockage et de déduplication, namespaces pour organiser les sources, et politiques de rétention adaptées à chaque besoin.

Questions fréquentes

PBS dé-duplique-t-il les sauvegardes provenant de clusters Proxmox différents ?

Il peut réutiliser des chunks identiques si les sauvegardes sont dans le même datastore. Les namespaces permettent de séparer logiquement les sources sans créer des domaines de déduplication indépendants.

Un namespace peut-il avoir une politique de rétention différente ?

Oui. Les tâches de prune peuvent cibler un namespace précis et appliquer des règles comme keep-last, keep-daily, keep-weekly, keep-monthly ou keep-yearly.

Faut-il toujours tout centraliser dans un seul datastore ?

Pas forcément. Partager un datastore favorise la déduplication et simplifie la gestion, mais augmente également le risque de défaillance totale. La séparation peut être préférable en termes de performances, isolation ou conformité réglementaire.

Les sauvegardes PBS sont-elles incrémentielles ?

Les données sont envoyées de façon incrémentielle et PBS réalise la déduplication côté serveur. Toutefois, chaque snapshot référence tous les chunks nécessaires pour représenter une sauvegarde complète.