Niveaux RAID pour serveurs dédiés : 0, 1, 5, 10 et ZFS expliqués
Le RAID détermine deux choses pour votre serveur avant même qu'il ne démarre : quelle part du stockage que vous payez est réellement utilisable, et ce qui se passe au moment où un disque tombe en panne. Aucune des deux décisions n'est réversible sans reconstruire l'array, autant donc bien les prendre dès la commande. Ce guide explique les quatre niveaux qui comptent en pratique (0, 1, 5 et 10), ainsi que la vision de ZFS sur ces mêmes idées, avec des indications honnêtes sur le risque de reconstruction, ce contre quoi le RAID ne protège pas, et quel niveau convient à quelle charge de travail.
Loading...
La réponse d'abord
Pour les impatients, les choix par défaut qui conviennent à la plupart des charges de travail :
- Deux disques ? RAID 1 (mirror). La moitié de la capacité brute, survit à la panne d'un disque, simple à raisonner. La bonne réponse pour presque tous les serveurs à deux disques.
- Quatre disques ou plus, avec des bases de données ou des VM ? RAID 10. La moitié de la capacité, d'excellentes performances en écriture aléatoire, des reconstructions rapides et sans drame.
- Quatre disques ou plus, gourmand en capacité et à dominante lecture (médias, sauvegardes de sauvegardes, archives) ? RAID 5 vous offre le plus d'espace utilisable avec une protection contre la panne d'un disque, avec des réserves sur les reconstructions sur de gros disques, traitées honnêtement plus bas.
- RAID 0 uniquement pour des données dont vous pouvez vous permettre la perte instantanée : espace scratch, caches, artefacts de build reproductibles.
- ZFS est moins un cinquième niveau qu'une philosophie différente (checksums, auto-réparation, snapshots), à choisir dès lors que vous utiliserez ces fonctionnalités et pourrez nourrir son appétit pour la RAM.
Et la phrase qui devrait être tatouée sur chaque décision de stockage : le RAID, c'est de la disponibilité, pas une sauvegarde. Il maintient le serveur en fonctionnement lors de la panne d'un disque ; il réplique les suppressions, le ransomware et la corruption tout aussi fidèlement que vos données.
Ce que le RAID fait réellement
Le RAID (Redundant Array of Independent Disks) combine des disques physiques en un seul volume logique, en arbitrant entre capacité, performance et redondance. Trois mécanismes sous-tendent chaque niveau :
- Striping : les données sont réparties entre les disques de sorte que lectures et écritures sollicitent plusieurs disques à la fois (plus de vitesse, aucune protection).
- Mirroring : chaque bloc est écrit sur deux disques (protection complète, capacité divisée par deux).
- Parity : une redondance équivalente à un disque est calculée sur l'ensemble du stripe, de sorte que n'importe quel disque manquant peut être reconstruit (le plus de capacité, le mode de panne le plus habile, et le plus de petits caractères).
Chaque niveau utilisé en pratique est l'un de ceux-ci ou une combinaison :
| Level | Min drives | Usable capacity | Survives | Read perf | Write perf | Rebuild burden |
|---|---|---|---|---|---|---|
| RAID 0 (stripe) | 2 | 100 % | Rien : tout disque perdu = toutes les données perdues | Excellente | Excellente | n/a |
| RAID 1 (mirror) | 2 | Capacité d'1 disque | N−1 disques (par mirror) | Bonne (lit sur les deux) | Un disque | Légère : copie directe |
| RAID 5 (parity) | 3 | (N−1)/N | Un seul disque, n'importe lequel | Très bonne | Bonne en séquentiel, plus faible en aléatoire (mise à jour de parité) | Lourde : lit tous les disques |
| RAID 10 (mirror+stripe) | 4 | 50 % | Un par paire de mirror | Excellente | Très bonne | Légère : copie un seul mirror |
(La colonne capacité utilisable est exactement le calcul que notre configurateur affiche lorsque vous choisissez une variante RAID à la commande : RAID 1 donne la capacité d'un disque, RAID 5 donne tout sauf un, RAID 10 donne la moitié ; notre calculateur RAID effectue les mêmes calculs pour n'importe quel nombre et taille de disques, en To comme en Tio.)
Les niveaux, en toute honnêteté
RAID 0 : la vitesse sans ceinture de sécurité
Tout en striping, aucune redondance : la capacité et le débit de tous les disques combinés, et la probabilité de panne combinée aussi : la mort d'un seul disque emporte tout le volume avec lui. Ce n'est pas un cas limite rare ; sur une location de plusieurs années, c'est l'événement attendu. Les usages légitimes sont exactement ceux où la perte vous coûte une relance plutôt que des données : scratch de CI, résultats intermédiaires de rendu, caches éphémères. Si la phrase « on restaurera depuis la sauvegarde » fait grimacer quelqu'un dans votre entreprise, RAID 0 n'est pas fait pour ce jeu de données.
RAID 1 : le héros sans éclat
Deux disques, contenu identique. Vous perdez la moitié de votre capacité et gagnez le scénario de panne le plus simple qui soit : un disque meurt, le serveur ne bronche pas, vous remplacez le disque, le mirror se recopie. Les reconstructions sont douces (une copie linéaire depuis le disque sain) et, qualité sous-estimée, un seul disque survivant est une copie complète et lisible de vos données, pas une pièce de puzzle. Pour les disques d'OS et tout serveur à deux disques, c'est le choix par défaut, à juste titre.
RAID 5 : capacité maximale, petits caractères les plus sévères
Avec N disques, vous conservez (N−1)/N de l'espace et survivez à n'importe quelle panne isolée, sur le papier la meilleure offre du tableau. Les petits caractères concernent ce qui se passe après une panne :
- Les reconstructions lisent chaque octet de chaque disque survivant. Sur les gros disques d'aujourd'hui, c'est une longue fenêtre, souvent de plusieurs heures à plusieurs jours sur de grands HDD (bien plus courte en NVMe), durant laquelle l'array n'a plus aucune redondance et chaque disque restant subit une charge maximale et soutenue. Une seconde panne, ou un secteur illisible découvert en pleine reconstruction sur un disque vieillissant, met fin à l'histoire. Ce risque augmente avec la taille des disques, ce qui explique pourquoi la réputation du RAID 5 a mal vieilli avec les téraoctets.
- Chaque petite écriture paie une taxe de parité (lire les anciennes données, lire l'ancienne parité, calculer, écrire les deux), ce qui explique pourquoi les charges à forte écriture aléatoire (bases de données, stockage de VM très sollicité) ressentent le RAID 5 plus que ne le suggèrent les benchmarks de débit séquentiel.
Là où il garde toute sa place : les charges à dominante lecture et axées capacité sur des disques de taille modeste (ou du NVMe à reconstruction rapide), avec un monitoring qui alerte réellement dès la première panne et, comme toujours, de vraies sauvegardes. Si vous êtes tenté par le RAID 5 sur de très grands disques, c'est le moment d'envisager la double parité (RAID 6 / ZFS raidz2, quand disponible) ou de reconsidérer le RAID 10.
RAID 10 : ce que veulent les bases de données
Des paires en mirror, striped ensemble. Vous payez la taxe de 50 % de capacité du mirror et obtenez le meilleur profil opérationnel du groupe : des I/O aléatoires solides (aucun calcul de parité), les pannes ne dégradent qu'une seule paire, et les reconstructions copient un seul mirror plutôt que de mettre à mal tout l'array. Pour les bases de données, les hôtes de virtualisation, et tout ce qui est intensif en écriture où la prévisibilité des performances pendant les pannes compte, RAID 10 est le choix professionnel par défaut. Quatre disques à moitié capacité, c'est le prix à payer pour ne jamais connaître de reconstruction mouvementée.
ZFS : les mêmes questions, une philosophie différente
ZFS regroupe gestion de volumes et système de fichiers, et ses équivalents, les mirrors (≈RAID 1/10) et raidz1/raidz2 (≈RAID 5/6), ajoutent ce qui manque fondamentalement au RAID classique : des checksums de bout en bout. Le RAID classique fait confiance aux disques pour signaler leurs propres pannes ; ZFS vérifie chaque bloc à la lecture et, dans une configuration redondante, répare silencieusement la corruption à partir de la bonne copie (« auto-réparation »). En plus : des snapshots qui rendent le retour à un instant donné pratiquement gratuit, zfs send/receive pour une réplication efficace, et une compression transparente qui se rentabilise souvent d'elle-même.
Les coûts, tout aussi honnêtement : ZFS veut de la RAM (une base de quelques Go, plus pour le cache ; son ARC utilisera volontiers tout ce que vous lui donnez), ajoute de la charge conceptuelle (pools, vdevs, datasets), et ses variantes à parité partagent les caractéristiques d'écriture du RAID 5/6. Règles empiriques : mirrors pour les VM et les bases de données, raidz2 pour la capacité en masse, et c'est précisément la couche de stockage que Proxmox VE propose nativement, ce qui explique pourquoi le choix se pose dès l'installation de l'hyperviseur (voir notre guide d'installation de Proxmox).
RAID matériel, mdadm ou ZFS ?
Le niveau est une décision ; ce qui l'implémente en est une autre, avec de vraies conséquences à 3 h du matin :
- Les contrôleurs RAID matériels présentent l'array à l'OS comme un disque opaque unique. Avantage : indépendant de l'OS, simple au démarrage, cache en écriture différée avec sauvegarde batterie/flash. Inconvénient : le format de l'array est le secret du contrôleur (la récupération ou la migration demande généralement du matériel compatible) et le monitoring dépend d'outils du fournisseur que vous devez configurer vous-même.
- Linux mdadm (RAID logiciel) est transparent et portable : n'importe quelle machine Linux peut assembler l'array,
cat /proc/mdstatdit la vérité, et il n'y a aucune couche propriétaire entre vous et vos données. Les CPU modernes rendent l'argument de performance en faveur du RAID matériel largement historique (le calcul de parité est une erreur d'arrondi face au débit du NVMe). - ZFS : comme ci-dessus, quand ses fonctionnalités justifient leur surcoût.
Le résumé honnête : sur les serveurs NVMe modernes, le RAID logiciel (mdadm ou ZFS) est la recommandation par défaut pour la transparence et la portabilité ; le RAID matériel reste pertinent là où le support de l'OS, des contraintes de démarrage, ou une pratique opérationnelle existante le favorisent.
Choisir selon la charge de travail
| Workload | Pick | Why |
|---|---|---|
| OS / serveur général à deux disques | RAID 1 | Simplicité, panne avec copie complète |
| Bases de données, hôtes VM | RAID 10 (ou mirrors ZFS) | Performance en écriture aléatoire, reconstructions douces |
| Médias, archives, cibles de sauvegarde | RAID 5 / raidz2 | Efficacité de capacité là où l'écriture est en masse et la lecture domine |
| Scratch, caches, CI | RAID 0 | La perte se résume à une relance, la vitesse est l'objectif |
| « Je veux des snapshots/checksums » | Variante ZFS de ce qui précède | Fonctionnalités d'intégrité sur la même géométrie |
Deux disciplines à respecter pour finir, quel que soit votre choix. Surveillez l'array. Le mode de panne du RAID est une dégradation silencieuse : le premier disque meurt, rien de visible ne se produit pour l'utilisateur, et l'array tourne sans protection jusqu'à ce que quelqu'un le remarque (reliez les alertes mdadm/SMART/contrôleur à un humain). Et faites des sauvegardes. Le RAID répond à « un disque est mort » ; les sauvegardes répondent à tout le reste, de rm -rf au ransomware jusqu'à la panne de l'array lui-même. Dimensionnez le plan de sauvegarde avec le même sérieux que l'array (notre guide des stratégies de sauvegarde Proxmox couvre le cas de la virtualisation).
Questions fréquentes
Le RAID remplace-t-il les sauvegardes ?
Non, et autant être précis sur le pourquoi : le rôle du RAID est la disponibilité : le serveur continue de fonctionner quand un disque tombe en panne. Tout autre mode de perte de données le traverse sans obstacle : suppressions, bugs applicatifs, ransomware et corruption du système de fichiers sont répliqués sur tous les disques en quelques millisecondes, et une panne de contrôleur ou la mort d'un second disque peut emporter l'array entier. Les sauvegardes sont une copie ailleurs avec un historique ; le RAID est de la redondance sur place. Les données de production veulent les deux.
RAID 5 ou RAID 10 ?
Tranchez sur deux axes : le motif d'écriture et la tolérance à la reconstruction. Beaucoup d'écritures aléatoires (bases de données, stockage de VM) ou peu d'appétit pour de longues fenêtres dégradées → RAID 10. Capacité en masse à dominante lecture, où l'espace utilisable supplémentaire compte et où les disques sont de taille modeste ou en NVMe à reconstruction rapide → RAID 5 se défend. S'il s'agit de RAID 5 sur de très grands disques, considérez la double parité (RAID 6/raidz2) comme l'alternative sérieuse : la fenêtre de reconstruction à parité simple sur de gros disques est le risque le plus aigu de cet article.
Les disques NVMe rapides ont-ils encore besoin de RAID ?
Pour la redondance, oui. Le NVMe change la performance, pas la mortalité. La mémoire flash tombe en panne différemment des disques mécaniques (bugs de firmware, mort du contrôleur, usure), mais elle tombe bel et bien en panne, et sans redondance, une panne signifie une restauration depuis la sauvegarde avec l'interruption de service qui va avec. Ce que le NVMe change réellement, ce sont les compromis : les reconstructions se terminent en heures plutôt qu'en jours (ce qui atténue le plus gros inconvénient du RAID 5) et le coût CPU de la parité est négligeable, même si les mirrors restent le choix à la latence la plus prévisible.
Puis-je changer de niveau RAID plus tard ?
Pour la planification, partez du principe que la réponse est « non ». Certaines migrations sont techniquement possibles (mdadm peut reformer certains niveaux entre eux ; ZFS a récemment ajouté l'expansion raidz), mais ce sont des opérations lentes et risquées effectuées sur des données en production, exactement ce que vous voulez éviter. La voie réaliste est celle qui fonctionne partout : provisionner la nouvelle configuration, restaurer depuis la sauvegarde, basculer. C'est un argument pour passer cinq minutes sur le calcul de capacité avant de commander.
Déploiement chez Serverside
Notre configurateur de serveurs dédiés rend cette décision concrète : choisissez une variante RAID à la commande, et il affiche la capacité utilisable pour votre nombre exact de disques (le même calcul que dans le tableau ci-dessus), l'array étant livré déjà construit, si bien qu'il n'y a rien à assembler le premier jour. Les options NVMe maintiennent des fenêtres de reconstruction courtes, et si vous dimensionnez les disques et tout ce qui les entoure, notre guide de dimensionnement de serveur s'accorde naturellement avec celui-ci.
Lectures complémentaires : stratégies de sauvegarde Proxmox pour la moitié de l'histoire consacrée à « le RAID n'est pas une sauvegarde », et la checklist de durcissement de la première heure pour tout ce qui suit la décision de stockage.

Écrit par
CEO, Serverside.com & Host Havoc
Clay is the CEO of Serverside.com and Host Havoc, with more than a decade of experience running globally distributed hosting infrastructure and a game-server platform that has served over 200,000 customers.
Continuer la lecture
Voir tous les articlesCet article vous a plu ?
Recevez les nouveaux guides et articles techniques par e-mail. Sans spam, désinscription à tout moment.



