RAID 10 para armazenamento em VPS: como funciona

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

RAID 10 é o esquema de armazenamento mais utilizado pelos provedores de VPS em unidades NVMe (non-volatile memory express) virtualizadas. No esquema convencional com duas cópias, ele espelha cada unidade numa unidade parceira e depois distribui os dados entre esses pares espelhados. Uma unidade pode falhar sem interromper a matriz, e a recuperação é uma simples cópia a partir da unidade parceira que continua disponível, 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 é disponibilidade, e disponibilidade não é segurança.

O RAID replica as suas gravações. rm -rf /srv é uma gravação. As duas metades do espelho eliminam o diretório no mesmo milissegundo, e a matriz continua a indicar que está íntegra.

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

Os níveis que um comprador de alojamento realmente encontra: 1, 5, 6 e 10

Uma página de planos indica 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 mantêm blocos idênticos. Cada escrita é feita nas duas. Qualquer unidade pode responder a 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 é striping 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 unidade dedicada. É distribuída por todas as unidades, por isso cada unidade contém dados e paridade.

RAID 6 acrescenta um segundo bloco de paridade independente a cada stripe, normalmente identificado como 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 recuperação da primeira.

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

Também verá a designação RAID 1+0, que é a descrição correta: primeiro cria-se o espelho e depois faz-se striping entre os espelhos. RAID 0+1 usa a ordem inversa: primeiro faz-se striping e depois espelham-se os dois stripes. É uma opção pior, porque a falha de uma unidade coloca um stripe inteiro fora de serviço e a recuperação tem de copiar todo o outro lado.

O Linux é um caso especial que vale a pena conhecer. O raid10 do kernel é uma personalidade única, e não duas camadas empilhadas. Por isso, funciona com um número ímpar de unidades e tem layouts (near, far, offset) que uma configuração aninhada não consegue representar. É por isso que a linha de estado num sistema Linux mostra 2 near-copies em vez de indicar dois arrays.

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

Oito unidades de 1 TB fornecem 7 TB de espaço utilizá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. O RAID 6 sobrevive a 2 falhas, independentemente do padrão. O RAID 10 garante apenas 1, porque a segunda falha perigosa é a que ocorre na unidade correspondente à que já falhou. Sobrevive a até 4 falhas quando nenhuma falha ocorre no mesmo par, mas isso é sorte, não uma propriedade do design.

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.

No caso de read-modify-write, o controlador lê primeiro os dados antigos e a paridade antiga. Uma sobrescrita de um único bloco, sem cache, em RAID 5 passa então a ser read, read, write, write. O RAID 6 mantém dois blocos de paridade, por isso o read-modify-write passa a ser read, read, read, write, write, write. O Linux também usa reconstruct-write, lendo os dados inalterados para calcular a paridade. Num RAID 5 com três discos, essa sobrescrita pode exigir uma leitura de dados e duas escritas; num RAID 6 com quatro discos, uma leitura de dados e três escritas. Quatro e seis são contagens de operações de read-modify-write, não custos fixos para todas as pequenas escritas aleatórias.

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

Um read-modify-write de um único bloco, sem cache, custa 6 operações nos dispositivos em RAID 6, contra 2 para a mesma sobrescrita num RAID 10 com duas cópias. Estas contagens subestimam a diferença de latência. As duas escritas nos mirrors são emitidas em paralelo, por isso o guest espera pelo mais lento dos dois. O percurso de read-modify-write 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 em 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 overhead diminui para uma escrita de paridade por stripe no RAID 5 ou duas no RAID 6, sem prereads. É por isso que o RAID 5 apresenta bons resultados num benchmark sequencial, mas se comporta mal com uma carga mista de pequenas escritas provenientes de vários 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 completa de RAID 5 precisa reconstruir a unidade em falta a partir de todos os restantes dados. Por isso, no exemplo com oito unidades, lê 7 unidades sobreviventes, do primeiro bloco ao último. Com pares de espelhos fixos, uma reconstrução de RAID 10 lê 1: a unidade parceira do espelho da unidade avariada, e nada mais. Outros layouts Linux RAID10 distribuem as cópias de forma diferente: a reconstrução de um membro do layout near de três dispositivos lê os dois membros sobreviventes.

Daqui resultam dois custos. O primeiro é o tempo, porque a reconstrução é limitada pelas unidades sobreviventes, pelo trabalho de reconstrução e pelas metas de velocidade de recuperação. O segundo é a carga. Uma reconstrução com paridade distribui a I/O pelas unidades sobreviventes. Com pares de espelhos fixos, uma reconstrução de RAID 10 concentra essa I/O num par; os recursos partilhados do controlador e do host continuam a afetar os outros pares.

