Migração Btrfs: Convertendo RAID 1 para RAID 5 (Guia de Sobrevivência)

Você está diante de um servidor de armazenamento cheio. O sintoma é claro: luzes vermelhas, alertas de espaço em disco e a necessidade urgente de expansão. Você tem dois discos em RAID 1 (espelhamento) e comprou um terceiro. A matemática é sedutora: converter para RAID 5 aumentaria sua capacidade drasticamente sem sacrificar toda a redundância.

Mas antes de digitar qualquer comando, precisamos isolar as variáveis. O Btrfs não opera como um controlador RAID de hardware dos anos 90, e tratá-lo como tal é a causa raiz da maioria dos desastres de dados que investiguei.

Vamos dissecar a anatomia dessa migração, entender os riscos reais (não apenas o hype) e executar a operação com precisão cirúrgica.

A Conversão de Perfil Btrfs é um processo de rebalanceamento online que reescreve dados existentes em um novo layout de paridade. Diferente do RAID tradicional, que exige formatação ou reconstrução de bloco, o Btrfs move "chunks" (pedaços) de dados alocados dinamicamente de um perfil (ex: RAID 1) para outro (ex: RAID 5) enquanto o sistema de arquivos permanece montado e acessível.

---

A Anatomia dos Chunks no Btrfs: Por que a Migração é Possível

A maioria dos administradores carrega um modelo mental herdado do mdadm ou controladores LSI: eles imaginam que o RAID é uma camada rígida abaixo do sistema de arquivos. No Btrfs, essa premissa é falsa.

O Btrfs é, simultaneamente, o gerenciador de volume e o sistema de arquivos. Ele não gerencia o disco inteiro como um bloco monolítico. Ele divide o espaço físico em Chunks (geralmente de 1GB para dados). O "RAID" no Btrfs é, na verdade, uma propriedade desses chunks, não dos discos.

Figura: Diferença visual: O Btrfs opera no nível de 'Chunks', permitindo que diferentes perfis RAID coexistam nos mesmos discos físicos durante a migração.

Isso significa que, durante a migração, seu disco conterá uma mistura heterogênea: alguns chunks antigos ainda em RAID 1 e novos chunks sendo gravados em RAID 5. O sistema de arquivos sabe exatamente onde está cada pedaço. É por isso que não precisamos desmontar o array ou copiar dados para fora (embora backups sejam obrigatórios para qualquer investigador prudente).

O Elefante na Sala: O "Write Hole" e a Estabilidade do RAID 5

Antes de prosseguirmos, precisamos apresentar as evidências contra o acusado. O RAID 5/6 no Btrfs tem uma reputação terrível. Parte disso é eco de fóruns antigos, mas há um risco técnico real e documentado: o Write Hole.

Em um RAID 5 tradicional, se a energia cair enquanto o sistema está gravando, você pode acabar com dados gravados mas a paridade não atualizada (ou vice-versa). No próximo boot, o array não sabe quem está falando a verdade. Em sistemas tradicionais, o controlador de hardware usa uma bateria (BBU) para mitigar isso.

O Btrfs, sendo software, não tem essa bateria. Se ocorrer um "Write Hole" nos Metadados (a árvore que diz onde seus arquivos estão), você perde o sistema de arquivos inteiro. Se ocorrer nos Dados, você corrompe apenas aquele arquivo.

O Veredito de Segurança (Mixed Mode)

Para sobreviver a essa operação, adotaremos uma postura híbrida:

1. Dados (Data): Convertidos para RAID 5. Aceitamos o risco calculado para ganhar espaço.

2. Metadados (Metadata): Mantidos em RAID 1 (ou RAID 1c3 para 3 cópias).

Nunca, sob nenhuma circunstância, converta metadados para RAID 5 em produção. O ganho de espaço é irrisório (metadados são pequenos) e o risco de destruição total é alto. Manter metadados em RAID 1 vacina o sistema contra a falha catastrófica estrutural.

Preparação Forense: Isolando Variáveis de Risco

Um bom investigador nunca altera a cena do crime sem documentar o estado atual. Se o seu filesystem já tiver corrupção silenciosa (bitrot) no RAID 1, a conversão para RAID 5 irá cristalizar esse erro na paridade, tornando-o permanente.

Checklist Pré-Operatório

1. Kernel Check: O código do Btrfs RAID 5/6 recebeu correções massivas nos kernels recentes. Se você está rodando algo anterior ao Kernel 5.15, pare. Atualize seu sistema. O ideal é 6.1 LTS ou superior.

2. Scrub Obrigatório: Execute uma limpeza profunda para garantir que os dados atuais estão íntegros.

   sudo btrfs scrub start -B /mnt/seuponto
   

   Se houver erros não corrigíveis, aborte. Não migre lixo.

3. Backup: RAID não é backup. RAID 5 em Btrfs é uma "feature avançada". Tenha uma cópia fria dos dados.

Execução da Manobra (Live Migration)

Vamos ao procedimento. O cenário é: você tem 2 discos em RAID 1 montados em /mnt/data. Você conectou fisicamente o terceiro disco (/dev/sdc).

Passo 1: Adicionar o novo dispositivo ao pool

O Btrfs precisa "ver" o novo espaço antes de usá-lo. Ao adicionar o disco, ele inicialmente não conterá dados, apenas espaço livre disponível para alocação.

