RAID em NAS Doméstico: A Batalha Real entre ZFS (TrueNAS) e SHR (Synology)
Não escolha seu NAS pelo chassi, mas pelo sistema de arquivos. Entenda os trade-offs reais de integridade, expansão e custo entre ZFS e SHR antes de comprar os discos.
Quando analisamos armazenamento doméstico ou de pequenas empresas (SOHO), a discussão frequentemente degenera em tribalismo de marcas. De um lado, os puristas do ZFS que tratam a RAM como oxigênio; do outro, os pragmáticos do Synology que valorizam a conveniência do "plug-and-play".
Como engenheiro de performance, não me importo com a cor do chassi. Eu me importo com o caminho do dado (datapath). Me importo com o que acontece quando um bit vira (bitrot) e com a latência introduzida por camadas de abstração. Vamos dissecar a arquitetura de armazenamento do ZFS (usado no TrueNAS) e do SHR (Synology Hybrid RAID), não com base em promessas de marketing, mas em como eles gerenciam blocos, paridade e integridade física.
A escolha entre ZFS e SHR não é sobre interface gráfica; é uma escolha entre flexibilidade de expansão e garantia matemática de integridade.
O que diferencia ZFS e SHR?
ZFS (Zettabyte File System) é um sistema unificado que atua simultaneamente como gerenciador de volume e sistema de arquivos, garantindo integridade ponta-a-ponta através de checksums em cada bloco e exigindo planejamento rígido de hardware. SHR (Synology Hybrid RAID) é um sistema de gerenciamento automatizado baseado em Linux RAID (mdadm) e LVM (Logical Volume Manager), priorizando a flexibilidade para misturar discos de tamanhos diferentes ao custo de maior sobrecarga de CPU e menor visibilidade direta da saúde dos dados.
A Ilusão do Hardware: Por que o Filesystem dita as regras
Antigamente, confiávamos em controladoras RAID de hardware para gerenciar a redundância. Elas eram caixas pretas caras com baterias de cache. Hoje, em um NAS doméstico, a CPU é o controlador. Isso significa que a eficiência do seu código define a performance do seu array.
O erro fundamental de muitos entusiastas é tratar o disco rígido como um cofre confiável. Discos mentem. Eles reportam gravações que ainda estão no cache volátil. Eles falham em setores silenciosamente.
No mundo ZFS: O sistema não confia no disco. Ele assume que o hardware é hostil e verifica tudo.
No mundo SHR: O sistema confia na camada de abstração do Linux (mdadm) para apresentar um "disco virtual" limpo para o sistema de arquivos (geralmente Btrfs ou ext4).
Essa diferença arquitetural define tudo o que vem a seguir.
Anatomia do Synology SHR: O truque do LVM e fatiamento de discos
O Synology Hybrid RAID (SHR) é frequentemente chamado de "mágico" porque permite misturar um disco de 4TB com um de 8TB e, eventualmente, utilizar todo o espaço. Mas em engenharia, mágica é apenas complexidade oculta.
O SHR não é um novo tipo de RAID. Ele é um script de automação inteligente que opera sobre duas tecnologias Linux robustas: mdadm (software RAID) e LVM (Logical Volume Manager).
Como o SHR gerencia a capacidade mista
Imagine que você tem dois discos de 4TB e dois discos de 8TB.
O SHR cria um array RAID 5 usando 4TB de cada um dos quatro discos.
Sobram 4TB não utilizados nos dois discos maiores.
O SHR cria outro array RAID 1 (espelhamento) usando apenas essas sobras.
O LVM entra em cena e "cola" esses dois arrays distintos em um único volume lógico linear.
Figura: O 'Tetris' do Armazenamento: Como o SHR usa LVM para fatiar discos físicos e criar múltiplos arrays RAID invisíveis ao usuário.
O Custo da Abstração: Essa flexibilidade tem um preço em latência e IOPS. Quando você grava um arquivo grande, o LVM pode estar espalhando blocos entre o RAID 5 (mais lento em escrita devido ao cálculo de paridade) e o RAID 1. As cabeças de leitura/escrita dos discos maiores precisam trabalhar em dobro, buscando dados em diferentes "fatias" lógicas do mesmo prato físico. Em cargas de trabalho sequenciais (filmes), isso é imperceptível. Em cargas aleatórias (banco de dados, VMs, Docker), o wait time de I/O aumenta.
A Fortaleza ZFS: VDEVs, Copy-on-Write e a rigidez necessária
O ZFS rejeita a ideia de camadas. Ele quer controle total. Não existe "RAID" abaixo dele e "Filesystem" acima. É tudo uma coisa só.
O bloco de construção do ZFS é o VDEV (Virtual Device). Um VDEV pode ser um espelho, ou um RAIDZ (equivalente ao RAID 5/6). O pool é formado por um ou mais VDEVs.
O Mecanismo Copy-on-Write (CoW)
Em sistemas tradicionais (como ext4 no Synology), se você edita um arquivo, o sistema sobrescreve os dados antigos no local. Se a energia cair durante essa sobrescrita, você tem corrupção.
O ZFS usa Copy-on-Write. Ele nunca sobrescreve dados ativos.
Novos dados são escritos em um novo bloco livre.
O checksum é calculado.
Só então o ponteiro de metadados é atualizado para apontar para o novo bloco.
Isso garante que o estado do sistema de arquivos seja sempre consistente, sem necessidade de fsck (checkdisk) após queda de energia.
Figura: A Paranóia Necessária: O ciclo de leitura do ZFS não confia no disco. Ele confia na matemática (checksum) para validar cada bloco lido.
A "rigidez" do ZFS vem do fato de que, historicamente, você não podia adicionar um único disco a um VDEV RAIDZ existente. Você tinha que adicionar um novo VDEV inteiro. Isso torna o planejamento de capacidade no TrueNAS muito mais crítico e caro inicialmente do que no Synology.
Proteção contra Bitrot: Onde o ZFS realmente supera o Btrfs sobre mdadm
Aqui reside a maior diferença técnica para quem valoriza a longevidade dos dados (fotos de família, documentos fiscais).
O cenário Synology (Btrfs sobre mdadm): A Synology usa Btrfs, que possui checksums. Se o Btrfs ler um arquivo e o checksum falhar, ele sabe que o arquivo está corrompido. Ótimo. Mas o Btrfs no Synology roda em cima do mdadm. O Btrfs muitas vezes não tem controle direto sobre qual disco físico tem a cópia boa. Ele precisa pedir ao mdadm. Embora a Synology tenha integrado correções, é uma colcha de retalhos de camadas. Frequentemente, o mdadm diz "o disco está online e feliz", enquanto o Btrfs diz "o dado está podre".
O cenário ZFS (Autocura Nativa): No ZFS, o checksum não é apenas do arquivo, mas de toda a árvore de dados (Merkle Tree). O ponteiro pai tem o checksum do bloco filho.
Você pede um arquivo.
O ZFS lê o bloco do Disco A.
Calcula o checksum. Não bateu?
O ZFS sabe instantaneamente que o Disco A mentiu.
Ele lê o bloco de paridade ou espelho do Disco B.
Verifica o checksum. Bateu?
Ele entrega o dado correto para você e repara o bloco errado no Disco A automaticamente.
Tudo isso acontece em microssegundos, transparente para a aplicação.
O Dilema da Expansão: Adicionar um disco (SHR) vs RAIDZ Expansion
Para o usuário doméstico, o modelo de expansão é o fator decisivo de compra.
A facilidade do SHR
O SHR permite o crescimento orgânico. Começou com 2 discos? Adicione o 3º. O sistema vai passar dias "reconstruindo" e expandindo o volume (processo intensivo de I/O), mas ao final, você tem mais espaço. É a vitória da conveniência.
A evolução do ZFS (RAIDZ Expansion)
Durante anos, o ZFS exigia que você comprasse discos em lotes. Se você tinha um RAIDZ2 de 6 discos, para expandir, precisava comprar outros 6 discos para criar um novo VDEV.
Recentemente, o recurso RAIDZ Expansion chegou ao OpenZFS (e ao TrueNAS Scale). Ele permite adicionar um disco a um VDEV existente. O Alerta do Engenheiro: Não é mágica. O ZFS não reescreve os dados antigos para redistribuir a paridade perfeitamente (como o SHR faz). Os dados antigos mantêm a proporção de paridade antiga; apenas os novos dados usam a nova largura. Isso significa que você não ganha performance imediata e o espaço ganho tem uma pequena ineficiência (overhead) até que os dados sejam reescritos. É funcional, mas tecnicamente "menos limpo" que o método do SHR.
Custo Total de Propriedade (TCO): O preço da flexibilidade vs RAM
Não olhe apenas o preço dos discos. Olhe o conjunto.
Custo de Memória (RAM)
ZFS: É faminto por RAM. A regra de ouro (embora flexível) é 1GB de RAM para cada 1TB de armazenamento para performance ótima, devido ao ARC (Adaptive Replacement Cache). O ZFS usa RAM como cache de leitura agressivo. Sem RAM suficiente, a performance de leitura despenca, pois ele precisa buscar metadados nos discos rotacionais.
SHR/Synology: Roda bem com 4GB ou 8GB de RAM mesmo em arrays grandes. O Linux gerencia o cache de página de forma mais conservadora.
Custo de Hardware vs Software
Synology: Você paga um prêmio altíssimo pelo hardware (frequentemente CPUs Celeron ou Ryzen antigos) para ter o software (DSM). O TCO é alto no hardware, baixo na manutenção cognitiva.
TrueNAS (ZFS): O software é grátis. Você pode usar hardware commodity ou enterprise usado. O custo está no tempo de configuração e na necessidade de hardware específico (ECC RAM é altamente recomendada para ZFS para evitar que erros de memória corrompam o pool, embora não seja obrigatória para uso doméstico).
Comparativo Técnico Direto
| Característica | Synology SHR (Btrfs/mdadm) | TrueNAS (ZFS) | Vencedor Técnico |
|---|---|---|---|
| Expansão | Adição de disco único com rebalanceamento total. | Adição de VDEV ou RAIDZ Expansion (com caveats). | SHR (Flexibilidade) |
| Integridade de Dados | Checksum de arquivo (Btrfs) sobre camada burra (mdadm). | Checksum hierárquico e autocura (Self-healing) nativa. | ZFS (Segurança) |
| Performance (Throughput) | Limitada pela CPU em arrays mistos (LVM overhead). | Limitada apenas pela física dos discos e tamanho do ARC. | ZFS (Velocidade) |
| Requisito de RAM | Baixo (2GB-8GB é funcional). | Alto (8GB mínimo, 16GB+ recomendado). | SHR (Eficiência) |
| Portabilidade | Proprietário (difícil montar discos SHR fora de um Synology). | Universal (Importe o pool em qualquer Linux/BSD com ZFS). | ZFS (Liberdade) |
Veredito Técnico: Quando a conveniência vence a pureza técnica
Como engenheiro, minha preferência natural é pelo ZFS. A elegância de como ele trata a integridade dos dados é inigualável. Se você vai armazenar dados que não podem ser perdidos sob nenhuma hipótese (arquivos de trabalho, produção de vídeo, backups únicos), o ZFS no TrueNAS é a única escolha profissional. A curva de aprendizado e o requisito de RAM são o seguro que você paga contra o bitrot.
No entanto, o Synology SHR é uma obra-prima de engenharia de usabilidade. Para um media server (Plex/Jellyfin), backup de PCs domésticos e armazenamento geral onde a densidade e a facilidade de expansão superam a necessidade de performance extrema de I/O, o SHR vence. O "truque" do LVM funciona bem o suficiente para 95% dos lares.
A regra final:
Se você tem orçamento para comprar todos os discos de uma vez e quer performance máxima: Vá de ZFS.
Se você vai comprar um disco por ano na Black Friday e quer silêncio e baixo consumo: Vá de SHR.
Apenas lembre-se: RAID não é backup. Seja ZFS ou SHR, se a casa pegar fogo ou um raio queimar a controladora, seus dados se vão. Mantenha sempre uma cópia off-site.
Referências & Leitura Complementar
OpenZFS Documentation: "ZFS Data Integrity - The Merkle Tree Architecture".
Synology Inc. Whitepaper: "Synology Hybrid RAID (SHR) Technology Guide - Based on LVM and mdadm implementation".
Bonwick, J. & Moore, B. (Sun Microsystems): "ZFS: The Last Word in File Systems" (O paper original que definiu a arquitetura de 128-bits).
RFC 3720: iSCSI (Internet Small Computer Systems Interface) - Para entender o transporte de blocos sobre rede em ambos os sistemas.
David Ross
Linux Sysadmin Veterano
Vive no terminal. Mantenedor de diversos módulos kernel de storage. Acredita que GUI é bloatware.