Existe um risco de integridade durante a mesma janela. 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 consultou durante um ano. Os valores publicados nas fichas técnicas colocam um disco rígido de consumo perto de um erro de leitura irrecuperável por cada 10^14 bits lidos, e uma unidade NVMe empresarial em um por cada 10^17 ou melhor. Estas são especificações dos fornecedores, 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 esse aviso é muito menos aplicável a NVMe. O argumento da carga aplica-se a qualquer suporte.

Detete os erros latentes antes que uma reconstrução o faça, executando um scrub. Debian e Ubuntu incluem um scrub periódico para arrays md, mas o mecanismo varia entre versões. Verifique qual tem instalado e depois inicie 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 volta a idle quando a passagem termina, e mismatch_cnt deve apresentar 0. Um número superior a zero num espelho significa que as duas metades divergem e que o kernel não consegue indicar qual está correta, porque nenhuma cópia contém um checksum. Algumas divergências são inofensivas, e as partições swap são a origem habitual: o kernel pode escrever uma página que se altera enquanto está a ser processada. Um contador crescente num array de dados exige investigação; o contador, por si só, não identifica qual unidade deve ser substituída.

Por que os fornecedores de VPS optam por RAID 10 para NVMe

Um nó de hipervisor não executa uma única carga de trabalho. Executa dezenas de máquinas convidadas sem relação entre si, e a respetiva E/S chega intercalada, como um fluxo de pequenas escritas sem localidade entre elas. Esse é exatamente o padrão em que o ciclo de leitura-modificação-escrita da paridade tem o maior custo, e é o padrão que um nó partilhado processa durante todo o dia.

O comportamento durante a reconstrução reforça essa escolha. Uma unidade com falha num nó com paridade acrescenta trabalho de reconstrução em todas as unidades sobreviventes. Com pares de espelhos fixos, uma unidade com falha num nó RAID 10 acrescenta E/S de reconstrução apenas a um par, e o Linux MD abranda a recuperação quando existe outra atividade. Os fornecedores vendem latência sem picos, por isso pagam esse desempenho com capacidade: metade da capacidade bruta de NVMe é usada pelo espelho.

A capacidade das unidades aponta na mesma direção. À medida que as unidades ficam maiores, a janela de reconstrução aumenta. No RAID 5, essa é a janela em que a reconstrução adiciona carga e deixa de existir redundância; o RAID 6 mantém proteção contra a falha de mais uma unidade. É pela mesma razão que as 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 usados, num único par.

Nada disso torna o RAID 10 correto em todos os casos. Um destino de cópias de segurança recebe escritas sequenciais longas e é lido raramente, por isso o RAID 6 é a melhor opção nesse cenário. Sobrevive a duas falhas e devolve a maior parte da capacidade. A carga de trabalho decide, não o número. Para um plano que esteja a escolher hoje, o meio de armazenamento normalmente importa mais do que o layout aplicado sobre ele, e a passagem de SATA SSD para NVMe é mais significativa do que qualquer diferença entre níveis RAID em qualquer um dos dois.

Como ler /proc/mdstat

Execute estes comandos numa máquina onde o array é seu: um servidor dedicado, um computador em casa ou uma VPS com dois volumes anexados que você mesmo montou. Leia a sua própria saída. Os blocos abaixo são exemplos, escritos para que você 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 unidades 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 dessa saída contém informações.

• 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 estado dele e o nível RAID.
• Os nomes seguintes são os membros. O número entre colchetes é o índice do dispositivo nos metadados do array. Ele não indica a posição na linha e nem sempre corresponde ao slot.
• Depois da substituição de uma unidade, o novo membro normalmente mantém um índice maior que o slot que ocupa. Por isso, nvme4n1p3[4] pode estar no slot 2. mdadm --detail mostra o slot real na coluna RaidDevice. Use essa coluna quando essa diferença for importante.
• (F) depois de um membro significa que ele está com falha. (S) significa sobressalente: está presente, inativo e aguardando uma falha.
• 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, ele 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 que está atualmente sincronizado.
• [UUUU] contém um caractere por slot, na ordem dos slots. U é um slot ativo e sincronizado. _ é um slot sem nenhum dispositivo funcionando.
• bitmap: é o bitmap de intenção de escrita. Ele registra quais regiões estavam recebendo gravações. Assim, um membro que sai do array e volta sincroniza essas regiões, em vez da unidade inteira.

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

