RAID 10 para armazenamento em VPS: como funciona

O que é RAID 10 e por que os hosts de VPS o utilizam

RAID 10 é o esquema de armazenamento mais utilizado pelos hosts de VPS em unidades NVMe (non-volatile memory express) virtualizadas. Cada unidade é espelhada para uma unidade parceira e os dados são distribuídos entre esses pares espelhados. Uma unidade pode falhar sem que o array pare, e a recuperação consiste numa simples cópia a partir da unidade parceira sobrevivente, em vez de um recálculo que leia todas as outras unidades do conjunto.

RAID significa redundant array of independent disks. A sua única função é manter a máquina a servir enquanto um disco está avariado ou a ser substituído. Essa função é a disponibilidade, e disponibilidade não é segurança.

O RAID replica as suas escritas. rm -rf /srv é uma escrita. As duas metades do espelho removem o diretório no mesmo milissegundo, e o array continua a indicar que está íntegro.

Guarde essa frase. O resto desta página explica o que cada nível suporta e o custo de cada um em todas as escritas. As últimas secções contêm os comandos para consultar o estado de um array numa máquina que lhe pertence e a falha que o RAID nunca cobriu.

Os níveis que um comprador de alojamento encontra na prática: 1, 5, 6 e 10

A página de um plano apresenta um número e fica por aí. Esse número responde a duas perguntas: quantas unidades podem falhar e qual é o custo de cada escrita.

RAID 1 é um espelho. Duas unidades armazenam blocos idênticos. Cada escrita é feita nas duas. Qualquer uma das unidades pode servir uma leitura. Uma unidade pode falhar sem perda de dados, e metade da capacidade bruta fica disponível. Não há paridade para calcular, por isso o caminho de escrita é curto.

RAID 5 distribui os dados com um bloco de paridade por stripe. Com n unidades, obtém-se a capacidade de n-1 delas, e o array sobrevive exatamente a uma falha. A paridade não fica numa única unidade dedicada. Roda entre todas, por isso cada unidade transporta dados e paridade.

RAID 6 adiciona um segundo bloco de paridade independente a cada stripe, normalmente identificado por P e Q. Sobrevive à falha simultânea de quaisquer duas unidades. Isto é mais importante do que parece, porque a segunda falha ocorre com maior frequência durante a reparação da primeira.

RAID 10 é um stripe de espelhos. As unidades são espelhadas em pares, e os dados são distribuídos entre os pares. A capacidade disponível é metade do total bruto, tal como no RAID 1, com o paralelismo do striping.

Também aparece escrito como RAID 1+0, que é a descrição correta: primeiro cria-se o espelho e depois faz-se o stripe entre os espelhos. RAID 0+1 segue a ordem inversa: primeiro faz-se o stripe e depois espelham-se os dois stripes. É pior, porque a falha de uma unidade deixa um stripe inteiro indisponível e a reparação tem de copiar todo o outro lado.

Linux é um caso especial que vale a pena conhecer. O raid10 do kernel é uma única personalidade, em vez de duas camadas sobrepostas, por isso funciona com um número ímpar de unidades e tem layouts (near, far, offset) que uma configuração aninhada não consegue expressar. É por isso que a linha de estado num sistema Linux apresenta 2 near-copies em vez de identificar dois 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
  }
]

Oito unidades de 1 TB fornecem 7 TB de espaço disponível em RAID 5 e 4 TB em RAID 10. Essa diferença representa dinheiro real e explica por que razão a paridade continua a ser proposta. RAID 6 sobrevive a 2 falhas, independentemente do padrão. RAID 10 garante apenas 1, porque a segunda falha perigosa é a que atinge o par da unidade que já falhou. Sobrevive até 4 falhas quando nenhuma combinação de duas falhas partilha um par, mas isso é sorte, não uma propriedade do projeto.

O custo de cada nível em cada escrita

Uma escrita num mirror corresponde a duas escritas, emitidas ao mesmo tempo para ambos os membros. Uma escrita numa stripe de paridade exige mais trabalho, porque o bloco de paridade dessa stripe fica incorreto e tem de ser recalculado.

