Wat is RAID 10 en waarom gebruiken VPS-hosts dit?

Wat RAID 10 is en waarom VPS-hosts dit gebruiken

RAID 10 is de opslagindeling die de meeste VPS-hosts gebruiken voor gevirtualiseerde NVMe (non-volatile memory express) schijven. Het spiegelt elke schijf naar een partner en verdeelt (striping) vervolgens gegevens over deze gespiegelde paren. Eén schijf kan uitvallen zonder dat de array stopt, en het herstel is een eenvoudige kopie vanaf de overgebleven partner in plaats van een herberekening waarbij elke andere schijf in de set moet worden gelezen.

RAID staat voor redundant array of independent disks. Het heeft één taak: de machine operationeel houden terwijl een schijf defect is of wordt vervangen. Die taak is beschikbaarheid, en beschikbaarheid is geen veiligheid.

RAID repliceert uw schrijfacties. rm -rf /srv is een schrijfactie. Beide helften van de spiegel verwijderen de map in dezelfde milliseconde, en de array rapporteert zichzelf daarna nog steeds als in orde.

Onthoud die zin. De rest van deze pagina behandelt wat elk niveau overleeft en wat elk niveau u kost bij elke schrijfactie. De laatste secties bevatten de commando's om de status van een array te lezen op een machine die u beheert, en de fout die RAID nooit heeft afgedekt.

De niveaus die een hostingklant daadwerkelijk tegenkomt: 1, 5, 6 en 10

Een pagina met abonnementen noemt een getal en stopt daar. Dat getal beantwoordt twee vragen: hoeveel schijven kunnen er defect raken en wat kost elke schrijfactie.

RAID 1 is een spiegel. Twee schijven bevatten identieke blokken. Elke schrijfactie gaat naar beide schijven. Elke schijf kan een leesverzoek afhandelen. Eén schijf kan defect raken zonder dataverlies, en de helft van de ruwe capaciteit is bruikbaar. Er is geen pariteit om te berekenen, dus het schrijfpad is kort.

RAID 5 is striping met één pariteitsblok per stripe. Met n schijven krijgt u de capaciteit van n-1 schijven, en de array overleeft precies één defect. De pariteit staat niet op één toegewezen schijf. Deze roteert over alle schijven, waardoor elke schijf zowel data als pariteit bevat.

RAID 6 voegt een tweede, onafhankelijk pariteitsblok toe aan elke stripe, meestal geschreven als P en Q. Het overleeft het gelijktijdig defect raken van twee willekeurige schijven. Dat is belangrijker dan het klinkt, omdat het tweede defect meestal optreedt tijdens het herstel van het eerste.

RAID 10 is een stripe van spiegels. Schijven worden in paren gespiegeld en data wordt verspreid over de paren. De bruikbare capaciteit is de helft van het ruwe totaal, net als bij RAID 1, met de parallelliteit van striping erbovenop.

U zult het ook geschreven zien als RAID 1+0, wat de eerlijke beschrijving is: eerst spiegelen, dan stripen over de spiegels. RAID 0+1 is de andere volgorde: eerst stripen en dan de twee stripes spiegelen. Dit is minder goed, omdat bij één defecte schijf een hele stripe buiten gebruik raakt en het herstel de volledige andere kant moet kopiëren.

Linux is een bijzonder geval dat het vermelden waard is. De raid10 van de kernel is één geheel in plaats van twee gestapelde lagen, dus het draait op een oneven aantal schijven en heeft lay-outs (near, far, offset) die een geneste configuratie niet kan bieden. Daarom geeft de statusregel op een Linux-systeem 2 near-copies aan in plaats van twee arrays te benoemen.

[
  {
    "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
  }
]

Acht schijven van 1 TB geven 7 TB aan bruikbare ruimte onder RAID 5 en 4 TB onder RAID 10. Dat verschil is echt geld, en dat is de reden waarom pariteit steeds opnieuw wordt voorgesteld. RAID 6 overleeft 2 defecten in elk willekeurig patroon. RAID 10 garandeert slechts 1, omdat het gevaarlijke tweede defect het defect is dat op de partner van de reeds defecte schijf valt. Het overleeft tot 4 wanneer geen twee defecten hetzelfde paar delen, wat geluk is in plaats van een ontwerpeigenschap.

Wat elk niveau kost bij elke schrijfactie

