RAID 10 per lo storage VPS: come funziona

Cos'è RAID 10 e perché i provider VPS lo usano

RAID 10 è il layout di archiviazione più usato dai provider VPS con unità NVMe (non-volatile memory express) virtualizzate. Nel layout convenzionale a due copie, esegue il mirroring di ogni unità su un'unità partner, quindi distribuisce i dati tra le coppie sottoposte a mirroring. Un'unità può guastarsi senza interrompere l'array. La ricostruzione consiste in una semplice copia dall'unità partner ancora attiva, invece di un ricalcolo che legge tutte le altre unità del set.

RAID significa redundant array of independent disks. Ha un solo obiettivo: mantenere la macchina operativa mentre un disco è guasto o viene sostituito. Questo obiettivo è la disponibilità, che non equivale alla sicurezza dei dati.

RAID replica le scritture. rm -rf /srv è una scrittura. Entrambe le metà del mirror eliminano la directory nello stesso millisecondo, e l'array continua a risultare integro.

Conserva questa frase. Il resto di questa pagina spiega quali guasti ogni livello è in grado di tollerare e quale costo comporta per ogni scrittura. Le sezioni finali contengono i comandi per leggere lo stato di un array su una macchina di tua proprietà e descrivono il guasto che RAID non ha mai coperto.

I livelli che un acquirente di hosting incontra davvero: 1, 5, 6 e 10

La pagina di un piano indica un numero e si ferma lì. Quel numero risponde a due domande: quanti dischi possono guastarsi e quale costo comporta ogni scrittura.

RAID 1 è un mirror. Due dischi contengono blocchi identici. Ogni scrittura viene eseguita su entrambi. Entrambi i dischi possono servire una lettura. Un disco può guastarsi senza perdita di dati e metà della capacità grezza è utilizzabile. Non è necessario calcolare la parità, quindi il percorso di scrittura è breve.

RAID 5 distribuisce i dati con un blocco di parità per ogni stripe. Con n dischi si ottiene la capacità di n-1 dischi e l'array sopravvive esattamente a un guasto. La parità non risiede su un unico disco dedicato. Viene distribuita a rotazione su tutti i dischi, quindi ogni disco contiene sia dati sia parità.

RAID 6 aggiunge un secondo blocco di parità indipendente a ogni stripe, indicato in genere con P e Q. Può tollerare il guasto simultaneo di due dischi qualsiasi. Questo è più importante di quanto possa sembrare, perché il secondo guasto si verifica molto spesso durante la riparazione del primo.

RAID 10 è uno stripe di mirror. I dischi sono replicati a coppie e i dati vengono distribuiti tra le coppie. La capacità utilizzabile è metà della capacità grezza complessiva, come in RAID 1, con il parallelismo dello striping aggiunto.

Lo si trova anche scritto come RAID 1+0, che è la descrizione corretta: prima si crea il mirror, poi si esegue lo stripe tra i mirror. RAID 0+1 segue l'ordine opposto: prima crea lo stripe e poi esegue il mirror dei due stripe. È una soluzione peggiore, perché il guasto di un disco rende indisponibile un intero stripe e la riparazione deve copiare l'intero altro lato.

Linux è un caso particolare che vale la pena conoscere. Il kernel usa raid10 come una singola personality, non come due livelli sovrapposti, quindi può funzionare con un numero dispari di dischi e offre layout (near, far, offset) che una configurazione annidata non può esprimere. Per questo la riga di stato su un sistema Linux indica 2 near-copies invece di nominare due array.

[
  {
    "label": "RAID 1 (eight copies)",
    "usable_tb": 1,
    "worst_case_drives_lost": 7,
    "best_case_drives_lost": 7
  },
  {
    "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
  }
]