O controlador não consegue recalcular a paridade apenas a partir do bloco novo. Primeiro precisa do bloco de dados antigo e do bloco de paridade antigo. Por isso, uma pequena escrita aleatória em RAID 5 transforma-se em read, read, write, write. O RAID 6 mantém um segundo código de redundância, portanto a mesma escrita transforma-se em read, read, read, write, write, write.

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

Uma pequena escrita aleatória custa 6 operações de dispositivo no RAID 6 e 2 no RAID 10. Estes valores subestimam a diferença de latência. As duas escritas do mirror são enviadas em paralelo, por isso o guest espera pela mais lenta das duas. O caminho da paridade contém uma leitura que tem de terminar antes de a nova paridade poder ser calculada, por isso o guest espera primeiro por uma leitura e depois por uma escrita. Num host ocupado, essa leitura fica na fila atrás das operações de I/O dos restantes utilizadores.

Existe uma exceção importante. Uma escrita suficientemente grande para preencher uma stripe inteira não precisa dos dados antigos, porque todos os blocos da stripe estão a ser substituídos. A paridade é calculada a partir do que já está na memória, e o custo passa a ser uma escrita adicional. É por isso que o RAID 5 apresenta bons resultados num benchmark sequencial, mas tem um comportamento fraco com uma carga mista de pequenas escritas provenientes de muitos tenants. Teste o padrão que realmente executa: fazer corretamente o benchmark de um disco VPS significa usar I/O aleatório com uma profundidade de fila realista, e não um único dd grande.

Por que a reconstrução é a parte perigosa

Uma reconstrução de paridade precisa reconstruir a unidade em falta a partir de todos os restantes dados. Por isso, lê 7 unidades sobreviventes, do primeiro bloco ao último. Uma reconstrução de RAID 10 lê 1: a unidade parceira do espelho da unidade avariada e nada mais.

Daqui resultam dois custos. O primeiro é o tempo, porque a reconstrução fica limitada pela unidade sobrevivente mais lenta e pelos cálculos de paridade adicionais. O segundo é a carga. Todas as unidades de um conjunto de paridade ficam ocupadas durante toda a operação, por isso todas as máquinas convidadas desse nó sofrem maior latência até à conclusão. No RAID 10, um par fica ocupado e os restantes pares continuam a servir à velocidade normal.

Durante a mesma operação existe também um risco de integridade. Um array RAID 5 com uma unidade avariada já não tem redundância. Assim, um setor ilegível em qualquer unidade sobrevivente deixa de ser recuperável. A reconstrução é a operação que lê todos os setores, incluindo os que ninguém acedeu durante um ano. Os valores publicados nas fichas técnicas indicam que um disco rígido de consumo pode ter cerca de um erro de leitura irrecuperável por cada 10^14 bits lidos, enquanto uma unidade NVMe empresarial pode ter um por cada 10^17 bits ou menos. Estas são especificações dos fabricantes, não medições. Ainda assim, a proporção explica por que o antigo aviso de que uma reconstrução de RAID 5 iria falhar se referia a discos magnéticos de grande capacidade e por que é muito menos relevante em NVMe. O argumento relativo à carga aplica-se a qualquer suporte.

Detete os erros latentes antes que uma reconstrução os encontre, executando um scrub. Debian e Ubuntu incluem um scrub periódico para arrays md. O mecanismo varia entre versões. Verifique qual está disponível no seu sistema e depois execute uma passagem manualmente.

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 regressa a idle quando a passagem termina, e mismatch_cnt deve apresentar 0. Um valor acima de zero num espelho significa que as duas metades não coincidem e que o kernel não consegue determinar qual está correta, porque nenhuma cópia contém um checksum. Alguns desencontros são inofensivos. As partições swap são a origem habitual: o kernel pode escrever uma página que se altera enquanto está a ser lida. Um contador crescente num array de dados indica que deve substituir uma unidade.

Por que os fornecedores de VPS padronizam o uso de RAID 10 para NVMe

