RAID, ZFS, DRBD ou Ceph :
ce que chacun apporte, ce qu'il coûte
Ces quatre technologies sont souvent comparées comme si elles répondaient à la même question. Ce n'est pas le cas : chacune absorbe une panne différente, se paie dans une monnaie différente — disques, serveurs, réseau, heures d'exploitation — et certaines se cumulent quand d'autres se contrarient.
Sommaire
1. Trois niveaux de panne, pas quatre concurrents
La bonne question n'est pas « lequel est le meilleur ? » mais « qu'est-ce qui peut tomber sans que le service s'arrête ? ». Posée ainsi, la comparaison se range d'elle-même.
| Technologie | Ce qui peut tomber | Serveurs au minimum |
|---|---|---|
| RAID, ZFS en miroir ou RAIDZ | Un disque (deux en RAID 6 / RAIDZ2) | 1 |
| Réplication ZFS | Un serveur, en perdant les écritures faites depuis la dernière copie | 2, plus un arbitre |
| DRBD synchrone | Un serveur, sans perte d'écriture confirmée | 2, plus un arbitre |
| Ceph | Un disque, un serveur, voire une baie selon le placement des copies | 3, plutôt 4 ou 5 |
Aucune des quatre n'est une sauvegarde
Toutes recopient fidèlement ce qu'on leur écrit, y compris une suppression, une table vidée par erreur ou des fichiers chiffrés par un rançongiciel. La redondance protège contre le matériel qui casse, pas contre l'écriture qui abîme. Pour cela, il faut une copie séparée, versionnée et hors d'atteinte : c'est le rôle de la sauvegarde externalisée de vos VM Proxmox, un sujet distinct de celui-ci.
2. RAID : protéger les disques d'un serveur
Le RAID répartit les données sur plusieurs disques d'une même machine pour qu'un disque mort ne l'arrête pas. Il le fait par un contrôleur matériel ou en logiciel (mdadm sous Linux). C'est le socle de presque tous les serveurs, et c'est aussi celui qu'on surestime le plus : il protège les disques, pas le serveur. Pour comparer la capacité utile des différents niveaux, notre calculateur RAID fait le calcul pour votre nombre et votre taille de disques.
Ce qu'il apporte
- • La perte d'un disque (deux en RAID 6) sans arrêt ni intervention immédiate
- • Aucune dépendance au réseau : tout se passe dans la machine
- • Transparent pour le système et les applications
- • De bonnes performances en RAID 10, disques au plus près du processeur
- • Une technologie mûre, bien outillée, connue de tous les administrateurs
Ce qu'il coûte
- • La moitié de la capacité en RAID 1 et 10, deux disques en RAID 6
- • Carte mère, alimentation, contrôleur et serveur restent des points de panne uniques
- • Des reconstructions de plusieurs heures sur les gros disques : un RAID 5 y est exposé à une seconde panne, d'où le RAID 6 au-delà de quelques téraoctets
- • En RAID matériel, une dépendance au contrôleur : relire les disques demande un modèle compatible, et le cache d'écriture dépend de sa batterie
3. ZFS : vérifier ce qu'on relit, et répliquer
ZFS joue deux rôles qu'il faut distinguer. Dans un serveur, il remplace le RAID : miroir ou RAIDZ, géré par le système de fichiers lui-même, sans contrôleur. Entre deux serveurs, il sait envoyer les modifications d'un disque vers un autre nœud, et c'est sur ce mécanisme que repose la réplication de stockage de Proxmox VE. Pour dimensionner un pool, notre calculateur de capacité ZFS et d'espace PBS donne la capacité utile selon la topologie choisie.
En local : un RAID qui sait ce qu'il relit
Ce qu'il apporte
- • Chaque bloc porte une somme de contrôle : une donnée altérée sur un disque est détectée à la lecture et réparée depuis l'autre copie, là où un RAID classique ne voit rien
- • Des instantanés quasi gratuits, pratiques avant une mise à jour
- • La compression à la volée, qui regagne souvent une partie de l'espace
- • Plus de contrôleur RAID propriétaire : les disques se relisent sur n'importe quel serveur
Ce qu'il coûte
- • De la mémoire vive pour son cache : à l'installation, Proxmox VE lui réserve 10 % de la RAM, plafonnés à 16 Gio, à arbitrer avec les VM
- • Des disques en accès direct : pas de contrôleur RAID avec son propre cache en dessous
- • Des performances qui se dégradent quand le pool approche du plein
- • Un RAIDZ qui s'agrandit disque par disque seulement depuis OpenZFS 2.3 ; en miroir, on ajoute des paires
Entre deux serveurs : la réplication planifiée
Proxmox VE copie les disques des machines virtuelles vers un autre nœud à intervalle régulier : toutes les quinze minutes par défaut sous Proxmox VE, et la planification, au format cron, descend dès une minute ou s'espace jusqu'à une fois par semaine. Si le nœud tombe, la machine redémarre sur l'autre depuis la dernière copie. C'est asynchrone : les écritures faites depuis cette copie sont perdues, soit jusqu'à un intervalle entier — un quart d'heure avec le réglage par défaut, une journée ou une semaine si la réplication est quotidienne ou hebdomadaire. Les écritures, elles, restent locales et ne paient aucune latence réseau.
Deux serveurs et un petit arbitre suffisent, sans réseau de stockage dédié. C'est le meilleur rapport entre ce qu'on protège et ce qu'on paie pour beaucoup de PME, à condition d'accepter cette fenêtre de perte ; nous détaillons ce compromis dans le cas sans stockage partagé.
4. DRBD : un miroir de disques entre deux serveurs
DRBD fait entre deux machines ce que le RAID 1 fait entre deux disques : chaque écriture est envoyée à l'autre serveur. En mode synchrone (le « protocole C »), elle n'est confirmée à l'application qu'une fois écrite des deux côtés. Si le serveur actif tombe, l'autre dispose de toutes les écritures confirmées, et un gestionnaire de cluster comme Pacemaker y redémarre le service.
Ce qu'il apporte
- • Aucune écriture confirmée perdue quand un serveur tombe, en mode synchrone
- • Deux serveurs suffisent, plus un témoin léger pour le quorum
- • Des lectures sur disques locaux, aussi rapides qu'en local
- • Des serveurs standards, sans baie de stockage partagée
- • Un mode asynchrone pour répliquer vers un site distant
Ce qu'il coûte
- • Un risque de split-brain : sans isolation (fencing) ni quorum, les deux nœuds peuvent écrire chacun de leur côté
- • Chaque écriture attend l'aller-retour réseau : un lien dédié, rapide et court est indispensable
- • Un fonctionnement actif/passif en pratique ; le double primaire exige un système de fichiers de cluster
- • Une bascule qui redémarre le service : l'arrêt est court, mais réel
- • Sous Proxmox VE, pas d'intégration native : il passe par le plugin LINSTOR de LINBIT
Le coût en latence est le point qui décide. Il devient vite rédhibitoire dès que les deux serveurs s'éloignent ; nous le chiffrons écriture par écriture dans la contrainte de latence des réplications synchrones.
5. Ceph : un stockage réparti qui se répare seul
Ceph agrège les disques de plusieurs serveurs en un seul stockage, et place chaque donnée en plusieurs exemplaires sur des serveurs différents — trois par défaut. Quand un disque ou un nœud disparaît, le cluster recrée seul les copies manquantes ailleurs. Proxmox VE l'intègre directement, interface comprise, ce qui en fait le stockage partagé naturel d'un cluster d'hyperviseurs.
Ce qu'il apporte
- • Aucun point de panne unique : disque, serveur, et même baie ou salle si les copies y sont réparties
- • Une réparation automatique, répartie sur tout le cluster
- • Un stockage partagé : les VM migrent à chaud sans copier leurs disques, et redémarrent sur n'importe quel nœud
- • Une croissance au fil de l'eau, en ajoutant des disques ou des serveurs
- • Du bloc, du fichier (CephFS) et de l'objet compatible S3 depuis un même cluster
Ce qu'il coûte
- • Trois serveurs au strict minimum ; à trois, la perte d'un nœud laisse le cluster sans place pour se réparer, d'où 4 ou 5 en pratique
- • Un tiers de la capacité brute avec trois copies, et moins encore en gardant de quoi absorber un nœud perdu ; l'alerte de remplissage tombe à 85 %
- • Un réseau dédié d'au moins 10 Gbit/s, davantage avec des disques NVMe
- • Une latence d'écriture supérieure au disque local, sensible pour les bases très transactionnelles
- • Du matériel choisi : SSD avec protection contre les coupures, 4 Gio de RAM par disque par défaut et 8 recommandés, un HBA plutôt qu'un contrôleur RAID
- • Une exploitation exigeante : placement des données, reconstructions, montées de version
6. Ce que chacun apporte, ce qu'il coûte
| Ce que ça apporte | Capacité utile | Matériel | Écritures | Exploitation | |
|---|---|---|---|---|---|
| RAID 1 / 10 | Perte d'un disque | 50 % | 1 serveur | Locales | Faible |
| RAID 6 | Perte de deux disques | (n−2)/n | 1 serveur | Pénalisées | Faible, reconstructions longues |
| ZFS miroir / RAIDZ2 | Perte d'un ou deux disques, et détection des données altérées | 50 % / (n−2)/n | 1 serveur, RAM pour le cache | Locales | Faible |
| Réplication ZFS | Perte d'un serveur, moins les écritures depuis la dernière copie (de 1 min à 1 semaine selon l'intervalle) | 25 % (miroir sur deux nœuds) | 2 serveurs + arbitre | Locales | Faible, intégrée à Proxmox |
| DRBD sur RAID 1 | Perte d'un serveur, sans perte d'écriture confirmée | 25 % | 2 serveurs + arbitre, lien dédié | Attendent le réseau | Moyenne : fencing et quorum |
| Ceph, trois copies | Perte d'un disque ou d'un serveur, réparation automatique, migration à chaud | 33 %, moins la marge | 4 à 5 serveurs, réseau 10/25 Gbit/s | Attendent trois copies | Élevée |
Les pourcentages de capacité sont de l'arithmétique sur la capacité brute totale, pas des mesures. Chaque ligne coûte plus que la précédente, en matériel comme en exploitation : la seule façon de savoir laquelle se justifie est de la rapporter au prix d'une heure d'arrêt et au volume de données que vous acceptez de perdre.
7. Lesquels se cumulent
| Combinaison | Verdict | Pourquoi |
|---|---|---|
| ZFS en miroir + réplication ZFS | Oui | Le montage type d'une PME : chaque nœud survit à un disque, l'ensemble survit à un nœud |
| RAID 1 + DRBD | Oui | L'usage classique : le RAID couvre le disque, DRBD couvre le serveur, et un disque mort ne déclenche pas de bascule |
| RAID 1 pour le système des nœuds Ceph | Oui | Les disques système ne portent pas de données Ceph : aucune objection |
| Ceph sur des grappes RAID | Non | Voir ci-dessous |
| ZFS sur un RAID matériel | Non | ZFS voit un seul disque : il détecte une donnée altérée mais n'a plus de copie pour la réparer, et le cache du contrôleur fausse ses garanties d'écriture |
| DRBD + Ceph | Sans objet | Les deux répliquent entre serveurs : on paierait deux fois la même protection |
Ceph sur des grappes RAID 1 : une fausse bonne idée
C'est l'erreur la plus fréquente des premiers déploiements, et la documentation de Proxmox VE la déconseille en toutes lettres : Ceph gère lui-même la redondance, un contrôleur RAID n'améliore ni les performances ni la disponibilité.
- • La redondance se paie deux fois. Trois copies Ceph sur des disques en RAID 1, c'est six exemplaires de chaque donnée : un sixième de la capacité brute reste utile, moins la marge. Le même budget disques, en accès direct, stocke deux fois plus.
- • Ceph ne voit plus les disques. C'est lui qui repère un disque défaillant, l'écarte et recrée les copies ailleurs. Derrière un contrôleur, il voit un volume « sain » pendant qu'un disque se dégrade, et la réparation répartie sur tout le cluster devient une reconstruction RAID lente dans une seule machine.
- • Le cache du contrôleur fausse les garanties. Ceph considère qu'une écriture confirmée est sur disque. Avec un cache d'écriture dont la batterie est usée, une coupure peut perdre des écritures que Ceph a déjà confirmées aux machines virtuelles.
- • Deux réparations se marchent dessus. Pendant une reconstruction RAID, le disque Ceph concerné reste en service mais lent, et ralentit tout le cluster sans que Ceph sache pourquoi.
- • La variante « RAID 1 dessous, deux copies Ceph dessus » est pire. Avec deux copies, la perte d'un nœud oblige à choisir entre bloquer les écritures ou accepter de n'avoir plus qu'une copie, ce que la documentation de Proxmox VE proscrit : une panne de plus et la donnée est perdue.
La bonne pratique : un adaptateur HBA, ou un contrôleur passé en mode HBA (« IT »), avec les disques présentés tels quels. Sur un contrôleur qui ne le permet pas, le contournement habituel est un RAID 0 par disque, cache désactivé — faute de mieux, pas par choix.
8. Ce que nous recommandons selon le cas
Un serveur, pas de haute disponibilité
ZFS en miroir plutôt qu'un RAID matériel : les disques restent relisibles ailleurs et les données altérées sont détectées. La sauvegarde externalisée fait le reste.
Deux serveurs, quelques minutes de perte acceptables
ZFS en miroir sur chaque nœud, réplication ZFS entre les deux, un arbitre léger pour le quorum. C'est la configuration la plus économique qui survive à la perte d'un serveur.
Deux serveurs, aucune écriture confirmée ne doit être perdue
DRBD synchrone sur RAID 1, piloté par Pacemaker, sur un lien dédié entre deux serveurs proches. Pour une base de données seule, une réplication au niveau du moteur est souvent plus adaptée : elle ne paie la latence qu'à la validation des transactions.
Un cluster de virtualisation qui grandit
Ceph, à partir de quatre ou cinq nœuds, avec un réseau de stockage dédié et des disques en accès direct. C'est l'option qui demande le plus d'exploitation, et celle qui en rend le plus : migrations à chaud, réparation automatique, croissance sans refonte.
Le bon niveau dépend de ce que coûte un arrêt chez vous, pas de la technologie la plus complète. Commencez par l'ordre de grandeur que donne notre calculateur de coût d'indisponibilité : c'est lui qui dit si le troisième serveur, ou le réseau 25 Gbit/s, se rentabilise.
Questions fréquentes
Le RAID suffit-il pour de la haute disponibilité ?
Non. Le RAID protège les disques d'un serveur, pas le serveur lui-même : une alimentation, une carte mère ou un contrôleur qui lâche arrête la machine, quel que soit le niveau de RAID. La haute disponibilité commence quand les données existent aussi sur un deuxième serveur, par réplication ZFS, DRBD ou Ceph.
ZFS remplace-t-il un contrôleur RAID ?
Oui, et il apporte davantage : chaque bloc porte une somme de contrôle, ce qui permet de détecter et de réparer une donnée altérée qu'un RAID classique relirait sans rien voir. En échange, ZFS veut les disques en accès direct, sans contrôleur RAID avec son propre cache en dessous, et de la mémoire vive pour son cache.
Combien de serveurs faut-il pour Ceph ?
Trois au strict minimum, c'est ce que demande Proxmox VE. Mais à trois serveurs et trois copies, la perte d'un nœud laisse le cluster sans endroit où recréer la copie manquante : il continue de fonctionner, en mode dégradé, jusqu'au retour du nœud. À partir de quatre ou cinq serveurs, il se répare seul. En dessous de trois, la réplication ZFS ou DRBD est plus adaptée.
Peut-on installer Ceph sur des disques en RAID ?
Techniquement oui, mais c'est une erreur. Ceph gère lui-même la redondance : sur du RAID 1, chaque donnée existe en six exemplaires, Ceph ne voit plus l'état réel des disques, et le cache du contrôleur peut perdre des écritures que Ceph croit déjà sur disque. La documentation de Proxmox VE le déconseille explicitement. Il faut un HBA et des disques en accès direct.
DRBD ou réplication ZFS : lequel choisir sur deux serveurs ?
Tout dépend des données que vous acceptez de perdre. La réplication ZFS est asynchrone : simple, sans pénalité sur les écritures, mais une panne fait perdre ce qui a été écrit depuis la dernière copie : jusqu'à quinze minutes avec le réglage par défaut de Proxmox VE, davantage si la réplication est quotidienne ou hebdomadaire. DRBD synchrone ne perd aucune écriture confirmée, au prix d'une latence réseau sur chaque écriture et d'une mise en œuvre plus exigeante, avec fencing et quorum.
Un stockage redondant dispense-t-il de sauvegarde ?
Non. RAID, ZFS, DRBD et Ceph recopient fidèlement tout ce qu'on leur écrit, y compris une suppression ou des fichiers chiffrés par un rançongiciel. Ils protègent contre le matériel qui casse. Contre l'erreur et l'attaque, seule une copie séparée, versionnée et hors d'atteinte permet de revenir en arrière.
Votre stockage survivrait-il à la perte d'un serveur ?
Nous auditons l'existant, nous identifions ce qui est vraiment redondant et ce qui ne l'est pas, et nous chiffrons le niveau qui correspond à votre coût d'arrêt.
Demander un devisÀ lire aussi
Les 4 architectures de haute disponibilité
Ce que nous déployons, de 4 h à 10 s de bascule
Panne d'hyperviseur
Quorum, stockage partagé, fencing : relancer les VM en 5 min
Cluster de service : keepalived ou Pacemaker
Faire basculer le service, et pas seulement la machine
Le plan de reprise avec Proxmox
Ceph étiré sur deux sites, objectifs de reprise
Sources
Les recommandations matérielles et les valeurs par défaut citées sur cette page viennent des documentations primaires suivantes. Liens consultés le 29 septembre 2026.
- [1] Proxmox VE — déployer un cluster Ceph hyperconvergé (nombre de nœuds, réseau, mémoire par OSD, RAID déconseillé, min_size)
- [2] Proxmox VE — ZFS on Linux (disques en accès direct, cache ARC)
- [3] Proxmox VE — réplication du stockage (intervalles de réplication)
- [4] OpenZFS 2.3.0 — notes de version (extension RAIDZ)
- [5] LINBIT — guide utilisateur DRBD 9 (protocole C, arbitre de quorum)
- [6] LINBIT — guide utilisateur LINSTOR (plugin Proxmox VE)