RAID 10 pour VPS : fonctionnement et avantages

Ce qu’est le RAID 10 et pourquoi les hébergeurs de VPS l’utilisent

Le RAID 10 est la configuration de stockage la plus utilisée par les hébergeurs de VPS avec des disques NVMe (non-volatile memory express) virtualisés. Il met chaque disque en miroir avec un disque partenaire, puis répartit les données entre ces paires en miroir. Un disque peut tomber en panne sans arrêter l’array. Sa reconstruction consiste à effectuer une simple copie depuis le disque partenaire encore disponible, au lieu de recalculer les données en lisant tous les autres disques de l’ensemble.

RAID signifie redundant array of independent disks. Son seul objectif est de maintenir la machine en service lorsqu’un disque est hors service ou en cours de remplacement. Cet objectif relève de la disponibilité, et la disponibilité ne garantit pas la sécurité.

Le RAID réplique vos écritures. rm -rf /srv est une écriture. Les deux moitiés du miroir suppriment le répertoire dans la même milliseconde, et l’array continue ensuite d’indiquer qu’il est sain.

Gardez cette phrase. Le reste de cette page explique ce que chaque niveau permet de supporter et ce que chacun vous coûte à chaque écriture. Les dernières sections présentent les commandes permettant de consulter l’état d’un array sur une machine qui vous appartient, ainsi que la défaillance que le RAID n’a jamais couverte.

Les niveaux qu’un client d’hébergement rencontre réellement : 1, 5, 6 et 10

Une page de forfait indique un numéro, puis s’arrête là. Ce numéro répond à deux questions : combien de disques peuvent tomber en panne et quel est le coût de chaque écriture.

RAID 1 est un miroir. Deux disques contiennent des blocs identiques. Chaque écriture est envoyée aux deux disques. L’un ou l’autre peut répondre à une lecture. Un disque peut tomber en panne sans perte de données, et la moitié de la capacité brute est utilisable. Il n’y a aucun calcul de parité, donc le chemin d’écriture est court.

RAID 5 répartit les données avec un bloc de parité par stripe. Avec n disques, vous obtenez la capacité de n-1 disques, et l’array résiste exactement à une panne. La parité n’est pas stockée sur un disque dédié. Elle tourne sur l’ensemble des disques, qui contiennent donc tous à la fois des données et de la parité.

RAID 6 ajoute un second bloc de parité indépendant à chaque stripe, généralement nommé P et Q. Il résiste à la panne simultanée de deux disques. Cela compte davantage qu’il n’y paraît, car la seconde panne survient le plus souvent pendant la réparation de la première.

RAID 10 est une stripe de miroirs. Les disques sont regroupés en paires miroir, puis les données sont réparties entre ces paires. La capacité utilisable correspond à la moitié du total brut, comme avec RAID 1, avec en plus le parallélisme de la répartition en stripe.

Vous le verrez aussi écrit RAID 1+0, ce qui est la description correcte : créer d’abord les miroirs, puis répartir les données entre eux. RAID 0+1 applique l’ordre inverse : créer d’abord les deux stripes, puis les mettre en miroir. Cette configuration est moins robuste, car la panne d’un seul disque met toute une stripe hors service et la réparation doit copier l’intégralité de l’autre côté.

Linux constitue un cas particulier qu’il faut connaître. Le raid10 du kernel est une seule personality et non deux couches empilées. Il fonctionne donc avec un nombre impair de disques et propose des layouts (near, far, offset) qu’une configuration imbriquée ne peut pas exprimer. C’est pourquoi la ligne d’état d’un système Linux indique 2 near-copies au lieu de nommer deux arrays.