Um nó de hypervisor não executa uma única carga de trabalho. Executa dezenas de guests independentes, cujas operações de I/O chegam intercaladas, como um fluxo de pequenas gravações sem localidade entre elas. Esse é exatamente o padrão em que o ciclo de leitura-modificação-gravação da paridade tem o maior custo. É também o padrão que um nó partilhado apresenta durante todo o dia.

O comportamento durante a reconstrução reforça essa escolha. Uma unidade com falha num nó com paridade torna mais lentos todos os guests do servidor durante horas. Uma unidade com falha num nó RAID 10 torna mais lenta apenas uma réplica, e a cópia é executada sequencialmente à velocidade da unidade. Os fornecedores vendem uma latência sem picos, por isso pagam por ela com capacidade: metade da capacidade bruta de NVMe é usada no espelho.

A capacidade das unidades aponta na mesma direção. À medida que as unidades aumentam de capacidade, a janela de reconstrução fica maior. Em configurações com paridade, essa é a janela em que tudo fica lento e nada está protegido. Pela mesma razão, implementações ZFS para virtualização usam pools de vdevs espelhados em vez de raidz largos: um resilver de um espelho copia apenas os blocos efetivamente utilizados, num único par.

Isto não significa que RAID 10 seja sempre a escolha correta. Um destino de backup recebe gravações sequenciais longas e é lido raramente, por isso RAID 6 oferece uma relação melhor. Suporta duas falhas e devolve a maior parte da capacidade disponível. É a carga de trabalho que decide, não o número. Para um plano que esteja a escolher hoje, o suporte de armazenamento normalmente importa mais do que o layout usado sobre ele, e a mudança de SATA SSD para NVMe é maior do que qualquer diferença de RAID em ambos.

Como ler /proc/mdstat

Execute estes comandos numa máquina onde é proprietário do array: um servidor dedicado, um equipamento em casa ou uma VPS com dois volumes anexados que montou pessoalmente. Leia a sua própria saída. Os blocos abaixo são exemplos, escritos para que possa comparar o formato com o resultado obtido.

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

Um RAID 10 saudável com quatro discos apresenta uma saída semelhante a esta.

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>

Cada parte contém informação.

• Personalities lista os módulos md carregados pelo kernel em execução. A presença de raid10 nessa lista significa que o código está disponível, e nada mais.
• md0 : active raid10 é o dispositivo do array, o respetivo estado e o nível.
• Os nomes que aparecem depois são os membros. O número entre parênteses retos é o índice do dispositivo nos metadados do array, não a posição na linha e nem sempre a respetiva ranhura.
• Depois de substituir um disco, o novo membro normalmente mantém um índice superior ao da ranhura que ocupa. Por isso, nvme4n1p3[4] pode estar na ranhura 2. mdadm --detail apresenta a ranhura real na coluna RaidDevice, portanto use esse valor quando a diferença for relevante.
• (F) depois de um membro significa que este está com falhas. (S) significa spare: presente, inativo e à espera que algo falhe.
• 3906764800 blocks super 1.2 é o tamanho utilizável em blocos de 1 KiB, seguido do formato dos metadados.
• 512K chunks 2 near-copies é o tamanho do bloco de stripe e o layout RAID 10. Neste caso, mantém duas cópias de cada bloco lado a lado.
• [4/4] é o número de membros esperado pelo array, seguido do número atualmente sincronizado.
• [UUUU] é um caráter por ranhura, pela ordem das ranhuras. U é uma ranhura ativa e sincronizada. _ é uma ranhura sem nenhum dispositivo funcional.
• bitmap: é o mapa de intenção de escrita. Regista as regiões que estavam a ser escritas, para que um membro que fique indisponível e volte a estar disponível sincronize essas regiões em vez de sincronizar o disco inteiro.

O que significam [4/3] e [UU_U] quando existe um problema

Um array degradado apresenta este formato.

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]

