Calculateur ZFS / RAIDZ et stockage Proxmox Backup Server
Combien d'espace vous restera-t-il vraiment après la parité, l'arrondi de RAIDZ et la réserve de ZFS ? Et combien en consommera votre rétention de sauvegardes ? Deux calculs, avec la méthode d'OpenZFS affichée sous le résultat.
Le calcul se fait dans votre navigateur : aucune valeur saisie n'est envoyée.
Capacité utile d'un pool ZFS
Résultat
Capacité utile
28,98 Tio
31,86 To
À ne pas dépasser (80 %)
23,18 Tio
Rendement
66,4 %
6 disques au total
Pannes supportées
2 disques
| Capacité brute | 43,66 Tio |
| Parité ou copies | − 14,55 Tio |
| Perte de remplissage RAIDZ | 0 Gio |
| Réserve de ZFS (slop) | − 128 Gio |
| Capacité utile | 28,98 Tio |
Espace occupé par un datastore Proxmox Backup Server
Résultat
Espace consommé, rétention pleine
1,32 To à 5,28 To
17 points de restauration conservés
Datastore à prévoir (remplissage 80 %)
1,65 To à 6,6 To
Première sauvegarde complète
1 To
0 % de gain
Borne basse : ce sont chaque jour les mêmes morceaux qui changent. Borne haute : chaque jour touche des morceaux différents.
Reportez la borne haute dans le calculateur de pool ci-dessus pour choisir vos disques.
Comment le calcul est fait
Le calculateur reprend la règle d'allocation d'OpenZFS, et non la simple formule « (disques − parité) × taille ». Pour chaque bloc, RAIDZ écrit les secteurs de données, ajoute la parité de chaque ligne, puis arrondit le tout à un multiple de (parité + 1) secteurs. C'est la fonction vdev_raidz_psize_to_asize() du code source :
secteurs = ⌈ taille_bloc / 2^ashift ⌉
secteurs += parité × ⌈ secteurs / (largeur − parité) ⌉
secteurs = arrondi au multiple de (parité + 1)
rendement = secteurs de données / secteurs allouésZFS affiche l'espace d'un vdev RAIDZ en appliquant ce rendement à un bloc de référence de 128 Kio. C'est ce que fait le calculateur. Sur la plupart des largeurs, on retombe sur le rendement théorique : 66,7 % pour un RAIDZ2 de 6 disques, 80 % pour un RAIDZ1 de 5 disques. Sur d'autres, l'arrondi coûte de la place : un RAIDZ2 de 10 disques rend 76,2 % au lieu de 80 %, un RAIDZ3 de 8 disques 57,1 % au lieu de 62,5 %.
Vient ensuite la réserve que ZFS garde pour ses propres écritures, le slop space : 1/32 du pool (paramètre spa_slop_shift = 5), au moins 128 Mio et au plus 128 Gio. Enfin, la capacité « à ne pas dépasser » applique votre taux de remplissage visé. Au-delà de 80 %, l'allocateur cherche plus longtemps des blocs libres et les écritures ralentissent : c'est une règle d'usage, pas une limite dure.
Sources : vdev_raidz.c (OpenZFS), paramètre spa_slop_shift (documentation OpenZFS).
L'espace d'un datastore Proxmox Backup Server
Proxmox Backup Server découpe chaque sauvegarde en morceaux et ne stocke qu'une fois un morceau déjà connu. Un datastore contient donc la première sauvegarde complète, puis les morceaux nouveaux de chaque point de restauration conservé. Le second calculateur en déduit une fourchette :
plein = volume × (1 − gain)
borne basse = plein × (1 + (points − 1) × morceaux_modifiés_jour)
borne haute = plein × (1 + Σ min(1, écart_jours × morceaux_modifiés_jour))
écart = 1 jour (daily), 7 jours (weekly), 30 jours (monthly)Le taux à saisir n'est pas la part des données modifiées, mais la part des morceaux touchés par au moins une écriture (4 Mio par défaut). La nuance est décisive pour une base de données : sur notre banc de sauvegarde MariaDB, des mises à jour dispersées sur une ligne sur cent ont donné 0 % de déduplication, car chaque morceau contenait une modification. Regroupées, les mêmes mises à jour dédupliquent bien. La borne basse correspond au cas où ce sont chaque jour les mêmes morceaux qui changent, la borne haute à celui où chaque jour touche des morceaux différents, comme un serveur de fichiers qui reçoit des fichiers nouveaux. Votre réalité est entre les deux. Les options keep-daily, keep-weekly et keep-monthly sont celles de la rétention de PBS. Le calcul les additionne sans chevauchement, ce qui surestime légèrement : c'est voulu.
Les repères de gain viennent de nos mesures publiées, pas d'une moyenne du marché. Le premier backup d'un serveur Windows de 1 To a transmis 374 Go pour 876 Go sauvegardés, soit 57 % d'économie. Sur notre base MariaDB de séries temporelles, la méthode recommandée pour sauvegarder MariaDB vers Proxmox Backup Server, un dump SQL, a réduit le premier backup de 86 % (29,73 Gio → 4,3 Gio). Une copie physique des fichiers fait moins bien, 79 % (45 Gio → 9,6 Gio), car elle emporte les index et l'espace libre des fichiers. Aux backups suivants, sept heures plus tard, 99,15 % des morceaux de 4 Mo étaient déjà présents : c'est un repère sur 7 heures, pour une base surtout alimentée par des ajouts, pas un taux par jour. D'où le « jusqu'à » : une base très active dédupliquera moins. Partez de 0 % et ajustez après une première sauvegarde réelle.
Après le calcul
Un pool ZFS local protège contre la panne d'un disque, pas contre la perte du serveur, un incendie ou un rançongiciel. La copie suivante doit partir ailleurs. Pour un NAS, voyez la sauvegarde TrueNAS externalisée. Pour un cluster Proxmox VE, la sauvegarde Proxmox externalisée envoie les sauvegardes vers un datastore PBS opéré en France. Et pour sortir une copie du réseau, nous avons documenté comment mettre un datastore PBS hors ligne avec zfs send.
Une fois le volume connu, reste la durée : le premier envoi et l'incrémental quotidien tiennent-ils dans votre lien ? Le calculateur de fenêtre de sauvegarde répond pour un envoi vers Nimbus. Si le lien est loin, notre calculateur de débit TCP montre ce que la latence retire à une réplication. Et si vos disques passent par un contrôleur matériel plutôt que par ZFS, le calculateur RAID couvre les niveaux 5, 6, 10, 50 et 60.
Si vous préférez confier le dimensionnement et l'exploitation de vos pools ZFS, c'est le métier de notre infogérance Proxmox.
Questions fréquentes
Combien d'espace utile donne un RAIDZ2 de 6 disques ?
Quatre disques sur six, soit 66,7 % de la capacité brute, moins la réserve de ZFS (1/32 du pool, plafonnée à 128 Gio). Avec six disques de 8 To, le pool affiche environ 29 Tio, et 28,98 Tio restent réellement utilisables. Pour garder de bonnes performances d'écriture, visez 80 % de remplissage, soit environ 23 Tio.
Pourquoi mon pool RAIDZ affiche-t-il moins que (disques − parité) × taille ?
Pour trois raisons. Les disques sont vendus en To décimaux (10¹² octets) et ZFS affiche des Tio binaires (2⁴⁰ octets) : 8 To font 7,28 Tio. RAIDZ arrondit chaque bloc à un multiple de (parité + 1) secteurs, ce qui coûte de la place sur certaines largeurs, par exemple 3,8 points sur un RAIDZ2 de 10 disques. Enfin, ZFS garde une réserve (slop) de 1/32 du pool, au plus 128 Gio.
Miroir ou RAIDZ pour des machines virtuelles Proxmox ?
Pour des VM, un pool de miroirs est souvent le meilleur choix : chaque miroir ajoute des IOPS, la reconstruction ne relit qu'un disque, et les petits blocs des zvols ne subissent pas l'arrondi de RAIDZ. RAIDZ2 convient mieux au stockage de gros fichiers et aux datastores de sauvegarde, où la capacité compte plus que les IOPS.
Quelle place prévoir pour un datastore Proxmox Backup Server ?
La première sauvegarde complète, puis, pour chaque point de restauration conservé, les blocs qui ont changé depuis le point précédent. Le calculateur donne une fourchette : la borne basse suppose que ce sont chaque jour les mêmes morceaux qui changent, la borne haute que chaque jour touche des morceaux différents. Le taux à saisir est la part des morceaux modifiés, pas la part des données : des mises à jour dispersées sur 1 % des lignes peuvent toucher presque tous les morceaux. Prévoyez ensuite 20 % de marge pour le remplissage et le ramasse-miettes de PBS.
Les gains de déduplication affichés sont-ils garantis ?
Non. Ce sont des mesures publiées sur nos propres données, à titre de repère : 57 % au premier backup d'un serveur de fichiers Windows de 876 Go, et, sur une base MariaDB en série temporelle, jusqu'à 86 % au premier backup d'un dump SQL et 79 % au premier passage d'une copie physique des fichiers. Un autre jeu de données donnera un autre résultat. Pour dimensionner sans surprise, partez de 0 % et ajustez après une première sauvegarde réelle.
Contact
Adresse
5 B RUE DES NOYERS, 95300 PONTOISE, FRANCE