RAID 10 per lo storage VPS: come funziona

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

RAID 10 è il layout di archiviazione utilizzato dalla maggior parte dei provider VPS su unità NVMe (non-volatile memory express) virtualizzate. 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 arrestare l'array. Il ripristino consiste in una semplice copia dall'unità partner ancora funzionante, 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 segnalarsi come integro.

Conserva questa frase. Il resto di questa pagina descrive quali guasti ogni livello è in grado di tollerare e quale costo comporta per ogni scrittura. Nelle sezioni finali sono riportati i comandi per leggere lo stato di un array su una macchina di tua proprietà e il tipo di 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 drive possono guastarsi e quanto costa ogni scrittura.

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

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

RAID 6 aggiunge un secondo blocco di parità indipendente a ogni stripe, indicato di solito con P e Q. Sopravvive al guasto simultaneo di due drive qualsiasi. Questo è più importante di quanto sembri, perché il secondo guasto si verifica più spesso durante la riparazione del primo.

RAID 10 è uno stripe di mirror. I drive vengono configurati in coppie in mirror e i dati vengono distribuiti tra le coppie. La capacità utilizzabile è metà del totale raw, come in RAID 1, con il parallelismo dello striping aggiunto.

È possibile trovarlo anche scritto come RAID 1+0, che è la descrizione corretta: prima il mirror, poi lo striping tra i mirror. RAID 0+1 segue l'ordine inverso: prima lo striping e poi il mirror dei due stripe. È una configurazione peggiore, perché il guasto di un drive rende indisponibile un intero stripe e la riparazione deve copiare l'intero altro lato.

Linux è un caso particolare che vale la pena conoscere. Il raid10 del kernel è una singola personality, non due livelli sovrapposti, quindi può funzionare con un numero dispari di drive e dispone di 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 (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
  }
]

Otto drive da 1 TB forniscono 7 TB di spazio utilizzabile con RAID 5 e 4 TB con RAID 10. La differenza è concreta e spiega perché la parità continua a essere proposta. RAID 6 sopravvive a 2 guasti in qualunque combinazione. RAID 10 garantisce soltanto 1, perché il secondo guasto più pericoloso è quello che colpisce il partner del drive già guasto. Può sopravvivere fino a 4 guasti quando nessuna coppia subisce due guasti, ma si tratta di fortuna, non di una proprietà del progetto.

Il costo di ogni livello per ogni scrittura

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

Il controller non può ricalcolare la parità usando soltanto il nuovo blocco. Prima deve leggere il vecchio blocco dati e il vecchio blocco di parità. Di conseguenza, una piccola scrittura casuale su RAID 5 diventa: lettura, lettura, scrittura, scrittura. RAID 6 deve mantenere un secondo codice di ridondanza, quindi la stessa scrittura diventa: lettura, lettura, lettura, scrittura, scrittura, scrittura.

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

Una piccola scrittura casuale richiede 6 operazioni sui dispositivi con RAID 6 e 2 con RAID 10. Questi conteggi sottostimano la differenza di latenza. Le due scritture del mirror vengono eseguite in parallelo, quindi il guest attende quella più lenta. Nel percorso con parità, una lettura 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 si accoda dietro alle operazioni I/O degli altri utenti.

Esiste un'eccezione importante. Una scrittura abbastanza grande da riempire uno stripe completo non richiede i dati precedenti, perché ogni blocco dello stripe viene sostituito. La parità viene calcolata a partire dai dati già presenti in memoria e il costo si riduce a una sola scrittura aggiuntiva. Per questo RAID 5 può dare buoni risultati in un benchmark sequenziale, ma comportarsi male sotto un carico misto composto da piccole scritture provenienti da molti tenant. Testa il pattern che esegui realmente: eseguire correttamente il benchmark di un disco 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 della parità deve ricostruire l'unità mancante usando tutti gli altri dati, quindi legge 7 unità sopravvissute, dal primo blocco all'ultimo. Una ricostruzione RAID 10 legge 1: il partner mirror dell'unità guasta e nient'altro.