Leia os dois conjuntos de parênteses retos em conjunto. [4/3] indica que uma das quatro ranhuras não está a contribuir. [UU_U] indica qual é, porque o sublinhado é o terceiro caráter e as ranhuras são numeradas a partir de zero. Portanto, a ranhura 2 está indisponível. O marcador (F) identifica o dispositivo apenas enquanto o disco com falha ainda está ligado. Retire-o da máquina e o nome desaparece da linha, mas o sublinhado permanece.

O array continua a disponibilizar dados durante tudo isto. Num RAID 10, muitas vezes continua a fazê-lo quase à velocidade máxima. Por isso, ninguém nota o problema apenas pelo desempenho. É necessário algum mecanismo para o alertar.

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

O pacote mdadm instala um daemon de monitorização que lê MAILADDR a partir de /etc/mdadm/mdadm.conf. O nome da unidade mudou entre releases, portanto procure-o com o último comando em vez de o adivinhar. O comando --test envia imediatamente uma mensagem por array. Uma caixa de entrada vazia depois desse comando significa que o percurso de correio está avariado. Assim, a mensagem que realmente lhe interessa teria sido perdida da mesma forma.

Quando uma substituição está a ser reconstruída, aparece uma linha de progresso sob o 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 é uma reconstrução para um disco de substituição. resync é a primeira passagem de consistência sobre um array recém-criado. check é a verificação que iniciou acima. O par entre parênteses mostra o progresso em blocos de 1 KiB face ao total por dispositivo. finish é a estimativa do kernel à velocidade atual. Essa velocidade é limitada por /proc/sys/dev/raid/speed_limit_min e speed_limit_max. Esses limites existem para impedir que uma reconstrução prive de recursos a I/O de produção.

/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

Substituir um disco num array de que é proprietário requer quatro comandos. O último é a verificação.

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

A linha de recuperação deve aparecer dentro de um ou dois segundos. A partição de substituição tem de ser pelo menos tão grande como Used Dev Size de mdadm --detail. Uma partição ligeiramente mais pequena é rejeitada com uma mensagem do tipo not large enough to join array. Particione o novo disco para corresponder ao disco antigo antes de o adicionar.

O que pode e não pode ver dentro de um VPS

A maioria dos guests não consegue ver o RAID do host, e isso é intencional. O hypervisor disponibiliza um disco virtual. Esse disco pode ser criado a partir de um pool RAID 10 de unidades NVMe ou estar num único disco. Essa é uma propriedade do host e não aparece dentro do guest.

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

systemd-detect-virt imprime kvm num guest KVM, um tipo de contentor como lxc num contentor e none em bare metal. Num guest KVM, normalmente vê um único vda ou sda em lsblk e nenhum array em /proc/mdstat, porque não existem arrays dentro do guest.

Num VPS baseado em contentores, essa leitura não é fiável. Os contentores partilham o kernel do host, e partes de /proc não são isoladas por namespace. Por isso, o que lê pode descrever o host em vez da sua parte. Não trate nenhum desses dados como um facto sobre o seu próprio armazenamento. Pergunte ao fornecedor qual é a disposição do armazenamento e obtenha a resposta por escrito se isso for importante para si.

A partir do interior, pode verificar o comportamento do disco que lhe foi atribuído. Verificar se o disco do seu VPS é realmente NVMe apresenta os comandos que fornecem dados reais, e o que um VPS com SSD inclui realmente explica o que o rótulo na página do plano afirma incluir.

Você deve usar RAID dentro da sua VPS?

Normalmente, não. O motivo são os domínios de falha. Se anexar dois volumes a uma VPS e os espelhar com mdadm, ambos podem estar no mesmo array físico, no mesmo nó e ligados à mesma fonte de alimentação. O custo de cada escrita duplicaria por uma redundância que já existia, e continuaria a perder ambas as cópias na única falha relevante.

Vale a pena fazê-lo quando o fornecedor documenta que os volumes estão em domínios de falha separados ou quando utiliza um servidor dedicado com discos sob o seu controlo. Caso contrário, é melhor investir o esforço em cópias que saiam da máquina.

O que o RAID não protege

O RAID cobre um evento: uma unidade que deixa de funcionar corretamente. Tudo o que é descrito abaixo é uma gravação válida, por isso o array aplica-a a todas as cópias e mantém o estado saudável.

