Proxmox Backup Server: prérequis matériels, RAM et dimensionnement du stockage

Dimensionner Proxmox Backup Server ne consiste pas seulement à vérifier que le système dispose de la quantité minimale de RAM ou de disques suffisamment capacitaires. Dans un environnement d’entreprise, vous devez également prendre en compte le volume de données à protéger, la fréquence des modifications, la politique de rétention, le nombre de tâches simultanées et le délai dans lequel les services doivent pouvoir être restaurés.

Les performances de PBS dépendent de l’équilibre entre le CPU, la mémoire, le stockage et le réseau. Renforcer un seul composant ne résout pas nécessairement le problème: un processeur rapide, par exemple, ne compense pas les performances insuffisantes d’un datastore.

Dans cet article, nous verrons comment recueillir les données nécessaires et les traduire en une configuration adaptée à un environnement de production. Proxmox recommande un processeur d’au moins 4 cœurs, 4 GiB de RAM auxquels s’ajoute 1 GiB supplémentaire par TiB de stockage, au moins 32 GiB d’espace disque pour le système d’exploitation, des unités offrant de bonnes performances en accès aléatoire et des interfaces réseau redondantes multi-Gigabit. Ces valeurs constituent une base technique de référence, mais ne correspondent pas à un dimensionnement adapté à toutes les infrastructures.

Pour découvrir au préalable les fonctionnalités de la plateforme, vous pouvez consulter notre guide de Proxmox Backup Server.

Prérequis minimaux et recommandés pour Proxmox Backup Server

La documentation officielle distingue les prérequis minimaux pour l’évaluation de ceux recommandés pour un serveur utilisé en production.

Les prérequis minimaux sont explicitement destinés à l’évaluation du logiciel et ne doivent pas servir de référence pour un système de production. Proxmox recommande également du matériel serveur de qualité, des SSD Enterprise pour obtenir les meilleures performances et un cache dédié aux métadonnées lorsque le datastore utilise des disques HDD.

Ces indications répondent à la question «PBS peut-il fonctionner?», mais pas encore à la question la plus importante: «Le système pourra-t-il terminer les sauvegardes, les vérifications et les restaurations dans les délais exigés par l’entreprise?»

Pour y répondre, il est nécessaire d’analyser séparément chaque composant.

Combien de cœurs faut-il pour Proxmox Backup Server?

Les quatre cœurs indiqués par Proxmox constituent un point de départ. Le nombre réellement nécessaire dépend surtout de la charge et du nombre d’opérations exécutées simultanément.

Le CPU est sollicité lors des opérations suivantes:

• déduplication et compression;
• calcul et vérification des checksums;
• sauvegardes simultanées;
• vérification des snapshots;
• pruning et garbage collection;
• restauration de VM, conteneurs et fichiers;
• synchronisation avec des datastores distants.

Le nombre de machines virtuelles ne suffit pas, à lui seul, à estimer la charge. Dix VM volumineuses présentant un taux de modification élevé peuvent nécessiter davantage de ressources que cinquante VM peu actives.

Avant de choisir le CPU, vous devez donc connaître:

• nombre maximal de tâches simultanées;
• durée de la fenêtre de sauvegarde;
• fréquence des vérifications;
• volume de données traité chaque jour;
• nombre de restaurations susceptibles de se chevaucher;
• présence de synchronisations vers des sites distants ou du stockage S3.

Si les tâches sont exécutées principalement de manière séquentielle et que la fenêtre disponible est large, une configuration avec peu de cœurs peut suffire. Si, au contraire, de nombreux systèmes doivent être protégés dans le même intervalle, il faudra prévoir une capacité de traitement supérieure.

Combien de RAM faut-il?

Proxmox recommande au moins 4 GiB pour le système d’exploitation, le cache du système de fichiers et les services PBS, auxquels il faut ajouter au moins 1 GiB pour chaque TiB de stockage géré.

Un système disposant de 20 TiB de stockage nécessite donc, en théorie, au moins 24 GiB de RAM:

• 4 GiB pour le système d’exploitation, le cache et les services;
• 20 GiB correspondant aux 20 TiB de stockage.

Ce résultat ne doit pas être considéré comme une configuration définitive. Il est recommandé de prévoir une marge supplémentaire en présence de:

• système de fichiers ZFS;
• nombreux jobs simultanés;
• grand nombre de snapshots;
• vérifications fréquentes;
• fenêtres de sauvegarde restreintes;
• synchronisations distantes;
• croissance significative du stockage.