# Adiciona o dispositivo físico ao volume montado
sudo btrfs device add /dev/sdc /mnt/data

Neste momento, você tem um array de 3 discos, mas seus dados ainda estão ocupando espaço como RAID 1 nos dois primeiros discos. O terceiro está ocioso.

Passo 2: O Rebalanceamento Cirúrgico

Agora, invocamos o comando balance. Ele vai ler os chunks RAID 1, calcular a paridade e reescrevê-los distribuídos nos 3 discos como RAID 5.

Figura: Fluxo da Conversão: O comando 'balance' lê os dados espelhados, calcula a paridade e grava as novas faixas (stripes) no layout de 3 discos.

Aqui está o comando exato que separa os amadores dos profissionais. Note os filtros distintos para dados (-d) e metadados (-m).

# Executa em background, convertendo DADOS para RAID5 e mantendo METADADOS em RAID1
sudo btrfs balance start -dconvert=raid5 -mconvert=raid1 /mnt/data

O que está acontecendo aqui?

• -dconvert=raid5: Pega os chunks de dados (seja single ou RAID 1) e os converte para striping com paridade distribuída.

• -mconvert=raid1: Força os metadados a ficarem espelhados. Mesmo que já estejam em RAID 1, isso garante que o balanceador os redistribua corretamente pelos 3 discos para performance, mantendo 2 cópias de segurança.

Nota: O terminal vai travar até o processo acabar, a menos que você use a flag de background ou execute em um tmux/screen. O desempenho de I/O do servidor cairá drasticamente.

Análise Pós-Operação: Confirmando a Integridade

Após o retorno do prompt, não confie cegamente. Use ferramentas de análise para verificar a distribuição dos chunks. O comando df -h é inútil aqui, pois ele não entende a complexidade do RAID Btrfs.

Use o comando nativo:

sudo btrfs filesystem usage /mnt/data

O que procurar na saída:

Você verá uma seção Data,RAID5: Size:... e Metadata,RAID1: Size:.... O mais importante é verificar se as entradas antigas desapareceram.

Exemplo de Sucesso:

Data,RAID5: Size: 4.00TiB, Used: 3.80TiB
   /dev/sda    1.33TiB
   /dev/sdb    1.33TiB
   /dev/sdc    1.33TiB

Metadata,RAID1: Size: 10.00GiB, Used: 8.00GiB
   /dev/sda    5.00GiB
   /dev/sdb    5.00GiB
   /dev/sdc    (pode ou não ter alocação aqui dependendo do balanceamento)

Se você ainda vir Data,RAID1 com valor Used maior que zero, o balanceamento não terminou ou falhou parcialmente. Execute novamente.

Tabela Comparativa: O Trade-off Real

Para decidir se essa arquitetura se mantém a longo prazo, analise os fatos frios:

Característica	Btrfs RAID 1 (Espelho)	Btrfs RAID 5 (Paridade)	Veredito do Investigador
Eficiência de Espaço	50% (2 discos = 1 disco de espaço)	(N-1)/N (3 discos = 67%, 4 discos = 75%)	RAID 5 vence em custo/GB.
Velocidade de Leitura	Alta (lê de ambos simultaneamente)	Alta (striping em todos os discos)	Empate técnico para maioria das cargas.
Velocidade de Escrita	Alta (limitada pelo disco mais lento)	Baixa (custo de cálculo de paridade RMW)	RAID 5 sofre com muitas gravações pequenas.
Resiliência a Falhas	Excelente. Simples e robusto.	Moderada. Rebuild é intensivo e arriscado.	RAID 1 é mais seguro.
Risco de "Write Hole"	Inexistente.	Existente (Mitigado com Metadados em RAID1).	Exige UPS (No-break).

Manutenção de Longo Prazo

Você converteu com sucesso. O caso não está encerrado; ele entrou em condicional. Operar Btrfs RAID 5 exige vigilância constante.

1. UPS (No-Break) é Lei: Como discutimos, a falta de bateria no controlador é o calcanhar de Aquiles. Um desligamento abrupto vai causar dessincronização de paridade. Conecte o servidor a um UPS e configure o apcupsd ou nut para desligamento gracioso.

2. Scrub Agendado: O Btrfs pode detectar corrupção, mas só corrige se ler os dados. Em RAID 5, a autocura depende da paridade estar correta. Agende um scrub mensal via CRON ou Systemd Timer.

   # Exemplo de cron mensal
   0 2 1 * * root btrfs scrub start -B /mnt/data
   

3. Monitoramento de Espaço "Unallocated": O Btrfs precisa de espaço livre não alocado (raw) para conseguir corrigir erros de gravação em RAID 5. Se o filesystem usage mostrar Unallocated: 0.00, você está em perigo, mesmo que o df mostre espaço livre dentro dos arquivos. Mantenha os discos abaixo de 85-90% de uso real.

Referências & Leitura Complementar

• Btrfs Wiki - RAID56: Status oficial e avisos sobre a implementação de paridade.

• Kernel.org Btrfs Source: Documentação técnica sobre a alocação de chunks e árvores de metadados.

• Reliability of Btrfs RAID: Análises de desenvolvedores do SUSE e Facebook sobre a estabilidade das correções de "Write Hole" pós-Kernel 5.x.