Da questo derivano due costi. Il primo è il tempo, perché la ricostruzione è limitata dall'unità sopravvissuta più lenta e dai calcoli della parità. Il secondo è il carico. Tutte le unità di un gruppo con parità restano occupate per l'intera durata dell'operazione, quindi ogni guest su quel nodo registra una latenza maggiore fino al completamento. Con RAID 10 è occupata una sola coppia, mentre le altre continuano a fornire il servizio alla velocità normale.

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à sopravvissuta non è più recuperabile. La 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 hard disk consumer circa un errore di lettura non recuperabile ogni 10^14 bit letti, mentre per un'unità NVMe enterprise il valore è uno ogni 10^17 bit o migliore. Si tratta di specifiche dei produttori, non di misurazioni, ma il rapporto spiega perché il vecchio avvertimento secondo cui una ricostruzione RAID 5 sarebbe destinata a fallire riguardasse i grandi dischi magnetici e perché oggi sia molto meno valido per le unità NVMe. L'argomento relativo al carico resta valido per qualsiasi supporto.

Individua 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 cambia tra le release. Verifica quindi quale meccanismo è presente nel sistema e avvia manualmente un 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 torna a idle quando il pass termina, e mismatch_cnt dovrebbe riportare 0. Un valore maggiore di zero su un mirror indica che le due metà non coincidono e che il kernel non può stabilire quale sia corretta, perché nessuna delle due copie contiene un checksum. Alcune discrepanze sono innocue; la causa più comune sono le partizioni di swap, perché il kernel può scrivere una pagina che cambia mentre viene letta. Un conteggio in aumento su un array di dati indica un'unità da sostituire.

Perché i provider VPS scelgono di norma RAID 10 per NVMe

Un nodo hypervisor non esegue un solo carico di lavoro. Esegue decine di guest non correlati, i cui I/O arrivano intercalati come un flusso di piccole scritture senza località tra loro. Questo è esattamente il tipo di accesso 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 è naturale. Un drive guasto su un nodo con parità rallenta per ore ogni guest presente sul server. Un drive guasto su un nodo RAID 10 rallenta una sola coppia, e la copia procede in sequenza alla velocità del drive. I provider vendono una latenza stabile, senza picchi, quindi la ottengono sacrificando capacità: metà della capacità raw 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; sui sistemi con parità è proprio l'intervallo in cui tutto è lento e nulla è protetto. Per lo stesso motivo, nelle implementazioni ZFS per la virtualizzazione si usano pool di vdev in mirror invece di raidz estesi: il resilver di un mirror copia solo i blocchi effettivamente in uso, su una singola coppia.

Questo non significa che RAID 10 sia sempre la scelta corretta. Un target di backup viene scritto con lunghe sequenze e letto raramente, quindi RAID 6 è più conveniente in quel caso. Resiste a due guasti e restituisce gran parte della capacità disponibile. La scelta dipende dal carico di lavoro, non dal numero. Per un piano che stai scegliendo oggi, il supporto di archiviazione conta di solito più del layout che vi viene configurato, e il passaggio da SATA SSD a NVMe è più rilevante di qualsiasi differenza tra RAID sull'uno o sull'altro.

Come leggere /proc/mdstat

Esegui questi comandi su una macchina di cui possiedi l'array: un server dedicato, un computer di casa oppure una VPS con due volumi collegati e assemblati da te. Leggi il tuo output. I blocchi seguenti sono esempi, riportati per esteso così puoi confrontare la struttura con quella ottenuta.

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 indica il dispositivo dell'array, il relativo stato e il livello RAID.
• I nomi successivi sono i membri. Il numero tra parentesi quadre è l'indice del dispositivo nei metadati dell'array, non la posizione sulla riga e non sempre lo slot.
• Dopo la sostituzione di un disco, il nuovo membro conserva in genere un indice superiore a quello dello slot che occupa. Per questo nvme4n1p3[4] può trovarsi nello slot 2. mdadm --detail stampa lo slot effettivo nella colonna RaidDevice, quindi usa quel valore quando la differenza è importante.
• (F) dopo un membro indica che il membro è guasto. (S) indica uno spare: il dispositivo è presente, inattivo e in attesa di un guasto.
• 3906764800 blocks super 1.2 indica la dimensione utilizzabile in blocchi da 1 KiB, seguita dal formato dei metadati.
• 512K chunks 2 near-copies indica la dimensione dei chunk di stripe e il layout RAID 10. In questo caso, il layout conserva due copie di ogni blocco una accanto all'altra.
• [4/4] indica il numero di membri attesi 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 senza alcun dispositivo funzionante.
• bitmap: è la write-intent bitmap. Registra le regioni in fase di scrittura, così, quando un membro si disconnette e torna disponibile, la sincronizzazione viene eseguita su quelle regioni invece che sull'intero disco.

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