[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

Huit disques de 1 TB fournissent 7 TB d’espace utilisable en RAID 5 et 4 TB en RAID 10. Cette différence représente un coût réel, ce qui explique pourquoi la parité est si souvent proposée. RAID 6 résiste à 2 pannes, quelle que soit leur combinaison. RAID 10 en garantit seulement 1, car la seconde panne critique est celle qui touche le disque associé à celui qui est déjà tombé en panne. Il peut résister jusqu’à 4 pannes lorsqu’aucune paire ne subit deux pannes, mais cela relève de la chance et non d’une propriété de conception.

Ce que coûte chaque niveau à chaque écriture

Une écriture sur un miroir correspond à deux écritures, envoyées simultanément aux deux membres. Une écriture sur une stripe avec parité demande davantage de travail, car le bloc de parité de cette stripe n’est plus valide et doit être recalculé.

Le contrôleur ne peut pas recalculer la parité à partir du seul nouveau bloc. Il doit d’abord lire l’ancien bloc de données et l’ancien bloc de parité. Une petite écriture aléatoire sur RAID 5 devient donc une lecture, une lecture, une écriture, une écriture. RAID 6 doit gérer un second syndrome, si bien que la même écriture devient une lecture, une lecture, une lecture, une écriture, une écriture, une écriture.

[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

Une petite écriture aléatoire coûte 6 opérations sur les disques avec RAID 6, contre 2 avec RAID 10. Ces chiffres sous-estiment l’écart de latence. Les deux écritures du miroir sont lancées en parallèle : la machine virtuelle attend donc la plus lente des deux. Le chemin avec parité comprend une lecture qui doit se terminer avant le calcul de la nouvelle parité. La machine virtuelle attend donc d’abord une lecture, puis une écriture. Sur un hôte chargé, cette lecture attend derrière les entrées-sorties des autres utilisateurs.

Il existe une exception importante. Une écriture assez grande pour remplir une stripe entière n’a pas besoin des anciennes données, car chaque bloc de la stripe est remplacé. La parité est calculée à partir des données déjà présentes en mémoire, et le coût se limite à une écriture supplémentaire. C’est pourquoi RAID 5 donne de bons résultats dans un benchmark séquentiel, mais se comporte mal avec une charge mixte composée de petites écritures provenant de nombreux tenants. Testez le profil que vous utilisez réellement : évaluer correctement les performances du disque d’un VPS signifie mesurer des entrées-sorties aléatoires avec une profondeur de file réaliste, et non un seul gros dd.

Pourquoi la reconstruction est la partie dangereuse

Une reconstruction de parité doit recréer le disque manquant à partir de tous les autres. Elle lit donc les 7 disques encore disponibles, du premier bloc au dernier. Une reconstruction RAID 10 n’en lit que 1 : le miroir du disque défaillant, et rien d’autre.

Deux coûts en découlent. Le premier est le temps. La reconstruction est limitée par le disque encore disponible le plus lent, ainsi que par les calculs de parité. Le second est la charge. Tous les disques d’un ensemble de parité travaillent pendant toute la durée de l’opération. Toutes les VM de ce nœud subissent donc une latence plus élevée jusqu’à la fin de la reconstruction. En RAID 10, une seule paire travaille. Les autres paires continuent à fournir leur débit normal.

Cette période comporte aussi un risque d’intégrité. Un array RAID 5 dont un disque est défaillant n’a plus aucune redondance. Un secteur illisible n’importe où sur un disque encore disponible devient donc irrécupérable. La reconstruction est la seule opération qui lit chaque secteur, y compris ceux auxquels personne n’a accédé depuis un an. Les fiches techniques publiées indiquent qu’un disque dur grand public peut rencontrer environ une erreur de lecture irrécupérable pour 10^14 bits lus, contre une erreur pour 10^17 bits lus ou moins pour un disque NVMe enterprise. Il s’agit de spécifications constructeur, pas de mesures. Le rapport explique toutefois pourquoi l’ancien avertissement selon lequel une reconstruction RAID 5 échouerait concernait surtout les grands disques mécaniques, et pourquoi il est beaucoup moins pertinent avec le NVMe. L’argument lié à la charge reste valable quel que soit le support.

Détectez les erreurs latentes avant qu’une reconstruction ne les révèle, en effectuant un scrub. Debian et Ubuntu fournissent un scrub périodique pour les arrays md. Le mécanisme varie selon les releases. Vérifiez donc lequel est installé, puis lancez manuellement une passe.

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

sync_action revient à idle lorsque la passe est terminée, et mismatch_cnt doit afficher 0. Une valeur supérieure à zéro sur un miroir indique que ses deux moitiés ne correspondent pas. Le kernel ne peut pas déterminer laquelle est correcte, car aucune copie ne contient de checksum. Certains écarts sont sans conséquence. Les partitions swap en sont la cause la plus courante : le kernel peut écrire une page pendant qu’elle est modifiée. Un compteur qui augmente sur un array de données indique qu’un disque doit être remplacé.

Pourquoi les fournisseurs de VPS standardisent le RAID 10 pour le NVMe

Un nœud d’hyperviseur n’exécute pas une seule charge de travail. Il héberge des dizaines de guests indépendants, dont les opérations d’I/O arrivent en flux entremêlé de petites écritures, sans localité entre elles. C’est exactement le cas où le cycle read-modify-write avec parité coûte le plus cher, et c’est la situation d’un nœud partagé toute la journée.

Ajoutez le comportement pendant un rebuild, et le choix s’impose. Une drive défaillante sur un nœud avec parité ralentit tous les guests de la machine pendant des heures. Une drive défaillante sur un nœud en RAID 10 ralentit une seule paire, et la copie s’effectue séquentiellement à la vitesse de la drive. Les fournisseurs vendent une latence qui ne connaît pas de pics ; ils l’achètent donc avec de la capacité : la moitié de la capacité brute des NVMe est consacrée au mirror.

La taille des drives va dans le même sens. Plus les drives sont grandes, plus la fenêtre de rebuild s’allonge. Avec la parité, c’est pendant cette fenêtre que tout est lent et que rien n’est protégé. C’est aussi pourquoi les déploiements ZFS pour la virtualisation utilisent des pools de vdevs en mirror plutôt que de larges raidz : un resilver de mirror ne copie que les blocs réellement utilisés, sur une seule paire.

Cela ne signifie pas que le RAID 10 convient partout. Une cible de sauvegarde est écrite en longues séquences et rarement lue ; le RAID 6 y offre donc un meilleur compromis. Il survit à deux défaillances et restitue la majeure partie de la capacité. C’est la charge de travail qui décide, pas le nombre. Pour une offre que vous choisissez aujourd’hui, le support compte généralement davantage que la disposition utilisée par-dessus, et le passage d’un SSD SATA au NVMe est plus important que toute différence de RAID sur l’un ou l’autre.

Comment lire /proc/mdstat

Exécutez ces commandes sur une machine dont vous administrez la baie : un serveur dédié, une machine chez vous ou un VPS avec deux volumes attachés que vous avez assemblés vous-même. Lisez votre propre sortie. Les blocs ci-dessous sont des exemples présentés en toutes lettres afin que vous puissiez comparer la structure avec celle que vous obtenez.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

Un RAID 10 sain composé de quatre disques affiche quelque chose de proche de ceci.

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

Chaque partie contient des informations.

• Personalities répertorie les modules md chargés par le kernel en cours d’exécution. La présence de raid10 signifie que le code est disponible, rien de plus.
• md0 : active raid10 indique le périphérique de la baie, son état et son niveau.
• Les noms qui suivent sont les membres. Le nombre entre crochets est l’index du périphérique dans les métadonnées de la baie, pas sa position sur la ligne et pas toujours son emplacement.
• Après le remplacement d’un disque, le nouveau membre conserve généralement un index supérieur à celui de l’emplacement qu’il occupe. nvme4n1p3[4] peut donc se trouver dans l’emplacement 2. mdadm --detail affiche l’emplacement réel dans sa colonne RaidDevice ; utilisez cette information lorsque la différence compte.
• (F) après un membre signifie qu’il est défaillant. (S) signifie qu’il s’agit d’un spare : il est présent, inactif et attend une défaillance.
• 3906764800 blocks super 1.2 indique la taille utilisable en blocs de 1 KiB, puis le format des métadonnées.
• 512K chunks 2 near-copies indique la taille des chunks de stripe et la disposition RAID 10, qui conserve ici deux copies de chaque bloc côte à côte.
• [4/4] indique le nombre de membres attendu par la baie, puis le nombre actuellement synchronisé.
• [UUUU] contient un caractère par emplacement, dans l’ordre des emplacements. U correspond à un emplacement actif et synchronisé. _ correspond à un emplacement qui ne contient aucun membre actif.
• bitmap: est le write intent bitmap. Il enregistre les régions en cours d’écriture afin qu’un membre qui tombe puis revient puisse resynchroniser ces régions plutôt que le disque entier.

Que signifient [4/3] et [UU_U] en cas de problème

Une baie dégradée ressemble à ceci.

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

Lisez les deux crochets ensemble. [4/3] indique qu’un des quatre emplacements ne contribue plus. [UU_U] indique lequel : le caractère de soulignement est le troisième caractère et les emplacements sont numérotés à partir de zéro, donc l’emplacement 2 est indisponible. Le flag (F) désigne le périphérique uniquement tant que le disque défaillant est encore connecté. Retirez-le de la machine : son nom disparaît de la ligne, mais le caractère de soulignement reste.

La baie continue de servir les données malgré cela. Avec un RAID 10, elle conserve souvent une vitesse proche de la vitesse maximale, ce qui explique que personne ne remarque forcément le problème. Un mécanisme doit donc vous en informer.

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

Le paquet mdadm installe un daemon de supervision qui lit MAILADDR depuis /etc/mdadm/mdadm.conf. Le nom de l’unité a changé entre les releases ; utilisez donc la dernière commande pour le trouver au lieu de le deviner. La commande --test envoie immédiatement un message pour chaque baie. Une boîte de réception vide après son exécution signifie que le chemin d’envoi des e-mails est défaillant. Le message qui vous intéresse aurait donc été perdu de la même manière.

Lorsqu’un remplacement est en cours de reconstruction, une ligne de progression apparaît sous la baie.

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

recovery correspond à une reconstruction sur un disque de remplacement. resync correspond au premier contrôle de cohérence d’une baie nouvellement créée. check correspond au scrub que vous avez déclenché plus haut. La paire entre parenthèses indique la progression en blocs de 1 KiB par rapport au total par périphérique, et finish est l’estimation du kernel à la vitesse actuelle. Cette vitesse est limitée par /proc/sys/dev/raid/speed_limit_min et speed_limit_max afin qu’une reconstruction ne monopolise pas les I/O de production.

/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

Remplacer un disque sur une baie que vous administrez se fait avec quatre commandes. La dernière commande sert à effectuer le contrôle.

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

La ligne de recovery doit apparaître en une ou deux secondes. La partition de remplacement doit être au moins aussi grande que Used Dev Size provenant de mdadm --detail. Une partition, même légèrement plus petite, est refusée avec un message de la forme not large enough to join array. Partitionnez le nouveau disque pour reproduire le partitionnement de l’ancien avant de l’ajouter.

Ce que vous pouvez voir ou non depuis un VPS

La plupart des guests ne peuvent pas voir le RAID de l’hôte, et c’est prévu ainsi. L’hyperviseur vous présente un disque virtuel. Que ce disque soit créé à partir d’un pool RAID 10 de disques NVMe ou qu’il repose sur un seul disque relève de la configuration de l’hôte. Cette information n’apparaît pas dans votre guest.

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt affiche kvm sur un guest KVM, un type de conteneur tel que lxc dans un conteneur, et none sur du bare metal. Sur un guest KVM, vous voyez généralement un seul vda ou sda dans lsblk, et aucun ensemble RAID dans /proc/mdstat, car il n’y en a pas dans le guest.

Sur un VPS basé sur un conteneur, cette information n’est pas fiable. Les conteneurs partagent le kernel de l’hôte, et certaines parties de /proc ne sont pas isolées par namespace. Les informations que vous y lisez peuvent donc décrire l’hôte plutôt que votre environnement. Ne considérez aucune d’elles comme une information certaine sur votre propre stockage. Demandez au fournisseur quelle est la configuration du stockage. Demandez une réponse écrite si cette information est importante pour vous.

Depuis le VPS, vous pouvez vérifier le comportement du disque qui vous a été attribué. Vérifier si le disque de votre VPS est réellement un disque NVMe présente les commandes qui renvoient des informations réelles. Ce qu’inclut réellement un VPS SSD explique ce que recouvre l’intitulé affiché sur la page de l’offre.

Faut-il utiliser RAID dans votre VPS ?

En général, non. La raison tient aux domaines de panne.

Si vous attachez deux volumes à un même VPS et les mettez en miroir avec mdadm, les deux volumes peuvent se trouver sur la même baie physique, sur le même nœud et derrière la même alimentation. Vous doubleriez le coût de chaque écriture pour une redondance déjà assurée par le fournisseur. Vous perdriez malgré tout les deux copies lors de la panne unique qui compte réellement.

Cette solution peut être pertinente si le fournisseur indique que les volumes résident dans des domaines de panne distincts, ou si vous utilisez un serveur dédié dont vous contrôlez les disques. Dans les autres cas, il vaut mieux consacrer ces efforts à des copies stockées en dehors de la machine.

Ce que le RAID ne protège pas

Le RAID couvre un seul événement : un disque qui cesse de fonctionner correctement. Toutes les opérations ci-dessous sont des écritures valides. La grappe les applique donc à chaque copie et reste considérée comme saine.

• Suppression. rm -rf dans le mauvais répertoire, ou un script de déploiement dont une variable de chemin n’est pas définie. La grappe voit une écriture valide et l’effectue deux fois.
• Rançongiciel. Le chiffrement est une écriture. Une grappe saine stocke la version chiffrée sur les deux disques du miroir.
• Application défaillante. Un bug qui écrit des données incohérentes dans votre base de données écrit les mêmes données sur le disque redondant.
• Nœud entier. Un hôte qui tombe en panne, ou un compte suspendu par erreur. Une grappe peut être parfaitement fonctionnelle et inaccessible en même temps.
• Vous-même, une semaine plus tard. Le fichier supprimé lundi a disparu de tous les disques dès lundi. Seule une copie effectuée avant cette date permet de le restaurer.

Les snapshots stockés sur le même support ne résolvent pas non plus le problème. Ils aident en cas de suppression, mais disparaissent avec la grappe qui les héberge. Ce qui fait d’une sauvegarde une véritable sauvegarde, c’est qu’elle se trouve ailleurs. Sauvegardes chiffrées hors serveur avec restic constitue l’autre moitié de cette page : la grappe vous permet de continuer à fournir le service lorsqu’un disque tombe en panne, et restic récupère vos données lorsque le dommage provient d’une écriture que la grappe a appliquée sans erreur.

FAQ

RAID 10 signifie-t-il que je n’ai pas besoin de sauvegardes ?

Non. RAID 10 protège contre la défaillance d’un disque. Chaque écriture valide est appliquée aux deux membres d’un miroir. Une suppression ou une attaque par ransomware atteint donc le disque redondant au même instant. La grappe se signale ensuite comme saine, car de son point de vue aucune défaillance ne s’est produite. Vous avez toujours besoin de copies stockées hors de la machine. Vous devez également en restaurer une de temps en temps pour vérifier qu’elles fonctionnent.

Pourquoi les fournisseurs de VPS choisissent-ils RAID 10 plutôt que RAID 5 ou RAID 6 ?

Pour deux raisons, qui concernent toutes deux les petites écritures aléatoires. Une écriture avec parité doit d’abord relire les anciennes données et l’ancienne parité avant de calculer la nouvelle parité. Une petite écriture coûte donc 4 opérations sur RAID 5 et 6 sur RAID 6, contre 2 sur un miroir. Une reconstruction avec parité doit ensuite lire tous les disques encore disponibles de bout en bout. Cela ralentit chaque guest du nœud pendant plusieurs heures. Avec RAID 10, la reconstruction copie un disque vers un autre et laisse les autres paires intactes. Le coût pour les fournisseurs est la capacité : la moitié de la capacité brute des NVMe.

Que signifient [U_] ou [UU_U] dans /proc/mdstat ?

Chaque caractère représente un slot de la grappe, dans l’ordre des slots, avec un caractère par slot. U signifie que le slot contient un membre actif et synchronisé. _ signifie que le slot ne contient aucun membre fonctionnel. [U_] sur un miroir à deux disques signifie que le second slot est indisponible et qu’il ne reste plus de redondance. Interprétez cette information avec la paire qui la précède : [4/3] indique que la grappe attend quatre membres et qu’elle en possède trois. L’ordre des slots correspond à la colonne RaidDevice de mdadm --detail, et non à l’ordre dans lequel les noms de périphériques apparaissent sur la ligne.

Combien de disques une grappe RAID 10 peut-elle perdre ?

Un seul, quelle que soit la configuration des pannes. Au-delà, cela dépend de l’endroit où les pannes se produisent. Chaque paire miroir peut perdre l’un de ses deux membres. Une grappe de huit disques peut donc survivre à quatre pannes si aucune paire n’est touchée deux fois. Elle tombe en panne dès deux pannes si celles-ci touchent la même paire. Dimensionnez votre architecture selon le nombre garanti, qui est de un. Considérez tout dépassement comme de la chance, et non comme une protection.

Dois-je mettre en miroir deux volumes dans mon VPS avec mdadm ?

En général, non. Deux volumes attachés à un même VPS se trouvent souvent sur la même grappe physique, sur le même hôte. Leur mise en miroir double donc le coût de chaque écriture et ne protège contre rien que le RAID de l’hôte ne couvre déjà. Cette configuration n’est utile que si le fournisseur indique que les volumes se trouvent dans des domaines de panne distincts. Sinon, utilisez plutôt cet effort pour mettre en place des sauvegardes stockées hors de la machine.