Si vous prévoyez que le datastore passera de 20 à 30 TiB au cours du cycle de vie du serveur, la mémoire doit être dimensionnée en fonction de ce scénario futur et non uniquement de l’utilisation initiale.

RAM et ZFS

ZFS utilise également la mémoire pour améliorer la gestion et les performances du stockage. La documentation de l’installateur indique, à titre de référence générale, 4 Go de RAM plus 1 Go supplémentaire par To d’espace disque brut lors de l’utilisation de ZFS.

La présence de ZFS ne signifie pas qu’il soit nécessaire d’allouer de la mémoire sans limite. Elle signifie toutefois qu’un datastore ZFS ne devrait pas être dimensionné en se basant uniquement sur le minimum prévu pour PBS.

Séparer le disque système du datastore

Le disque sur lequel Proxmox Backup Server est installé et l’espace destiné aux sauvegardes remplissent des fonctions différentes.

Disque du système d’exploitation
Le stockage système contient Debian, Proxmox Backup Server, les configurations, les logs et les paquets. Pour un environnement de production, Proxmox recommande au moins 32 GiB disponibles ainsi qu’une configuration redondante.

Les options recommandées sont:

• RAID matériel avec cache d’écriture protégé par batterie;
• configuration ZFS redondante.

ZFS ne doit pas être utilisé au-dessus d’un contrôleur RAID matériel, car il doit pouvoir accéder directement aux disques. En production, il est préférable de séparer le système d’exploitation du datastore. Cette approche facilite:

• la maintenance et les mises à jour;
• le remplacement des périphériques;
• le contrôle de l’espace disponible;
• la restauration de la configuration PBS;
• l’identification des problèmes d’I/O.

Datastore des sauvegardes
Le datastore contient les snapshots, les index et les chunks dédupliqués. PBS utilise des répertoires au sein de systèmes de fichiers pris en charge, tels que ext4, XFS ou ZFS. Ses performances ne dépendent pas uniquement de la vitesse séquentielle des disques. Lors des sauvegardes, des vérifications, de la garbage collection et des restaurations, de nombreuses opérations d’accès aléatoire sont effectuées sur les chunks et les métadonnées. Un ensemble de disques de grande capacité mais lent peut donc exécuter correctement les sauvegardes courantes, puis devenir un goulet d’étranglement lors de:

• jobs simultanés;
• vérification de grandes quantités de données;
• garbage collection;
• restaurations complètes;
• récupération d’un grand nombre de fichiers;
• reconstruction des services après un incident.

La capacité ne peut pas être évaluée indépendamment des IOPS et des temps de réponse du datastore.

Comment calculer l’espace nécessaire

Il n’existe pas de ratio universel entre la taille des VM et la capacité requise par PBS. L’espace réellement nécessaire dépend de:

1. la quantité initiale de données protégées;
2. le taux de modification quotidien;
3. la politique de rétention;
4. la déduplication et la compression obtenues sur le dataset réel;
5. la croissance prévue;

Données réellement protégées
Ne tenez pas compte uniquement de la capacité nominale des disques virtuels. Une VM disposant d’un disque virtuel de 2 To peut n’utiliser que 600 Go, tandis qu’une base de données de capacité nominale inférieure peut générer beaucoup plus de données uniques au fil du temps. Le point de départ doit être la première sauvegarde réelle, mesurée après déduplication et compression.

Taux de modification
Le taux de modification indique le volume de données nouvelles ou modifiées qui doivent être conservées entre une sauvegarde et la suivante. Il peut varier fortement selon les types de systèmes:

• serveurs applicatifs;
• serveurs de fichiers;
• bases de données;
• systèmes documentaires;
• VM contenant des données déjà compressées;
• archives multimédias;
• workloads chiffrés.

Appliquer un pourcentage générique à toutes les VM conduit facilement à une estimation erronée.

Rétention
La politique de rétention détermine le nombre de points de restauration à conserver et leur durée de conservation. Elle peut inclure des copies:

• horaires;
• quotidiennes;
• hebdomadaires;
• mensuelles;
• annuelles.

PBS conserve les chunks tant qu’au moins un snapshot les utilise. Une politique de rétention plus longue peut donc continuer à occuper de l’espace même après la suppression des données sur les systèmes d’origine.