Een schrijfactie naar een mirror bestaat uit twee schrijfacties die tegelijkertijd naar beide leden worden verzonden. Een schrijfactie naar een parity-stripe vergt meer werk, omdat het parity-blok voor die stripe niet langer klopt en opnieuw moet worden berekend.

De controller kan de parity niet berekenen op basis van alleen het nieuwe blok. Hiervoor zijn eerst het oude datablok en het oude parity-blok nodig. Eén kleine, willekeurige schrijfactie naar RAID 5 resulteert dus in lezen, lezen, schrijven, schrijven. RAID 6 heeft een tweede syndroom dat moet worden bijgehouden, waardoor dezelfde schrijfactie resulteert in lezen, lezen, lezen, schrijven, schrijven, schrijven.

[
  {
    "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
  }
]

Een kleine, willekeurige schrijfactie kost 6 apparaatoperaties op RAID 6 en 2 op RAID 10. Deze aantallen onderschatten het verschil in latentie. De twee mirror-schrijfacties worden parallel uitgevoerd, waardoor de gast wacht op de traagste van de twee. Het parity-pad bevat een leesactie die moet zijn voltooid voordat de nieuwe parity kan worden berekend; de gast wacht dus op een leesactie en vervolgens op een schrijfactie, na elkaar. Op een drukke host komt die leesactie in de wachtrij achter de I/O van alle andere processen.

Er is een belangrijke uitzondering. Een schrijfactie die groot genoeg is om een volledige stripe te vullen, heeft geen oude data nodig, omdat elk blok in de stripe wordt vervangen. De parity wordt berekend op basis van wat al in het geheugen staat, en de kosten dalen tot één extra schrijfactie. Dit is de reden waarom RAID 5 er goed uitziet in een sequentiële benchmark, maar slecht presteert onder een gemengde belasting van kleine schrijfacties van veel tenants. Test het patroon dat u daadwerkelijk gebruikt: een VPS-schijf correct benchmarken betekent willekeurige I/O bij een realistische wachtrijdiepte, niet één grote dd.

Waarom de rebuild het gevaarlijke onderdeel is

Een parity-rebuild moet de ontbrekende schijf reconstrueren op basis van alle overige schijven; hiervoor worden 7 overgebleven schijven gelezen, van het eerste tot het laatste blok. Een RAID 10-rebuild leest 1: de mirror-partner van de defecte schijf en niets anders.

Hieruit vloeien twee kosten voort. De eerste is tijd, omdat de rebuild wordt beperkt door de traagste overgebleven schijf en de aanvullende parity-berekeningen. De tweede is belasting. Elke schijf in een parity-set is gedurende het gehele proces bezet, waardoor elke guest op die node een hogere latency ervaart totdat het proces is voltooid. Bij RAID 10 is slechts één paar bezet, terwijl de andere paren op hun normale snelheid blijven presteren.

Binnen hetzelfde tijdsbestek is er een risico voor de integriteit. Een RAID 5-array met één defecte schijf heeft geen redundantie meer, waardoor een onleesbare sector op een overgebleven schijf nu onherstelbaar is. Een rebuild is de enige operatie die elke sector leest, inclusief de sectoren die in een jaar tijd door niemand zijn aangeraakt. Gepubliceerde specificaties plaatsen een consumenten-harde schijf op ongeveer één onherstelbare leesfout per 10^14 gelezen bits, en een enterprise NVMe-schijf op één per 10^17 of beter. Dit zijn leveranciersspecificaties in plaats van metingen, maar de verhouding verklaart waarom de oude waarschuwing dat een RAID 5-rebuild zal falen, werd geschreven voor grote roterende schijven, en waarom dit risico bij NVMe veel kleiner is. Het argument over de belasting geldt echter voor elk medium.

Vind latente fouten voordat een rebuild dit doet door middel van scrubbing. Debian en Ubuntu leveren een periodieke scrub voor md-arrays, en het mechanisme verschilt per release; controleer dus welke versie u heeft en start daarna handmatig een pass.

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 keert terug naar idle wanneer de pass is voltooid, en mismatch_cnt zou 0 moeten aangeven. Een getal boven nul op een mirror betekent dat de twee helften niet overeenstemmen en de kernel niet kan bepalen welke versie correct is, omdat geen van beide kopieën een checksum bevat. Sommige mismatches zijn onschadelijk; swap-partities zijn de gebruikelijke bron hiervan: de kernel kan een pagina schrijven die eronder verandert. Een oplopend aantal op een data-array is een indicatie dat een schijf moet worden vervangen.