Otto dischi da 1 TB forniscono 7 TB di spazio utilizzabile con RAID 5 e 4 TB con RAID 10. La differenza si traduce in un costo reale, ed è per questo che la parità viene proposta così spesso. RAID 6 sopravvive a 2 guasti, indipendentemente dalla loro combinazione. RAID 10 garantisce soltanto 1, perché il secondo guasto più pericoloso è quello che colpisce il disco associato a quello già guasto. Può sopravvivere fino a 4 guasti quando nessuna coppia subisce due guasti, ma si tratta di una circostanza favorevole, non di una proprietà progettuale.

Qual è il costo di ogni livello per ogni scrittura

Una scrittura su un mirror equivale a due scritture, eseguite contemporaneamente su entrambi i membri. Una scrittura su una stripe con parità richiede più lavoro, perché il blocco di parità della stripe non è più valido e deve essere ricalcolato.

Con la modalità read-modify-write, il controller legge prima i dati e la parità precedenti. Una sovrascrittura non memorizzata nella cache di un singolo blocco su RAID 5 diventa quindi: lettura, lettura, scrittura, scrittura. RAID 6 mantiene due blocchi di parità, quindi read-modify-write diventa: lettura, lettura, lettura, scrittura, scrittura, scrittura. Linux usa anche reconstruct-write, leggendo i dati invariati per calcolare la parità. Su RAID 5 con tre unità, questa sovrascrittura può richiedere una lettura dei dati e due scritture; su RAID 6 con quattro unità, una lettura dei dati e tre scritture. Quattro e sei sono i conteggi delle operazioni read-modify-write, non costi fissi per ogni piccola scrittura casuale.