Un array degradato appare così.

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 all'array. [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 è inattivo. Il flag (F) identifica il dispositivo soltanto finché il disco guasto è ancora collegato. Rimuovilo dalla macchina e il nome scompare dalla riga, mentre il carattere di sottolineatura resta.

L'array continua a fornire il servizio in questa situazione. Con RAID 10 spesso mantiene una velocità vicina a quella massima, quindi il problema può non essere percepibile durante l'uso normale. È 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 daemon di monitoraggio che legge MAILADDR da /etc/mdadm/mdadm.conf. Il nome dell'unità è cambiato tra le diverse 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 la casella di posta è vuota, il percorso di posta non funziona. Anche il messaggio che ti interessa sarebbe quindi andato perso nello stesso modo.

Quando è in corso la ricostruzione dopo la sostituzione di un disco, 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 il primo controllo di consistenza su un array appena creato. check indica lo scrub avviato in precedenza. La coppia tra parentesi mostra l'avanzamento in blocchi da 1 KiB rispetto al totale per dispositivo. finish è la stima del kernel per il tempo rimanente alla velocità corrente. La velocità è limitata da /proc/sys/dev/raid/speed_limit_min e speed_limit_max. Questi limiti impediscono alla ricostruzione di saturare l'I/O di produzione.

/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 di tua proprietà richiede quattro comandi. L'ultimo comando esegue la verifica.

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 ripristino dovrebbe comparire entro uno o due secondi. La partizione sostitutiva deve avere almeno la dimensione indicata da Used Dev Size in 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à del mirror, quindi una cancellazione o l'esecuzione di un ransomware raggiunge l'unità ridondante nello stesso istante. In seguito l'array risulta integro, perché dal suo punto di vista non si è verificato alcun guasto. Servono comunque copie conservate fuori dalla macchina e occorre 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 scrittura con parità richiede la rilettura dei dati e della parità precedenti prima di poter calcolare la nuova parità. Di conseguenza, una piccola scrittura costa 4 operazioni su RAID 5 e 6 su RAID 6, contro 2 su un mirror. Una ricostruzione con parità legge poi ogni unità superstite dall'inizio alla fine. Questo rallenta per ore ogni guest sul nodo. Una ricostruzione RAID 10, invece, copia i dati da un'unità all'altra e lascia invariati gli altri mirror. Il costo per i provider è la capacità: metà della capacità grezza degli NVMe.

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

Ogni carattere rappresenta uno slot dell'array, nell'ordine degli slot, con un carattere per ogni slot. U indica che lo slot contiene un membro attivo e sincronizzato. _ indica che nello slot non è presente alcun membro funzionante. In un mirror a due unità, [U_] indica che il secondo slot è inattivo e che non è più disponibile alcuna ridondanza. Va letto insieme alla coppia che lo precede: [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 nella riga.

Quante unità può perdere un array RAID 10?

Una, indipendentemente dalla disposizione dei guasti. Oltre questo limite, dipende da dove si verificano i guasti. Ogni coppia mirror può perdere uno dei due membri. Un array con otto unità può quindi sopravvivere a un massimo di quattro guasti se nessuna coppia ne perde entrambe. Si arresta invece al secondo guasto se entrambi colpiscono la stessa coppia. Pianificare considerando il numero garantito, cioè uno, e considerare qualsiasi valore superiore come una situazione fortunata, non come una protezione.

Devo creare un mirror tra due volumi all'interno della mia 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 usare queste risorse per creare backup conservati fuori dalla macchina.