Waarom VPS-providers standaardiseren op RAID 10 voor NVMe

Een hypervisor-node draait niet slechts één workload. Het draait tientallen ongerelateerde guests, en hun I/O komt binnen als een stroom van kleine, onderling niet-gerelateerde schrijfacties. Dat is precies het patroon waarbij de read-modify-write-cyclus van pariteit de meeste overhead veroorzaakt, en het is het patroon dat een gedeelde node de hele dag door ziet.

Voeg daar het rebuild-gedrag aan toe en de keuze is snel gemaakt. Een defecte schijf in een node met pariteit vertraagt elke guest op de machine gedurende uren. Een defecte schijf in een RAID 10-node vertraagt slechts één paar, en het kopiëren verloopt sequentieel op de snelheid van de schijf. Providers verkopen latentie die niet piekt, dus kopen ze dat af met capaciteit: de helft van de ruwe NVMe-capaciteit gaat op aan de mirror.

Schijfgroottes dwingen tot dezelfde keuze. Naarmate schijven groter worden, wordt het rebuild-venster langer, en bij pariteit is dat het venster waarin alles traag is en niets beschermd. Het is dezelfde reden waarom ZFS-implementaties voor virtualisatie pools van mirrored vdevs gebruiken in plaats van brede raidz: een mirror-resilver kopieert alleen de blokken die daadwerkelijk in gebruik zijn, op één paar.

Dit betekent niet dat RAID 10 overal de juiste keuze is. Een back-updoel wordt beschreven in lange sequentiële runs en zelden gelezen, dus daar is RAID 6 de betere optie. Het overleeft twee defecten en levert het grootste deel van de capaciteit op. De workload bepaalt de keuze, niet het getal. Voor een plan dat u vandaag kiest, is het medium meestal belangrijker dan de lay-out die er bovenop ligt, en de sprong van SATA SSD naar NVMe is groter dan elk RAID-verschil op beide media.

Hoe u /proc/mdstat leest

Voer deze commando's uit op een machine waar u de array beheert: een dedicated server, een thuisserver of een VPS met twee zelfgekoppelde volumes. Lees uw eigen output. De onderstaande blokken zijn voorbeelden, zo opgesteld dat u ze kunt vergelijken met wat u zelf ziet.

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

Een gezonde RAID 10 met vier schijven geeft ongeveer de volgende output.

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>

Elk onderdeel hiervan bevat informatie.

• Personalities somt de md-modules op die de actieve kernel heeft geladen. Als raid10 daar verschijnt, betekent dit enkel dat de code beschikbaar is.
• md0 : active raid10 is het array-apparaat, de status ervan en het RAID-niveau.
• De namen daarna zijn de leden. Het getal tussen vierkante haken is de index van het apparaat in de array-metadata; dit is niet de positie op de regel en niet altijd de fysieke slot.
• Na het vervangen van een schijf krijgt het nieuwe lid meestal een hogere index dan de slot die het opvult, waardoor nvme4n1p3[4] in slot 2 kan staan. mdadm --detail toont de werkelijke slot in de kolom RaidDevice, gebruik die dus wanneer het verschil relevant is.
• (F) achter een lid betekent dat deze defect is. (S) betekent spare: aanwezig, inactief, wachtend op een defect.
• 3906764800 blocks super 1.2 is de bruikbare grootte in 1 KiB-blokken, gevolgd door het metadata-formaat.
• 512K chunks 2 near-copies is de stripe chunk-grootte en de RAID 10-layout, die hier twee kopieën van elk blok naast elkaar bewaart.
• [4/4] is het aantal leden dat de array verwacht, gevolgd door het aantal dat momenteel gesynchroniseerd is.
• [UUUU] is één teken per slot, in de volgorde van de slots. U is een slot die actief is en gesynchroniseerd. _ is een slot waar niets in werkt.
• bitmap: is de write intent bitmap. Deze registreert welke regio's werden beschreven, zodat een lid dat wegvalt en terugkeert alleen die regio's opnieuw synchroniseert in plaats van de hele schijf.

Wat [4/3] en [UU_U] betekenen als er iets mis is

Een gedegradeerde array ziet er als volgt uit.

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]

Lees de twee haakjes samen. [4/3] geeft aan dat één van de vier slots niet bijdraagt. [UU_U] geeft aan welke, omdat het underscore-teken het derde teken is en de slots vanaf nul worden geteld; slot 2 is dus defect. De vlag (F) benoemt het apparaat alleen zolang de defecte schijf nog is aangesloten. Haal deze uit de machine en de naam verdwijnt van de regel, terwijl de underscore blijft staan.