[
  {
    "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, fixed mirror pairs)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

Una read-modify-write non memorizzata nella cache, relativa a un singolo blocco, richiede 6 operazioni sui dispositivi con RAID 6, contro 2 per la stessa sovrascrittura su RAID 10 a due copie. Questi conteggi sottostimano la differenza di latenza. Le due scritture del mirror vengono eseguite in parallelo, quindi il guest attende quella più lenta. Il percorso read-modify-write contiene una lettura che deve terminare prima di poter calcolare la nuova parità; il guest attende quindi prima una lettura e poi una scrittura, in sequenza. Su un host sotto carico, quella lettura entra in coda dietro alle operazioni di I/O degli altri utenti.

Esiste un'eccezione importante. Una scrittura abbastanza grande da riempire un'intera stripe non richiede i dati precedenti, perché ogni blocco della stripe viene sostituito. La parità viene calcolata a partire dai dati già presenti in memoria e il sovraccarico si riduce a una scrittura della parità per stripe con RAID 5 oppure a due con RAID 6, senza letture preliminari. Per questo RAID 5 offre buoni risultati in un benchmark sequenziale, ma si comporta male con un carico misto composto da piccole scritture provenienti da molti tenant. Testa il pattern che utilizzi realmente: eseguire correttamente il benchmark del disco di una VPS significa usare I/O casuale con una profondità della coda realistica, non un unico dd di grandi dimensioni.

Perché la ricostruzione è la fase più rischiosa

Una ricostruzione completa di RAID 5 deve ricostruire l'unità mancante usando tutti gli altri dati, quindi, nell'esempio con otto unità, legge 7 unità superstiti dall'inizio alla fine. Con coppie mirror fisse, una ricostruzione RAID 10 legge 1: il partner mirror dell'unità guasta e nient'altro. Gli altri layout Linux RAID10 distribuiscono le copie in modo diverso: la ricostruzione di un membro del layout near a tre dispositivi legge entrambi i membri superstiti.

Ne derivano due costi. Il primo è il tempo, perché la ricostruzione è limitata dalle unità superstiti, dal lavoro di ricostruzione e dagli obiettivi di velocità del ripristino. Il secondo è il carico. Una ricostruzione con parità distribuisce l'I/O tra le unità superstiti. Con coppie mirror fisse, una ricostruzione RAID 10 concentra l'I/O su una coppia; le risorse condivise del controller e dell'host influenzano comunque le altre coppie.

Nella stessa finestra esiste anche un rischio per l'integrità dei dati. Un array RAID 5 con un'unità guasta non ha più ridondanza, quindi un settore illeggibile su una qualsiasi unità superstite non è più recuperabile. Una ricostruzione è l'unica operazione che legge ogni settore, compresi quelli che nessuno ha utilizzato nell'ultimo anno. I valori pubblicati nelle schede tecniche indicano, per un disco rigido consumer, circa un errore di lettura non recuperabile ogni 10^14 bit letti e, per un'unità NVMe enterprise, uno ogni 10^17 bit o oltre. Si tratta di specifiche dei vendor, non di misurazioni, ma il rapporto spiega perché il vecchio avvertimento secondo cui una ricostruzione RAID 5 sarebbe fallita si riferiva ai grandi dischi magnetici e perché è molto meno valido per NVMe. L'argomento relativo al carico vale per qualsiasi supporto.

Individuate gli errori latenti prima che lo faccia una ricostruzione, eseguendo uno scrub. Debian e Ubuntu includono uno scrub periodico per gli array md, ma il meccanismo varia tra le release; verificate quindi quale meccanismo è presente e avviate manualmente un passaggio.

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 torna a idle al termine del passaggio e mismatch_cnt dovrebbe indicare 0. Un numero superiore a zero su un mirror significa che le due metà non corrispondono e che il kernel non può stabilire quale sia quella corretta, perché nessuna delle due copie contiene un checksum. Alcune discrepanze sono innocue; la causa più comune sono le partizioni di swap: il kernel può scrivere una pagina che cambia mentre viene letta. Un conteggio in aumento su un array di dati richiede un'indagine; il conteggio, da solo, non identifica l'unità da sostituire.

Perché i provider VPS standardizzano su RAID 10 per NVMe

Un nodo hypervisor non esegue un solo carico di lavoro. Esegue decine di guest non correlati, il cui I/O arriva come un flusso intercalato di piccole scritture, senza località tra una scrittura e l'altra. È esattamente il modello in cui il ciclo di lettura-modifica-scrittura della parità ha il costo maggiore, ed è il modello che un nodo condiviso gestisce per tutta la giornata.

Considerando anche il comportamento durante il rebuild, la scelta diventa naturale. Un drive guasto su un nodo con parità aggiunge lavoro di ricostruzione su tutti i drive superstiti. Con coppie mirror fisse, un drive guasto su un nodo RAID 10 aggiunge I/O di rebuild a una sola coppia, mentre Linux MD rallenta il recupero quando sono in corso altre attività. I provider vendono una latenza stabile, senza picchi, e la ottengono sacrificando capacità: metà della capacità grezza degli NVMe viene destinata al mirror.

Anche le dimensioni dei drive spingono nella stessa direzione. Con l'aumento della capacità dei drive, la finestra di rebuild si allunga; su RAID 5, durante questa finestra la ricostruzione aggiunge carico e non rimane alcuna ridondanza. RAID 6 mantiene la protezione contro il guasto di un altro drive. Per lo stesso motivo, nelle installazioni ZFS per la virtualizzazione si usano pool di vdev mirror invece di raidz estesi: un resilver del mirror copia soltanto i blocchi effettivamente in uso, su una sola coppia.

Questo non rende RAID 10 la scelta corretta in ogni situazione. Un target di backup viene scritto con lunghe sequenze successive e letto raramente, quindi RAID 6 è più conveniente. Resiste a due guasti e restituisce la maggior parte della capacità. È il carico di lavoro a determinare la scelta, non il numero. Per un piano scelto oggi, il supporto di archiviazione di solito conta più del layout applicato sopra di esso, e il passaggio da SSD SATA a NVMe è più significativo di qualsiasi differenza tra configurazioni RAID su entrambi.

Come leggere /proc/mdstat

Esegui questi comandi su una macchina che gestisci e su cui possiedi l'array: un server dedicato, un sistema in casa oppure una VPS con due volumi collegati e assemblati da te. Esamina il tuo output. I blocchi seguenti sono esempi riportati per esteso, così puoi confrontare la struttura con quella del risultato ottenuto.

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

Un RAID 10 integro con quattro dischi restituisce un output simile a questo.

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>

Ogni parte contiene informazioni.

• Personalities elenca i moduli md caricati dal kernel in esecuzione. La presenza di raid10 indica che il codice è disponibile, ma non fornisce altre informazioni.
• md0 : active raid10 è il dispositivo dell'array, con il relativo stato e livello.
• I nomi che seguono sono i membri. Il numero tra parentesi quadre è l'indice del dispositivo nei metadati dell'array, non la sua posizione nella riga e non sempre il suo slot.
• Dopo la sostituzione di un disco, il nuovo membro mantiene in genere un indice superiore allo slot che occupa; per questo nvme4n1p3[4] può trovarsi nello slot 2. mdadm --detail stampa lo slot reale nella colonna RaidDevice, quindi usa quel valore quando la differenza è rilevante.
• (F) dopo un membro indica che il membro è guasto. (S) indica uno spare: il dispositivo è presente ma inattivo e attende un guasto.
• 3906764800 blocks super 1.2 è la dimensione utilizzabile in blocchi da 1 KiB, seguita dal formato dei metadati.
• 512K chunks 2 near-copies è la dimensione dei chunk dello stripe e il layout RAID 10, che in questo caso mantiene due copie di ogni blocco una accanto all'altra.
• [4/4] è il numero di membri atteso dall'array, seguito dal numero attualmente sincronizzato.
• [UUUU] contiene un carattere per ogni slot, nell'ordine degli slot. U indica uno slot attivo e sincronizzato. _ indica uno slot in cui non è attivo alcun dispositivo.
• bitmap: è la write-intent bitmap. Registra le regioni che erano in fase di scrittura, così, quando un membro si disconnette e torna disponibile, vengono sincronizzate solo quelle regioni invece dell'intero disco.

Cosa significano [4/3] e [UU_U] quando si verifica un problema

Un array degradato appare in questo modo.

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]

Leggi insieme le due parentesi. [4/3] indica che uno dei quattro slot non sta contribuendo. [UU_U] indica quale slot, perché il carattere di sottolineatura è il terzo e gli slot sono numerati a partire da zero: quindi lo slot 2 non è attivo. Il flag (F) identifica il dispositivo solo mentre il disco guasto è ancora collegato. Se lo rimuovi dalla macchina, il nome scompare dalla riga, mentre il carattere di sottolineatura resta.

L'array continua a fornire il servizio in questa situazione e, con RAID 10, spesso mantiene una velocità quasi piena. Per questo il problema può passare inosservato. È necessario un controllo esplicito.

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

Il pacchetto mdadm installa un demone di monitoraggio che legge MAILADDR da /etc/mdadm/mdadm.conf. Il nome dell'unità è cambiato tra le varie release, quindi cercalo con l'ultimo comando invece di indovinarlo. L'esecuzione di --test invia immediatamente un messaggio per ogni array. Se dopo l'esecuzione non trovi nulla nella casella di posta, il percorso di invio della posta non funziona; il messaggio che ti interessa sarebbe andato perso nello stesso modo.

Quando è in corso la ricostruzione su un disco sostitutivo, sotto l'array compare una riga di avanzamento.

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 indica una ricostruzione su un disco sostitutivo. resync indica un controllo di consistenza, compreso il controllo iniziale e il ripristino dopo un arresto non regolare. check indica lo scrub avviato in precedenza. La coppia tra parentesi mostra l'avanzamento in blocchi da 1 KiB rispetto al totale per dispositivo, mentre finish è la stima del kernel alla velocità corrente. Linux MD usa /proc/sys/dev/raid/speed_limit_min e speed_limit_max come obiettivi per la velocità di recovery, con override per singolo array in sync_speed_min e sync_speed_max. L'obiettivo massimo predefinito è 200,000 KiB/s per dispositivo; questi obiettivi consentono alla recovery di cedere risorse all'I/O di produzione e non sono limiti rigidi alla velocità.

/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

La sostituzione di un disco su un array che gestisci richiede quattro comandi. L'ultimo esegue il controllo.

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 riga di recovery dovrebbe comparire entro uno o due secondi. La partizione sostitutiva deve essere grande almeno quanto Used Dev Size indicato da mdadm --detail. Una partizione anche solo leggermente più piccola viene rifiutata con un messaggio del tipo not large enough to join array. Partiziona il nuovo disco in modo che corrisponda a quello precedente prima di aggiungerlo.

Cosa puoi e non puoi vedere dall'interno di un VPS

La maggior parte dei guest non può vedere il RAID dell'host, ed è una scelta progettuale. L'hypervisor presenta un solo disco virtuale. Che questo disco sia ricavato da un pool RAID 10 di unità NVMe o risieda su una singola unità è una proprietà dell'host e non viene mostrato all'interno del guest.

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

systemd-detect-virt stampa kvm su un guest KVM, un tipo di container come lxc su un container e none su un sistema bare metal. Su un guest KVM normalmente viene visualizzato un solo vda o sda in lsblk e nessun array in /proc/mdstat, perché nel guest non ce ne sono.

Su un VPS basato su container, questa lettura non è affidabile. I container condividono il kernel dell'host e alcune parti di /proc non sono isolate tramite namespace, quindi i dati visualizzati possono descrivere l'host anziché la porzione assegnata al container. Non considerare nessuno di questi dati una conferma dello storage del tuo VPS. Chiedi al provider quale sia la configurazione e fatti fornire la risposta per iscritto se per te è importante.

Dall'interno puoi verificare il comportamento del disco che ti è stato assegnato. Verificare se il disco del VPS è realmente NVMe illustra i comandi che restituiscono informazioni effettive, mentre cosa include realmente un VPS con SSD spiega a cosa si riferisce l'etichetta riportata nella pagina del piano.

Eseguire RAID all'interno della VPS?

Di solito no. Il motivo sono i domini di errore. Se colleghi due volumi a una VPS e li metti in mirroring con mdadm, entrambi i volumi potrebbero trovarsi sullo stesso array fisico, sullo stesso nodo e dietro la stessa alimentazione. Raddoppieresti il costo di ogni scrittura per una ridondanza che avevi già, ma perderesti comunque entrambe le copie in caso dell'unico guasto realmente rilevante.

Questa configurazione è utile se il provider documenta che i volumi si trovano in domini di errore separati oppure se usi un server dedicato con unità che puoi scegliere direttamente. Negli altri casi, conviene investire il lavoro in copie conservate al di fuori della macchina.

Da cosa non protegge il RAID

Il RAID copre un solo evento: un'unità che smette di funzionare correttamente. Tutto ciò che segue è una scrittura valida, quindi l'array la applica a ogni copia e continua a risultare integro.

• Eliminazione. rm -rf nella directory sbagliata oppure uno script di deploy con una variabile non impostata in un percorso. L'array vede una scrittura valida e la esegue due volte.
• Ransomware. La cifratura è una scrittura. Un array integro salva la versione cifrata su entrambi i lati del mirror.
• Un'applicazione guasta. Un bug che scrive dati errati nel database scrive gli stessi dati errati anche sull'unità ridondante.
• L'intero nodo. Un host che si guasta oppure un account sospeso per errore. Un array può essere perfettamente integro e contemporaneamente irraggiungibile.
• Tu, una settimana dopo. Il file eliminato lunedì scompare da ogni unità già lunedì. Solo una copia creata prima può ripristinarlo.

Neppure gli snapshot sullo stesso storage sono la soluzione. Aiutano contro le eliminazioni, ma vengono persi insieme all'array che li contiene. La caratteristica che rende un backup un backup è che si trova altrove. Backup cifrati fuori dal server con restic è l'altra metà di questa pagina: l'array permette di continuare a erogare il servizio anche quando un'unità si guasta, mentre restic ripristina i dati quando il danno è stato una scrittura che l'array ha applicato correttamente.

FAQ

RAID 10 significa che non servono backup?

No. RAID 10 protegge dal guasto di un'unità. Applica ogni scrittura valida a entrambe le metà di un mirror, quindi una cancellazione o un attacco ransomware raggiunge l'unità ridondante nello stesso istante. Dopo l'evento, l'array risulta integro, perché dal suo punto di vista non si è verificato alcun guasto. Servono comunque copie che risiedano fuori dalla macchina. È inoltre necessario ripristinarne periodicamente una per verificare che sia utilizzabile.

Perché i provider VPS scelgono RAID 10 invece di RAID 5 o RAID 6?

Per due motivi, entrambi legati alle piccole scritture casuali. Una lettura-modifica-scrittura non memorizzata nella cache di un singolo blocco legge i dati e la parità precedenti prima di calcolare la nuova parità. Questo richiede 4 operazioni su RAID 5 e 6 su RAID 6, contro 2 su un mirror a due copie. La scrittura con ricostruzione usa invece i dati invariati, mentre le scritture su una stripe completa non richiedono la rilettura dei dati o della parità precedenti. Una ricostruzione completa di RAID 5 legge quindi ogni unità superstite dall'inizio alla fine. RAID 10 convenzionale con coppie di mirror fisse copia invece dal partner superstite; gli altri layout Linux RAID10 usano più membri come sorgente. Linux MD limita la velocità di ripristino quando sono in corso altre attività. I provider sostengono questo costo in termini di capacità: metà della capacità NVMe raw.

Che cosa significano [U_] o [UU_U] in /proc/mdstat?

Ogni carattere rappresenta uno slot dell'array, nell'ordine degli slot, con un carattere per slot. U indica che lo slot contiene un membro attivo e sincronizzato. _ indica che nello slot non è presente alcun elemento funzionante. [U_] in un mirror a due unità indica che il secondo slot è inattivo e che non è rimasta alcuna ridondanza. Il valore va letto insieme alla coppia che lo precede, dove [4/3] indica che l'array prevede quattro membri e ne ha tre. L'ordine degli slot corrisponde alla colonna RaidDevice di mdadm --detail, non all'ordine in cui i nomi dei dispositivi compaiono sulla riga.

Quante unità può perdere un array RAID 10?

Con RAID 10 convenzionale a due copie e coppie di mirror fisse, una, indipendentemente dalla disposizione. Oltre questo limite, dipende dalla posizione dei guasti. Ogni coppia di mirror può perdere uno dei due membri. Di conseguenza, un array con otto unità può sopravvivere a un massimo di quattro guasti se nessun'altra unità guasta appartiene alla stessa coppia. L'array si interrompe invece dopo due guasti se entrambi colpiscono la stessa coppia. Pianificare considerando il numero garantito, cioè uno, e trattare ogni risultato migliore come un caso fortunato, non come una protezione.

Conviene creare un mirror tra due volumi all'interno della VPS con mdadm?

Di solito no. Due volumi collegati a una VPS risiedono spesso sullo stesso array fisico dello stesso host. In questo caso, il mirror raddoppia il costo di ogni scrittura e non protegge da alcun evento che il RAID dell'host non copra già. Conviene farlo solo quando il provider documenta che i volumi si trovano in domini di guasto separati. In caso contrario, è meglio destinare questo lavoro a backup conservati fuori dalla macchina.