TrueNAS e ambientes legados FreeNAS usam ZFS, com pools formados por VDEVs, mirrors, RAIDZ, datasets, zvols e snapshots. Quando discos falham ou o pool deixa de importar, a pergunta principal não é apenas "qual disco morreu?", mas quais VDEVs continuam completos e qual estado lógico ainda pode ser reconstruído.
O que é recuperação de TrueNAS e FreeNAS?
FreeNAS é o nome histórico da plataforma que foi unificada ao TrueNAS. A iXsystems informa que TrueNAS CORE foi introduzido como continuação do FreeNAS e que a unificação foi concluída em 2021. Hoje, sistemas FreeNAS e TrueNAS CORE legados continuam aparecendo em recuperação, enquanto a linha atual TrueNAS Community Edition é Linux-based.
Guia completo de recuperação TrueNAS, FreeNAS e ZFS
Quando um TrueNAS ou FreeNAS precisa de recuperação de dados?
Pool DEGRADED
O pool ainda funciona, mas perdeu redundância ou possui um membro problemático. É um momento crítico para validar backup.
Pool FAULTED
ZFS detecta condição em que o pool ou dispositivo não pode operar como esperado. A causa precisa ser localizada na topologia.
Pool UNAVAIL
Dispositivos ou VDEVs essenciais não estão disponíveis. Pode haver falha física, desconexão, identificação ou perda além da redundância.
Dataset não monta
Pool pode importar, mas um dataset, zvol ou caminho específico permanece inacessível por corrupção lógica ou dependência de chaves.
Snapshot inacessível
Snapshots dependem do pool e do dataset. Se a base não monta, o snapshot também precisa ser alcançado pela reconstrução.
Resilver travado
Substituição de disco fica lenta ou encontra novos erros. Outro membro pode estar fisicamente degradado.
Scrub encontra erros
Checksums, erros de leitura ou dados sem réplica válida podem surgir durante a verificação do pool.
Pool não importa após migração
Hardware, versão, feature flags, criptografia ou estado do conjunto podem impedir a importação normal.
TrueNAS não inicializa
Boot pool pode falhar sem que o data pool esteja perdido. A documentação TrueNAS prevê reinstalar o sistema e restaurar configuração em falha de boot pool.
FreeNAS, TrueNAS CORE e TrueNAS Community Edition
A marca FreeNAS foi incorporada ao TrueNAS. A história oficial da plataforma informa que TrueNAS CORE surgiu como continuação do FreeNAS e que a unificação dos projetos foi concluída em 2021. Por isso, pesquisas por "recuperação FreeNAS" continuam relevantes mesmo em 2026.
FreeNAS legado
Ambientes históricos baseados em FreeBSD e ZFS. Ainda existem appliances e servidores antigos em produção ou arquivo.
TrueNAS CORE
Linha FreeBSD-based que continuou o legado do FreeNAS. Versões 13.x ainda aparecem em ambientes existentes e migrações.
TrueNAS atual
A documentação atual trata a Community Edition Linux-based como plataforma de continuidade para usuários que migram de CORE.
A documentação de migração deixa claro que a passagem de versões FreeBSD-based para as versões Linux-based é uma operação que exige preparação e que determinados caminhos de rollback não são suportados. Em recuperação, não é prudente usar atualização de plataforma como tentativa de consertar um pool já com falhas.
Pool, VDEV, mirror, RAIDZ, dataset e zvol: entenda as camadas
O ZFS combina gerenciamento de volume e filesystem. O pool é construído a partir de VDEVs. A redundância efetiva está dentro de cada VDEV, enquanto o pool distribui dados entre seus VDEVs de dados.
Discos
HDDs ou SSDs individuais fornecem blocos ao VDEV e podem apresentar bad blocks, falha mecânica, firmware, eletrônica ou NAND.
VDEV
Unidade estrutural do pool. Pode ser mirror, RAIDZ, dRAID, stripe ou classes especiais conforme a configuração.
Pool
Agrega os VDEVs e fornece o espaço lógico utilizado por datasets e zvols.
Dataset
Filesystem ZFS com propriedades próprias, ACLs, quotas, snapshots e pontos de montagem.
zvol
Volume de bloco ZFS, frequentemente usado em iSCSI, virtualização e aplicações que esperam um dispositivo de bloco.
Snapshot
Estado somente leitura point-in-time de dataset ou zvol. Ajuda em exclusão e rollback, mas depende do pool subjacente.
10 passos quando um pool TrueNAS fica offline ou degradado
O que não fazer em um pool ZFS com dados críticos
Criar pool novo nos mesmos discos
Essa é uma operação realmente destrutiva para o estado anterior e não deve ser confundida com importação de um pool existente.
Forçar comandos sem entender a topologia
Flags e comandos de shell podem mudar estado ou ignorar verificações. Diagnóstico deve preceder tentativas em dados únicos.
Repetir resilver com outro disco instável
O resilver é legítimo, mas uma segunda mídia em falha muda o risco. Clonagem pode ser mais segura antes de insistir.
Usar scrub como recovery
Scrub é manutenção de integridade. Ele não substitui aquisição de discos defeituosos nem reconstrução de pool perdido.
Migrar CORE para Linux durante a falha
Migração de plataforma é um processo administrativo planejado, não uma técnica para recuperar pool instável.
Wipe ou reutilizar um membro
TrueNAS documenta que replacement disk pode ser apagado no processo. Nunca escolha como replacement um disco que ainda contém parte do pool original.
Como funciona a recuperação profissional de TrueNAS e FreeNAS
O objetivo é preservar a camada física antes de reconstruir a topologia ZFS. O procedimento varia conforme o tipo de VDEV, número de falhas, criptografia e estruturas adicionais.
PC-3000 e DeepSpar
Em HDDs com falha física ou firmware, ferramentas profissionais podem ser usadas para estabilizar leitura e obter a melhor imagem possível. Em SSDs, ferramentas específicas podem ser necessárias conforme controladora e firmware. Essas tecnologias atuam na camada de mídia, enquanto a reconstrução ZFS ocorre acima dela.
RAIDZ1, RAIDZ2 e RAIDZ3: tolerância dentro do VDEV
O ZFS Primer do TrueNAS descreve três níveis de RAIDZ e relaciona o número do RAIDZ à quantidade de discos que um VDEV pode perder sem perda de dados. Isso ajuda a entender a tolerância, mas não significa que RAIDZ seja idêntico a RAID 5 ou RAID 6 de hardware.
| Layout | Paridades | Tolerância teórica por VDEV | Ponto de recuperação |
|---|---|---|---|
| Stripe | 0 | 0 discos | Falha de um membro elimina parte do fluxo de dados |
| Mirror | Cópias completas | Depende do número de espelhos | Escolher a cópia mais íntegra e reconstruir membros faltantes |
| RAIDZ1 | 1 | 1 disco | Segundo membro com erros pode criar stripes irrecuperáveis |
| RAIDZ2 | 2 | 2 discos | Terceiro membro com falhas pode ultrapassar a redundância |
| RAIDZ3 | 3 | 3 discos | Mais robusto, mas não imune a falhas correlacionadas |
| dRAID | Configuração específica | Depende da topologia | Layouts distribuídos exigem identificar grupos de redundância |
Pool com vários VDEVs
Um pool pode ter dois ou mais VDEVs de dados. ZFS distribui dados entre eles. Se um VDEV de dados é perdido definitivamente além da sua redundância, o pool pode ficar comprometido mesmo que os outros VDEVs estejam saudáveis.
RAIDZ Expansion
A documentação atual do TrueNAS já inclui expansão de RAIDZ adicionando discos a VDEVs existentes em versões compatíveis. Em recuperação, isso reforça a importância de registrar histórico de expansão e topologia atual, pois pools modernos podem ter sofrido mudanças que não existiam em versões antigas.
Datasets, zvols e snapshots ZFS
TrueNAS documenta snapshots como cópias somente leitura point-in-time de filesystem ou volume. Eles registram diferenças de referências de blocos à medida que os dados mudam e podem manter histórico de arquivos.
Dataset
Filesystem ZFS com propriedades próprias, quotas, compressão, ACLs e snapshots. Compartilhamentos SMB/NFS geralmente apontam para datasets.
zvol
Dispositivo de bloco ZFS. Pode ser usado como iSCSI LUN, disco de VM ou base para outro filesystem.
Snapshot
Pode permitir recuperar arquivo antigo ou deletado sem varredura física, desde que o pool e snapshot permaneçam acessíveis.
Snapshot não consome uma segunda cópia completa
A documentação TrueNAS explica que snapshots registram diferenças de referências e não duplicam imediatamente toda a capacidade. Conforme blocos mudam, snapshots retêm as referências necessárias para representar o estado anterior.
Replicação
TrueNAS recomenda copiar snapshots para outro sistema como estratégia de proteção. Isso transforma o histórico point-in-time em uma cópia independente do pool local, muito mais útil em falha física catastrófica.
SLOG e L2ARC não têm o mesmo papel no ZFS
ZIL e SLOG
A documentação TrueNAS destaca que ZIL e SLOG são conceitos frequentemente confundidos. O ZFS Intent Log participa de escritas síncronas. Um SLOG é um dispositivo separado usado para armazenar esse log em cenários específicos de performance e integridade.
L2ARC
L2ARC é cache de leitura em dispositivo adicional. A documentação TrueNAS é explícita: falha de L2ARC não afeta a integridade do pool, embora possa reduzir performance. Isso é importante para não classificar um SSD L2ARC como um membro de dados crítico.
| Componente | Função | Se falhar | Relevância na recuperação |
|---|---|---|---|
| ARC | Cache em RAM | É reconstruído em operação normal | Não é mídia persistente de dados principal |
| L2ARC | Cache de leitura em SSD | TrueNAS informa que não afeta a integridade do pool | Identificar para não confundir com data VDEV |
| ZIL | Intent log para escritas síncronas | Faz parte da lógica de commit do ZFS | Estado do sistema durante falha pode ser relevante |
| SLOG | Dispositivo separado para o intent log | Impacto depende do evento e de escritas síncronas em trânsito | Preservar e identificar corretamente |
Special VDEV, metadata e DDT podem ser críticos
Pools ZFS modernos podem usar VDEVs especiais para metadata ou small blocks. A documentação TrueNAS para Fusion Pools alerta que Metadata VDEVs são críticos para operação e integridade do pool e recomenda redundância igual ou superior à dos data VDEVs.
Special Metadata VDEV
Se metadados essenciais foram direcionados a um special VDEV e ele perde todas as réplicas válidas, a perda pode afetar o acesso a todo o pool. Não trate um SSD pequeno como simples cache só porque tem capacidade menor que os discos de dados.
Deduplication Table
TrueNAS descreve a DDT como estrutura fundamental quando dedup foi usada. O pool depende das referências da DDT para localizar blocos compartilhados. Em recuperação, saber se dedup estava habilitada é relevante, principalmente em pools empresariais ou antigos.
dRAID
dRAID usa uma organização distinta para distribuição e reconstrução. A documentação atual também permite classes especiais ao lado de data VDEVs. A topologia completa precisa ser inventariada antes de concluir que todos os SSDs auxiliares são descartáveis.
Comandos e operações ZFS: quando são manutenção e quando exigem cautela
O benchmark consultado acerta ao alertar contra intervenções precipitadas, mas transforma algumas funções oficiais em regras absolutas de destruição. A documentação atual do TrueNAS mostra um quadro mais preciso.
| Operação | Uso legítimo | Quando ter cautela |
|---|---|---|
| Import Pool | Reconectar pool exportado, desconectado ou criado em outro sistema | Pool com falhas, discos instáveis ou uso de import manual por CLI sem diagnóstico |
| Scrub | Verificação de integridade e correção usando redundância válida | Mídias fisicamente degradadas em caso de dados sem backup |
| Replace + Resilver | Substituição normal de disco falho | Outros membros instáveis ou redundância já esgotada |
| zpool clear | Limpar condição de erro em determinados cenários administrativos | Quando a causa não foi determinada e novas escritas podem ocorrer |
| Upgrade / Migration | Manutenção planejada e migração de plataforma | Pool já instável, sem backup ou em recuperação |
| Create Pool / Wipe | Criar armazenamento novo | Nunca usar sobre discos que ainda contêm o pool a recuperar |
A documentação de importação atual recomenda WebUI ou API e alerta que import manual via CLI pode causar comportamento inesperado. Isso é diferente de dizer que toda importação é destrutiva. A precisão dessa distinção melhora a orientação para administradores e reduz medo desnecessário.
TrueNAS com zvol, iSCSI, VMs e bancos de dados
O objeto que o cliente precisa recuperar pode estar duas ou três camadas abaixo do ZFS. Um zvol pode ser exportado por iSCSI e conter outro filesystem. Uma dataset pode hospedar discos virtuais, aplicações e bancos de dados.
iSCSI zvol
Pode conter GPT, NTFS, ReFS, VMFS ou LVM. Recuperar o zvol é apenas a etapa anterior à reconstrução do filesystem interno.
VMware / Proxmox
VMDK, QCOW2, raw e outros discos virtuais precisam ser validados após a recuperação do dataset ou zvol.
Banco de dados
SQL Server, PostgreSQL, MySQL, Oracle e outros formatos precisam de validação estrutural além da simples extração do arquivo.
Snapshots ZFS podem ter versões diferentes de VMs ou bancos. Restaurar um snapshot sem avaliar consistência de aplicação pode trazer arquivos a um ponto diferente dos logs transacionais. Em ambientes críticos, a validação deve considerar aplicação e storage juntos.
Cenários técnicos de recuperação TrueNAS e FreeNAS
RAIDZ1 DEGRADED com segundo HDD instável durante resilver
Contexto: um disco falha, o administrador substitui e o resilver começa. Outro membro passa a registrar erros de leitura.
Ação de risco: insistir em múltiplos resilvers ou remover o segundo disco sem preservar a primeira configuração.
Estratégia: mapear VDEV e seriais, adquirir os discos com leitura instável e reconstruir o VDEV sobre imagens para aproveitar paridade e os melhores blocos de cada membro.
Aprendizado: resilver é manutenção correta em pool saudável, mas uma segunda falha muda o caso para recuperação.
TrueNAS pool UNAVAIL após controladora HBA e cabos apresentarem falhas
Contexto: múltiplos discos somem de forma simultânea e o pool deixa de importar.
Ação de risco: assumir que vários discos morreram ao mesmo tempo e iniciar substituições.
Estratégia: diferenciar caminho de dados, HBA, backplane e discos. Quando as mídias estão saudáveis, um incidente de conectividade pode ser muito diferente de perda real de VDEV.
FreeNAS legado em hardware antigo com boot device morto e data pool saudável
Contexto: o sistema não inicializa, mas os HDDs de dados não apresentam falhas.
Ação de risco: criar novo pool após reinstalar porque os dados não aparecem automaticamente.
Estratégia: reinstalar ou usar ambiente compatível sem escrever nos membros e importar o pool existente seguindo procedimento apropriado.
Aprendizado: boot pool e data pool são entidades diferentes.
Dataset com arquivos apagados e snapshots periódicos
Contexto: usuário remove uma pasta, mas o pool permanece ONLINE e snapshots anteriores existem.
Ação de risco: criar novo pool, restaurar todo o dataset sobre o estado atual sem revisar o snapshot ou executar varreduras desnecessárias.
Estratégia: identificar snapshot point-in-time adequado e recuperar arquivos para destino seguro. Se o pool também estiver degradado, priorizar a camada física.
Perguntas frequentes sobre recuperação de TrueNAS e FreeNAS
TrueNAS com pool DEGRADED tem recuperação?
Na maioria dos cenários, DEGRADED significa que o pool ainda possui dados acessíveis, mas perdeu parte da redundância. A ação correta depende do VDEV, do número de membros afetados, da saúde real dos discos e do backup disponível. Se outros discos apresentam erros, vale preservar antes de iniciar um resilver.
Pool ZFS FAULTED ou UNAVAIL significa perda definitiva?
Não necessariamente. Esses estados indicam que o ZFS não consegue operar o pool normalmente com o conjunto atual. A recuperação depende da topologia, quantidade de falhas além da redundância, regiões ilegíveis, metadados e histórico de intervenções.
Devo rodar zpool import -f em um pool que não importa?
Não como tentativa genérica. A documentação atual do TrueNAS recomenda importar pools pela WebUI ou API e alerta que import manual pela linha de comando pode causar comportamento inesperado. Pool exportado ou desconectado pode ser importado normalmente; um pool com falha precisa ser diagnosticado antes de forçar operações.
zpool clear destrói os dados?
Não é correto tratar zpool clear como comando que destrói dados por definição. Ele limpa estados de erro em cenários administrativos suportados. O problema é usá-lo sem entender a causa em um pool já instável e permitir novas escritas antes de preservar o estado.
Scrub é perigoso em TrueNAS?
Scrub é uma operação oficial de manutenção do ZFS e faz parte da rotina normal de integridade. Em mídias saudáveis, é apropriado. Em um incidente de recuperação com discos fisicamente degradados, a leitura extensa pode impor carga adicional, por isso o contexto importa.
Resilver sempre deve ser evitado?
Não. A documentação TrueNAS inicia resilver automaticamente após substituição de um disco. Isso é manutenção normal quando o pool está dentro da redundância e os demais membros estão saudáveis. Em dados críticos com outros discos instáveis, pode ser mais seguro clonar antes.
RAIDZ1, RAIDZ2 e RAIDZ3 equivalem a RAID 5, 6 e 7?
Não exatamente. As comparações ajudam a entender quantidade de paridades, mas RAIDZ é uma implementação do ZFS com organização própria. A documentação TrueNAS define RAIDZ1, RAIDZ2 e RAIDZ3 pela quantidade de discos que um VDEV pode perder sem perda de dados.
TrueNAS e FreeNAS são a mesma coisa?
FreeNAS foi unificado com TrueNAS. A iXsystems informa que TrueNAS CORE foi introduzido como continuação do FreeNAS, e a unificação foi concluída em 2021. Hoje, ambientes legados FreeNAS continuam relevantes em recuperação, enquanto as versões atuais TrueNAS Community Edition são Linux-based.
TrueNAS CORE e TrueNAS atual usam o mesmo sistema operacional?
Não. TrueNAS CORE 13.x é FreeBSD-based. A linha atual TrueNAS Community Edition é Linux-based. Ambos usam OpenZFS, mas migração, nomes de dispositivos, ACLs e compatibilidade de recursos devem ser considerados.
Snapshot ZFS pode recuperar arquivo deletado?
Sim, se existir um snapshot criado antes da exclusão e o pool estiver acessível. A documentação TrueNAS define snapshot como uma cópia somente leitura point-in-time e destaca seu uso para restaurar arquivos antigos ou deletados.
Snapshot local é backup?
Não sozinho. O snapshot local depende do mesmo pool. A documentação TrueNAS recomenda copiar ou replicar snapshots para outro sistema para proteção contra falha catastrófica do storage.
Falha de L2ARC derruba o pool?
A documentação TrueNAS informa que a falha de um dispositivo L2ARC não afeta a integridade do pool, embora possa reduzir desempenho de leitura. L2ARC é cache de leitura e não deve ser tratado como membro de dados.
Falha de SLOG sempre causa perda do pool?
Não. SLOG é um dispositivo separado para o ZFS Intent Log e atua em workloads de escrita síncrona. O impacto depende do estado do sistema e do tipo de falha. Não deve ser confundido com L2ARC nem com um data VDEV.
Posso importar os discos TrueNAS em outro servidor?
ZFS foi projetado para permitir importação de pools exportados ou desconectados em outro sistema compatível. A documentação TrueNAS prevê esse fluxo. Em recuperação, porém, se há discos instáveis ou pool corrompido, o ideal é preservar as mídias antes de novas tentativas.
A SECURITY atende TrueNAS e FreeNAS de todo o Brasil?
Sim. A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio seguro dos discos ou equipamentos quando necessário. Em Barueri, este artigo prioriza Alphaville, além de São Paulo e Campinas.
Atendimento para TrueNAS, FreeNAS e ZFS em todo o Brasil
A SECURITY atende clientes de diferentes regiões do Brasil e orienta o envio seguro dos discos, SSDs ou equipamento conforme o cenário. Em Barueri, este artigo prioriza Alphaville.
Alameda Rio Negro, 1030, Conj. 206
Barueri, SP, CEP 06454-000
(11) 98570-8000
Rua Frei Caneca, 1380, Conj. 11
São Paulo, SP, CEP 01307-002
(11) 98570-8000
Rua José Paulino, 1399, Andar 10
Campinas, SP, CEP 13013-001
(19) 99971-7987
Caio Bruno F. Garcia
Especialista em Recuperação de Dados e liderança técnica e estratégica da SECURITY. Atua desde 2005 em recuperação de dados, incluindo RAID, NAS, servidores, Linux, banco de dados, PC-3000, Data Extractor e análise RAID Low Level.
ZFS por dentro: labels, uberblocks, TXGs, MOS, datasets, VDEVs e reconstrução
Esta seção aprofunda as estruturas mais relevantes para compreender por que alguns pools deixam de importar e por que a recuperação deve começar pela camada física quando existe falha de disco.
1. ZFS labels e configuração do pool
Discos pertencentes a um pool ZFS armazenam labels com informações usadas para identificar o pool e sua topologia. Em recuperação, comparar labels entre membros ajuda a entender VDEVs, GUIDs e estados registrados. Membros que passaram por substituições ou alterações podem apresentar informações diferentes.
2. VDEV é a unidade de redundância
O pool distribui dados entre VDEVs de dados. A redundância existe dentro de cada VDEV. Em mirror, existem cópias. Em RAIDZ, existe paridade. A perda completa de um data VDEV pode comprometer o pool inteiro, mesmo quando outros VDEVs estão perfeitos.
3. Uberblocks representam pontos consistentes do pool
ZFS mantém uma sequência de uberblocks que referencia estados transacionais do pool. Em análise forense, estados anteriores podem ajudar a compreender corrupção ou eventos incompletos. Porém, não é correto afirmar que qualquer operação oficial sobrescreve automaticamente todos os uberblocks úteis. O comportamento depende da operação e das escritas efetivamente realizadas.
4. TXG, Copy-on-Write e consistência transacional
ZFS agrupa mudanças em transaction groups. Copy-on-write escreve novas versões em novos blocos antes de atualizar referências. Esse design reduz certos riscos de inconsistência por sobrescrita no lugar, mas não impede perda quando múltiplos membros físicos deixam de fornecer os blocos necessários.
5. MOS e objetos do ZFS
O Meta Object Set contém estruturas centrais de gerenciamento do pool. Datasets, zvols e outros objetos dependem de metadados que conectam árvores e blocos. Quando faltam regiões críticas, o desafio é reconstruir o máximo possível da estrutura sem assumir que todo bloco ainda possui uma réplica válida.
6. Dnodes e blocos de arquivo
Datasets ZFS usam objetos e dnodes para referenciar dados e metadados. Arquivos não são recuperados simplesmente procurando uma tabela única equivalente à MFT. A estrutura distribuída do ZFS exige interpretar árvores, blocos indiretos, checksums e estados transacionais.
7. Checksums detectam corrupção, mas não criam cópia do nada
ZFS usa checksums para validar dados e metadados. Quando existe uma réplica redundante válida, pode reparar um bloco incorreto. Se todas as cópias de um bloco crítico foram perdidas, o checksum detecta o problema, mas não consegue reconstruir informação que não existe em nenhuma réplica ou paridade disponível.
8. Scrub percorre dados para validar integridade
Scrub é uma operação oficial do ZFS. Ele verifica blocos e usa redundância para corrigir inconsistências quando possível. Em recuperação com mídia fisicamente degradada, a preocupação não é "scrub destrói ZFS", mas a carga de leitura extensa em discos que talvez devam ser clonados primeiro.
9. Resilver reconstrói redundância
Ao substituir um disco, TrueNAS inicia resilver para popular o novo membro. A documentação oficial descreve esse processo como manutenção normal. Em um pool com outro disco fortemente degradado, a leitura necessária pode expor erros adicionais. A decisão deve considerar estado físico e criticidade dos dados.
10. Importação de pool é função prevista pelo ZFS
TrueNAS permite importar pools exportados, desconectados, criados em outro sistema ou reconectados após reinstalação. A documentação atual recomenda WebUI ou API para a plataforma. Em recovery, o problema não é a ideia de importação em si, mas forçar uma topologia inconsistente ou trabalhar diretamente em mídias instáveis.
11. FreeNAS legado e migração de plataforma
FreeNAS evoluiu para TrueNAS CORE. A linha CORE usa FreeBSD, enquanto a linha atual TrueNAS é Linux-based. A documentação de migração atual trata o movimento de FreeBSD para Linux como operação planejada e, em algumas rotas, one-way. Em recuperação, preserve a versão e configuração original antes de migrar.
12. L2ARC é cache de leitura
TrueNAS declara que falha de L2ARC não afeta a integridade do pool. Isso o diferencia de data VDEV e special metadata VDEV. Um SSD L2ARC perdido pode reduzir desempenho, mas não deveria ser necessário para reconstruir os dados persistentes do pool.
13. SLOG participa de escritas síncronas
SLOG é o dispositivo separado usado pelo ZFS Intent Log. Ele existe para workloads síncronos e proteção de operações ainda não confirmadas no pool principal. Seu papel não é o mesmo do L2ARC. Em investigação de falha abrupta, preservar o SLOG pode ser relevante dependendo do evento.
14. Special VDEV pode ser crítico
TrueNAS alerta que Metadata VDEVs são críticos para pool e integridade. Se um special VDEV armazena metadata essencial e perde todas as réplicas, o pool pode ficar inacessível. Nunca descarte um SSD auxiliar sem identificar sua classe.
15. Dedup adiciona dependência da DDT
Quando dedup foi utilizada, a Deduplication Table é uma estrutura fundamental do pool. A recuperação precisa considerar que muitos blocos podem ser referenciados por múltiplos objetos. Perda de metadata de dedup pode ter impacto desproporcional em relação ao tamanho físico da região afetada.
16. Snapshots e versões anteriores
Snapshots preservam referências a estados anteriores. Eles são úteis para exclusão, ransomware e rollback, mas não são independentes do pool. Se um VDEV crítico foi perdido, snapshots também podem ficar inacessíveis até que a base do pool seja reconstruída.
17. zvols e virtualização
Um zvol pode ser um disco de bloco completo. Depois da recuperação ZFS, pode ser necessário analisar GPT, NTFS, ReFS, VMFS, LVM ou outro formato dentro dele. O trabalho termina no dado útil, não no primeiro objeto extraído.
18. Matriz técnica de decisão
| Sintoma | Camada provável | Prioridade | Evitar |
|---|---|---|---|
| Pool DEGRADED, dados acessíveis | Disco/VDEV | Backup validado e saúde dos demais membros | Ignorar segundo disco com erros |
| Pool FAULTED/UNAVAIL | VDEV, mídia, topologia, metadata | Mapear e adquirir membros | Criar pool novo |
| Resilver travado | Outro disco instável | Diagnóstico físico e clonagem | Repetir sem análise |
| Pool não importa após reinstalação | Import/configuração/SED | Usar fluxo suportado e preservar | Wipe dos membros |
| Boot pool falhou | Sistema TrueNAS | Diferenciar boot e data pool | Recriar data pool |
| Snapshot necessário | Dataset/zvol | Localizar snapshot point-in-time | Novas escritas |
| L2ARC falhou | Cache de leitura | Confirmar papel do dispositivo | Tratar como data VDEV |
| Special VDEV falhou | Metadata/small blocks | Preservar todas as réplicas | Descartar como cache |
| zvol com VM offline | ZFS + filesystem interno | Recuperar zvol e validar camada interna | Parar no arquivo bruto |
19. Conclusão técnica
TrueNAS e FreeNAS são ambientes em que a precisão de diagnóstico importa tanto quanto a ferramenta. ZFS possui recursos oficiais de import, scrub, replacement e resilver que são seguros quando usados no contexto correto. Em recuperação, o diferencial está em reconhecer quando o caso saiu da manutenção normal e passou a exigir preservação física, reconstrução de VDEVs e análise sobre imagens.
Referências utilizadas neste guia
A E-Recovery foi usada apenas como benchmark editorial, semântico e de intenção de busca. As afirmações técnicas foram redigidas de forma original e confrontadas com documentação oficial TrueNAS/iXsystems.
- TrueNAS ZFS Primer
- TrueNAS: Replacing Disks e resilver
- TrueNAS: Import Pool
- TrueNAS: Creating Snapshots
- TrueNAS: ZFS ZIL and SLOG
- TrueNAS: L2ARC
- TrueNAS: Fusion Pools e Metadata VDEVs
- TrueNAS: ZFS Deduplication e DDT
- TrueNAS: Community Migrations FreeBSD para Linux
- TrueNAS History: unificação FreeNAS e TrueNAS