De array blijft tijdens dit alles functioneren, en bij RAID 10 werkt dit vaak op bijna volledige snelheid, waardoor niemand het merkt door de prestaties. Iets moet u waarschuwen.

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

Het pakket mdadm installeert een monitor-daemon die MAILADDR leest uit /etc/mdadm/mdadm.conf. De unit-naam is tussen releases veranderd, dus zoek deze met het laatste commando in plaats van te gokken. De run --test verstuurt direct één bericht per array. Een lege inbox daarna betekent dat het mailpad defect is; het bericht waar u echt om geeft, zou op dezelfde manier verloren zijn gegaan.

Wanneer een vervangende schijf wordt herbouwd, verschijnt er een voortgangsregel onder de array.

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 is een rebuild naar een vervangende schijf. resync is de eerste consistentiecontrole van een nieuw aangemaakte array. check is de scrub die u hierboven heeft geactiveerd. Het paar tussen haakjes is de voortgang in 1 KiB-blokken ten opzichte van het totaal per apparaat, en finish is de schatting van de kernel bij de huidige snelheid. Die snelheid wordt begrensd door /proc/sys/dev/raid/speed_limit_min en speed_limit_max; deze limieten bestaan zodat een rebuild de productie-I/O niet vertraagt.

/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

Het vervangen van een schijf in een array die u beheert, bestaat uit vier commando's, waarbij de laatste de controle is.

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

De herstelregel zou binnen een seconde of twee moeten verschijnen. De vervangende partitie moet minstens zo groot zijn als Used Dev Size uit mdadm --detail; een partitie die zelfs maar iets kleiner is, wordt geweigerd met een melding in de vorm van not large enough to join array. Partitioneer de nieuwe schijf zodat deze overeenkomt met de oude voordat u deze toevoegt.

Wat u wel en niet kunt zien vanuit een VPS

De meeste gastsystemen kunnen de RAID van de host niet inzien; dit is een bewuste ontwerpkeuze. De hypervisor stelt één virtuele schijf aan u beschikbaar. Of die schijf nu is onderverdeeld uit een RAID 10-pool van NVMe-schijven of op één enkele schijf staat, is een eigenschap van de host en is niet zichtbaar binnen uw gastomgeving.

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

systemd-detect-virt geeft kvm weer op een KVM-gast, een containertype zoals lxc op een container, en none op bare metal. Op een KVM-gast ziet u doorgaans één enkele vda of sda in lsblk, en geen arrays in /proc/mdstat, omdat deze binnen de gastomgeving niet bestaan.

Op een VPS op basis van containers zijn de meetwaarden niet betrouwbaar. Containers delen de kernel van de host en delen van /proc zijn niet voorzien van een namespace, waardoor de informatie die u daar leest de host kan beschrijven in plaats van uw specifieke slice. Beschouw niets hiervan als een feit over uw eigen opslag. Vraag de provider naar de configuratie en laat dit schriftelijk bevestigen als dit voor u van belang is.

Wat u wel van binnenuit kunt controleren, is het gedrag van de schijf die aan u is toegewezen. Controleren of uw VPS-schijf echt NVMe is behandelt de commando's die feitelijke informatie rapporteren, en wat een SSD VPS daadwerkelijk bevat behandelt wat de specificaties op de productpagina beweren.

Moet u RAID binnen uw VPS draaien?

Doorgaans niet, en de reden hiervoor zijn failure domains. Als u twee volumes aan één VPS koppelt en deze spiegelt met mdadm, kunnen beide volumes zich op dezelfde fysieke array bevinden, op dezelfde node, achter dezelfde voeding. U verdubbelt de kosten van elke schrijfactie voor redundantie die u al had, en u verliest alsnog beide kopieën bij de enige fout die er echt toe doet.

Het is de moeite waard wanneer de provider documenteert dat de volumes zich in afzonderlijke failure domains bevinden, of wanneer u op een dedicated server werkt met schijven die u zelf kunt aansturen. Anders is de inspanning effectiever besteed aan kopieën die de machine verlaten.

Waar RAID u niet tegen beschermt

RAID dekt één scenario af: een schijf die niet meer correct functioneert. Alles hieronder wordt gezien als een geldige schrijfactie, dus de array voert deze uit op elke kopie en rapporteert zichzelf als gezond.