Um array degradado aparece assim.

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 colchetes em conjunto. [4/3] informa que um dos quatro slots não está contribuindo. [UU_U] informa qual deles: o sublinhado é o terceiro caractere e os slots são numerados a partir de zero, portanto o slot 2 está inativo. O sinalizador (F) identifica o dispositivo apenas enquanto a unidade com falha continua conectada. Remova-a da máquina e o nome desaparece da linha, mas o sublinhado permanece.

O array continua atendendo às solicitações durante tudo isso. No RAID 10, ele geralmente continua operando quase à velocidade total. Por isso, ninguém percebe apenas pelo desempenho. É necessário usar algum mecanismo de monitoramento.

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 monitoramento que lê MAILADDR de /etc/mdadm/mdadm.conf. O nome da unidade mudou entre versões, portanto localize-o usando o último comando, em vez de tentar adivinhar. A opção --test envia imediatamente uma mensagem para cada array. Se a caixa de entrada continuar vazia depois disso, o caminho de e-mail está com problemas. A mensagem que realmente importa teria sido perdida da mesma forma.

Quando uma unidade substituta está sendo reconstruída, aparece uma linha de progresso abaixo do 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 uma unidade substituta. resync é uma verificação de consistência, incluindo a verificação inicial e a recuperação após um desligamento incorreto. check é a verificação iniciada anteriormente. O par entre parênteses mostra o progresso em blocos de 1 KiB em relação ao total por dispositivo. finish é a estimativa do kernel na velocidade atual. O Linux MD usa /proc/sys/dev/raid/speed_limit_min e speed_limit_max como destinos de velocidade de recuperação, com substituições específicas por array em sync_speed_min e sync_speed_max. O destino máximo padrão é 200,000 KiB/s por dispositivo. Esses destinos permitem que a recuperação ceda prioridade às operações de E/S de produção e não são limites rígidos de velocidade.

/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 uma unidade num array que é seu exige 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 substituta deve ter pelo menos o tamanho indicado por Used Dev Size em mdadm --detail. Uma partição mesmo que ligeiramente menor é rejeitada com uma mensagem no formato not large enough to join array. Particione a nova unidade para corresponder à antiga antes de adicioná-la.

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

O RAID 10 significa que não preciso de cópias de segurança?

Não. O RAID 10 protege contra a falha de uma unidade. 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. Depois, o array apresenta-se como íntegro, porque, do seu ponto de vista, nada falhou. Continua a precisar de cópias que fiquem fora da máquina e deve restaurar uma ocasionalmente para confirmar que funcionam.

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

Por dois motivos, ambos relacionados com pequenas escritas aleatórias. Uma operação de leitura-modificação-escrita de um único bloco, sem cache, lê os dados antigos e a paridade antes de calcular a nova paridade. Isso custa 4 operações no RAID 5 e 6 no RAID 6, contra 2 num espelho com duas cópias. A escrita com reconstrução usa os dados que não foram alterados, e as escritas de uma faixa completa não precisam de pré-leituras dos dados antigos nem da paridade antiga. Uma reconstrução completa de RAID 5 lê depois todas as unidades sobreviventes de uma ponta à outra, enquanto o RAID 10 convencional, com pares de espelhos fixos, copia a partir do parceiro sobrevivente. Outros layouts de RAID10 do Linux usam vários membros de origem. O Linux MD limita a recuperação quando existe outra atividade. Os fornecedores pagam por isso em capacidade: metade da capacidade bruta de NVMe.

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

Cada carácter representa um slot no 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 o slot não tem nenhum membro funcional. [U_] num espelho de duas unidades significa que o segundo slot está inativo e que já não existe redundância. Leia este indicador juntamente com o par que aparece à sua frente, em que [4/3] indica que o array espera quatro membros e tem três. A ordem dos slots corresponde à coluna RaidDevice de mdadm --detail, e não à ordem em que os nomes dos dispositivos aparecem na linha.

Quantas unidades pode perder um array RAID 10?

No RAID 10 convencional, com pares de espelhos fixos e duas cópias, uma unidade, independentemente do padrão. Depois disso, depende de onde ocorrem as falhas. Cada par de espelhos pode perder um dos seus dois membros. Assim, um array com oito unidades sobrevive a até quatro falhas se não houver duas no mesmo par, mas falha com duas se ambas atingirem o mesmo par. Planeie com base no número garantido, que é uma unidade, e considere qualquer coisa além disso sorte, não proteção.

Devo espelhar dois volumes dentro da minha VPS com mdadm?

Normalmente, não. Dois volumes ligados à mesma VPS estão muitas vezes no mesmo array físico e no mesmo host. Nesse caso, espelhá-los 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, invista esse esforço em cópias de segurança que saiam da máquina.