Déduplication et compression
La déduplication peut réduire considérablement l’espace nécessaire lorsque plusieurs VM contiennent des systèmes d’exploitation, des applications ou des fichiers similaires. Le bénéfice peut être plus limité avec:

• données déjà compressées;
• vidéos et images;
• sauvegardes applicatives compressées;
• bases de données chiffrées;
• fichiers entièrement modifiés à chaque enregistrement.

Il n’est donc pas pertinent de dimensionner l’infrastructure sur la base d’un taux de déduplication hypothétique. Il est préférable de mesurer le résultat sur un échantillon représentatif.

Une première formule conceptuelle peut être exprimée comme suit:
Capacité requise = première sauvegarde réelle + données uniques conservées par la rétention + croissance prévue + marge opérationnelle

Cette formule ne remplace pas un test, mais permet d’éviter l’erreur consistant à multiplier simplement la taille des VM par le nombre de sauvegardes.

Exemple simplifié
Supposons que la première période d’observation mette en évidence:

• première sauvegarde après déduplication et compression: 3,2 TiB;
• nouvelles données uniques moyennes: 70 GiB par jour;
• rétention quotidienne: 30 points;
• croissance prévue: 15 %.

Après la première sauvegarde, les 29 points quotidiens suivants pourraient nécessiter environ: 29 × 70 GiB = 2 030 GiB. La capacité de base estimée serait donc d’environ: 3,2 TiB + 2 TiB = 5,2 TiB.

À cette valeur doivent encore être ajoutés:

• les données conservées par les rétentions hebdomadaires et mensuelles;
• la croissance prévue;
• la marge nécessaire pour la maintenance et les variations de charge.

Cet exemple sert uniquement à illustrer la méthode. Le comportement réel doit être vérifié sur le dataset de l’entreprise.

SSD, NVMe ou HDD

Le choix des disques dépend du compromis recherché entre capacité, performances, temps de restauration et budget.

Proxmox recommande un stockage rapide, capable de supporter des charges d’I/O aléatoires. Pour obtenir les meilleures performances, il recommande des SSD Enterprise; en présence de HDD, il conseille d’utiliser un cache de métadonnées, par exemple au moyen d’un special device ZFS en miroir.

Outre la technologie des disques, vous devez vérifier:

• l’endurance;
• la redondance;
• la protection contre la perte d’alimentation;
• les temps de reconstruction;
• la compatibilité avec le contrôleur;
• la disponibilité des pièces de rechange;
• la garantie et le support;
• les performances lors d’une restauration.

Toutes les infrastructures de sauvegarde ne nécessitent pas de NVMe. Une infrastructure avec une rétention étendue et des RTO peu contraignants peut utiliser des HDD Enterprise correctement dimensionnés. À l’inverse, de nombreux jobs simultanés et des restaurations fréquentes peuvent rendre insuffisant un stockage dimensionné uniquement en fonction de sa capacité.

Comment dimensionner le réseau

Le réseau détermine le volume de données pouvant être transféré dans la fenêtre disponible et le temps nécessaire à la restauration. Proxmox recommande des interfaces réseau redondantes multi-Gigabit pour les systèmes de production. La vitesse nécessaire doit toutefois être calculée en fonction du volume réel. Si vous devez transférer 2 TiB en huit heures, vous ne pouvez pas vous baser uniquement sur la vitesse nominale de la carte réseau. Vous devez prendre en compte:

• le débit réellement disponible;
• le trafic généré par les autres services;
• les jobs exécutés simultanément;
• la latence;
• la surcharge liée aux protocoles;
• les éventuelles synchronisations hors site;
• les restaurations susceptibles de se chevaucher avec les sauvegardes.

Dans les environnements complexes, il est recommandé de séparer le trafic de sauvegarde au moyen de VLAN ou de réseaux dédiés. Ainsi, les jobs PBS ne sont pas directement en concurrence avec les activités de production. Le réseau doit également être évalué dans le sens inverse. Terminer rapidement une sauvegarde ne suffit pas si une restauration complète nécessite un délai incompatible avec le RTO de l’entreprise.

Est-il possible de réutiliser un ancien serveur?

Un serveur déjà disponible peut être reconverti pour PBS s’il offre une capacité, une fiabilité et un niveau d’indépendance suffisants. Avant de le réutiliser, vous devez vérifier:

• l’âge et l’état des disques;
• les performances du contrôleur;
• la quantité maximale de RAM prise en charge;
• les interfaces réseau disponibles;
• la redondance des disques et des alimentations;
• les possibilités de gestion à distance;
• la consommation énergétique;
• la disponibilité des pièces de rechange;
• le support du fabricant;
• l’indépendance par rapport à l’infrastructure protégée.

Dans le projet réalisé pour Union Gas e Luce, certains serveurs existants ont été reconvertis pour Proxmox Backup Server et la reprise après sinistre. Cette réutilisation a été possible parce qu’elle s’inscrivait dans une évaluation globale de l’infrastructure, et non parce que n’importe quel ancien serveur convenait automatiquement.

Erreurs à éviter

Utiliser les prérequis minimaux en production
Les prérequis minimaux servent à installer et à évaluer PBS, et non à concevoir un système d’entreprise fiable.

Dimensionner le stockage sur la capacité nominale des VM
L’espace doit être estimé à partir des données réelles, du taux de modification et de la politique de rétention.

Tenir la déduplication pour acquise
Le résultat dépend de la nature des données et doit être mesuré.

Remplir le datastore jusqu’à sa limite
Il est nécessaire de conserver une marge pour la croissance, les variations imprévues et les opérations de maintenance.

Prendre en compte uniquement la vitesse de sauvegarde
La configuration doit également respecter le délai maximal acceptable pour la restauration.

Ignorer les jobs de maintenance
Les opérations de verify, pruning et garbage collection doivent disposer de ressources et de fenêtres opérationnelles adaptées.

Checklist avant de choisir le matériel

Avant de définir la configuration, rassemblez les informations suivantes:

• le nombre de VM, de conteneurs et d’hôtes;
• la quantité de données réellement protégées;
• le taux moyen de modification quotidienne;
• la politique de rétention requise;
• la croissance prévue;
• le nombre maximal de jobs simultanés;
• la fenêtre disponible pour les sauvegardes;
• les RPO et RTO;
• la fréquence des opérations de verify et de garbage collection;
• le délai maximal acceptable pour une restauration;
• la nécessité de disposer de copies distantes ou S3;
• les exigences de redondance;
• la durée de vie prévue de l’infrastructure;
• le niveau de support requis.

Ces informations permettent de passer des prérequis génériques de Proxmox à une configuration cohérente avec les services à protéger. Vous pouvez utiliser le configurateur AXOL Server pour décrire l’infrastructure existante, la capacité requise et les éventuels besoins en sauvegarde ou en reprise après sinistre.

Du prérequis minimal au projet réel

Les prérequis officiels constituent le point de départ. Le dimensionnement réel dépend en revanche des données, de la politique de rétention et du délai dans lequel l’entreprise doit pouvoir restaurer ses services. Une configuration correcte doit maintenir un équilibre entre:

• la capacité disponible;
• les performances du datastore;
• la puissance de traitement;
• la mémoire;
• la vitesse du réseau;
• la redondance;
• la croissance future;
• les délais de restauration.

En production, il est également recommandé d’évaluer l’accès au dépôt Enterprise et le niveau de support associé. Vous pouvez consulter les souscriptions Proxmox VE et Proxmox Backup Server disponibles via AXOL.

Combien de RAM faut-il pour Proxmox Backup Server?

Proxmox recommande au moins 4 GiB pour le système d’exploitation, le cache et les services, auxquels il faut ajouter au moins 1 GiB par TiB de stockage. Cette valeur doit être vérifiée en tenant compte de ZFS, de la croissance et des opérations simultanées.

Combien d’espace faut-il pour Proxmox Backup Server?
Cela dépend de la première sauvegarde réelle, des données uniques générées au fil du temps, de la politique de rétention, de la déduplication et de la croissance. Un test réalisé sur des données représentatives est plus fiable qu’un pourcentage standard.

Les SSD sont-ils obligatoires?
Non. Proxmox recommande les SSD Enterprise pour obtenir les meilleures performances, mais il est possible d’utiliser des HDD Enterprise lorsque la capacité, le cache des métadonnées et les fenêtres opérationnelles sont correctement dimensionnés.

Un réseau 10 GbE est-il nécessaire?
Pas dans tous les environnements. La vitesse doit être choisie en fonction du volume de données à transférer, de la fenêtre disponible et du délai requis pour la restauration.

Les prérequis minimaux sont-ils suffisants pour la production?
Non. Les prérequis minimaux publiés par Proxmox sont destinés exclusivement à l’évaluation du logiciel.