• Verwijdering. rm -rf in de verkeerde map, of een deploy-script met een niet-ingestelde variabele in een pad. De array ziet een legale schrijfactie en voert deze dubbel uit.
• Ransomware. Versleuteling is een schrijfactie. Een gezonde array slaat de versleutelde versie op beide helften van de mirror op.
• Een defecte applicatie. Een bug die corrupte data in uw database schrijft, schrijft dezelfde corrupte data naar de redundante schijf.
• Het volledige knooppunt. Een host die uitvalt, of een account dat per ongeluk is opgeschort. Een array kan perfect functioneren en tegelijkertijd onbereikbaar zijn.
• Uzelf, een week later. Het bestand dat u op maandag verwijderde, is op maandag van elke schijf verdwenen. Alleen een kopie die daarvoor is gemaakt, kan het terugbrengen.

Snapshots op dezelfde opslag zijn evenmin de oplossing. Ze helpen tegen verwijdering, maar ze gaan verloren met de array waarop ze staan. De eigenschap die een back-up tot een back-up maakt, is dat deze zich op een andere locatie bevindt. Versleutelde off-server back-ups met restic is de andere helft van deze pagina: de array zorgt dat u bereikbaar blijft bij een defecte schijf, en restic haalt uw data terug wanneer de schade het gevolg was van een schrijfactie die de array zonder problemen heeft uitgevoerd.

FAQ

Betekent RAID 10 dat ik geen back-ups nodig heb?

Nee. RAID 10 beschermt tegen een schijf die stopt met werken. Het voert elke geldige schrijfactie uit op beide helften van een mirror, dus een verwijdering of een ransomware-aanval bereikt de redundante schijf op hetzelfde moment. De array rapporteert zichzelf daarna als in orde, omdat er vanuit het perspectief van de array niets is mislukt. U heeft nog steeds kopieën nodig die zich buiten de machine bevinden, en u moet er af en toe een terugzetten om te controleren of ze werken.

Waarom kiezen VPS-providers voor RAID 10 in plaats van RAID 5 of RAID 6?

Twee redenen, beide gerelateerd aan kleine willekeurige schrijfacties. Een pariteitsschrijfactie vereist dat de oude data en de oude pariteit worden teruggelezen voordat de nieuwe pariteit kan worden berekend. Een kleine schrijfactie kost daarom 4 operaties op RAID 5 en 6 op RAID 6, tegenover 2 op een mirror. Een pariteitsrebuild leest vervolgens elke overgebleven schijf van begin tot eind, wat elke gast op de node urenlang vertraagt, terwijl een RAID 10-rebuild één schijf naar één schijf kopieert en de andere paren ongemoeid laat. Providers betalen hiervoor met capaciteit: de helft van de ruwe NVMe.

Wat betekent [U_] of [UU_U] in /proc/mdstat?

Elk teken staat voor één slot in de array, in de volgorde van de slots, met één teken per slot. U betekent dat het slot een lid bevat dat actief en gesynchroniseerd is. _ betekent dat er in dat slot niets werkends zit. [U_] op een mirror met twee schijven betekent dat het tweede slot defect is en er geen redundantie meer over is. Lees dit samen met het paar ervoor, waarbij [4/3] aangeeft dat de array vier leden verwacht en er drie heeft. De volgorde van de slots komt overeen met de RaidDevice-kolom van mdadm --detail, niet met de volgorde waarin de apparaatnamen op de regel verschijnen.

Hoeveel schijven kan een RAID 10-array verliezen?

Eén, in elk patroon. Daarboven hangt het af van waar de defecten optreden. Elk mirror-paar kan één van zijn twee leden verliezen, dus een array met acht schijven overleeft maximaal vier defecten als er geen twee schijven in hetzelfde paar zitten, en de array faalt bij twee defecten als beide in hetzelfde paar vallen. Plan op basis van het gegarandeerde aantal, wat één is, en beschouw alles daarboven als geluk in plaats van bescherming.

Moet ik twee volumes binnen mijn VPS spiegelen met mdadm?

Meestal niet. Twee volumes die aan één VPS zijn gekoppeld, bevinden zich vaak op dezelfde fysieke array op dezelfde host. Het spiegelen ervan verdubbelt de kosten van elke schrijfactie en beschermt tegen niets wat de eigen RAID van de host niet al afdekte. Het is alleen de moeite waard als de provider documenteert dat de volumes zich in afzonderlijke foutdomeinen bevinden. Steek die inspanning anders in back-ups die de machine verlaten.