• Eliminação. rm -rf no diretório errado ou um script de deploy com uma variável não definida num caminho. O array vê uma gravação válida e executa-a duas vezes.
• Ransomware. A encriptação é uma gravação. Um array saudável armazena a versão encriptada nas duas metades do espelho.
• Uma aplicação com falhas. Um bug que grava dados inválidos na sua base de dados grava os mesmos dados na unidade redundante.
• O nó inteiro. Um host que falha ou uma conta suspensa por engano. Um array pode estar perfeito e, ao mesmo tempo, inacessível.
• Você próprio, uma semana depois. O ficheiro eliminado na segunda-feira desaparece de todas as unidades nesse dia. Apenas uma cópia criada antes disso o pode recuperar.

Os snapshots no mesmo armazenamento também não resolvem o problema. Ajudam contra eliminações, mas desaparecem com o array onde estão armazenados. O que torna uma cópia de segurança numa cópia de segurança é estar noutro local. Cópias de segurança encriptadas fora do servidor com restic é a outra metade desta página: o array mantém o serviço disponível quando uma unidade falha, e o restic recupera os seus dados quando o dano resulta de uma gravação que o array aceitou.

FAQ

RAID 10 significa que não preciso de backups?

Não. O RAID 10 protege contra uma unidade que deixa de funcionar. Cada escrita válida é aplicada às duas metades de um espelho, por isso uma eliminação ou uma execução de ransomware chega à unidade redundante no mesmo instante. O array continua a indicar que está íntegro, porque, do seu ponto de vista, nada falhou. Continua a precisar de cópias armazenadas fora da máquina e deve restaurar uma delas ocasionalmente para confirmar que funcionam.

Porque é que os fornecedores de VPS escolhem RAID 10 em vez de RAID 5 ou RAID 6?

Por duas razões, ambas relacionadas com pequenas escritas aleatórias. Uma escrita de paridade precisa de ler os dados antigos e a paridade antiga antes de calcular a nova paridade. Por isso, uma pequena escrita custa 4 operações no RAID 5 e 6 no RAID 6, contra 2 num espelho. Uma reconstrução de paridade também lê todas as unidades sobreviventes do princípio ao fim. Isto abranda todas as máquinas convidadas do nó durante horas. Numa reconstrução de RAID 10, uma unidade é copiada para outra e os restantes pares não são afetados. Os fornecedores pagam esta vantagem com capacidade: metade da capacidade bruta de NVMe.

O que significa [U_] ou [UU_U] em /proc/mdstat?

Cada carácter representa um slot do array, pela ordem dos slots, com um carácter por slot. U significa que esse slot contém um membro ativo e sincronizado. _ significa que não existe nenhum membro funcional nesse slot. [U_] num espelho de duas unidades significa que o segundo slot está indisponível e já não existe redundância. Leia esta informação em conjunto com o par que aparece antes dela, no qual [4/3] indica que o array espera quatro membros e tem três. A ordem dos slots corresponde à coluna RaidDevice de mdadm --detail, não à ordem em que os nomes dos dispositivos aparecem na linha.

Quantas unidades pode um array RAID 10 perder?

Uma, independentemente do padrão de falha. A partir daí, depende de onde ocorrem as falhas. Cada par espelhado pode perder um dos seus dois membros. Assim, um array com oito unidades sobrevive a até quatro falhas se nenhuma delas afetar o mesmo par. O array falha com duas falhas se ambas afetarem o mesmo par. Planeie com base no número garantido, que é um, e considere qualquer valor acima disso uma questão de sorte, não de proteção.

Devo espelhar dois volumes dentro da minha VPS com mdadm?

Normalmente, não. Dois volumes ligados à mesma VPS residem muitas vezes no mesmo array físico e no mesmo host. Nesse caso, o espelhamento duplica o custo de cada escrita e não protege contra nada que o RAID do host já não cubra. Só vale a pena fazê-lo quando o fornecedor documenta que os volumes estão em domínios de falha separados. Caso contrário, use esse esforço para manter backups fora da máquina.