TrueNAS com Pool Offline: Como Recuperar os Dados
Por Equipe Técnica HD Doctor
Resposta direta
Pool do TrueNAS em UNAVAIL ou FAULTED quase nunca significa dados perdidos. O ZFS marca o pool inteiro como indisponível assim que a redundância acaba — mesmo quando os discos continuam legíveis. Na maioria dos casos que recebemos, 90% ou mais dos setores estavam íntegros e o que faltava era ordem de diagnóstico, não hardware novo.
As três camadas do TrueNAS que podem falhar
Entender o que quebrou evita a troca de disco que destrói o caso. (1) O boot-pool é separado do storage: fica no SSD ou pendrive de instalação e não guarda um byte dos seus dados. Boot-pool morto derruba o sistema, não o pool — reinstalar o TrueNAS e subir o arquivo de configuração devolve datasets, shares e permissões. (2) O data pool é um conjunto de vdevs. A unidade de falha é o vdev, não o disco: em RAIDZ1, o segundo disco fora do mesmo vdev já derruba o pool inteiro; perder um vdev special (metadados) derruba o pool mesmo com todos os outros saudáveis. (3) A configuração do middleware vive em /data/freenas-v1.db — e é ali que ficam também as chaves de datasets criptografados. Perder esse banco sem ter exportado as chaves torna dado criptografado irrecuperável, inclusive para laboratório. Vale ainda a diferença de linha: o TrueNAS CORE (FreeBSD, criptografia GELI legada) chegou ao fim com o 13.3-U1.2 e o desenvolvimento seguiu no SCALE, hoje TrueNAS Community Edition (Linux, criptografia nativa do ZFS). Migração mal feita entre as duas linhas é causa frequente de chamado. As origens mais comuns de pool offline: HBA ou expander com defeito, cabo SAS/SATA marginal, fonte oscilando, discos do mesmo lote envelhecendo juntos, RAM sem ECC corrompendo escrita e, muito frequente, export ou destroy acidental pela interface.
O que nunca fazer com um pool TrueNAS caído
- 1.Trocar disco 'para testar'. Substituição dispara resilver, que grava em todos os membros. Em pool sem redundância restante, é a causa número um de perda definitiva.
- 2.Rodar zpool import -f como primeira tentativa. O -f ignora a proteção de hostid e pode montar o pool para escrita a partir de estado inconsistente. Primeiro readonly=on, sempre.
- 3.Aceitar zpool clear ou scrub em pool degradado. Scrub lê todos os discos em carga máxima. Com disco já morrendo, costuma terminar de derrubar o membro que ainda respondia.
- 4.Reinstalar o TrueNAS antes de salvar o freenas-v1.db. A reinstalação recria o boot-pool e leva junto a configuração e as chaves de criptografia. Datasets criptografados sem chave são perda total.
- 5.Usar controladora RAID em vez de HBA em modo IT. Controladora RAID esconde os discos e o SMART do ZFS, mantém cache próprio e corrompe o pool em queda de energia. Se o pool foi montado assim, informe o laboratório — muda todo o procedimento.
- 6.Confiar em snapshot como se fosse backup. Snapshot ZFS vive dentro do mesmo pool. Pool perdido, snapshots perdidos junto. Só replicação para outro sistema conta como backup.
Como diagnosticar um pool TrueNAS offline, em 7 passos
Ordem de diagnóstico da HD Doctor para pools ZFS. Não troque nem substitua nenhum disco antes de concluir o passo 3.
- 1
Não substitua disco e não force resilver
Um zpool replace em pool já sem redundância inicia gravação em todos os membros e é a forma mais rápida de perder um caso recuperável. Enquanto o diagnóstico não terminar, o pool deve ficar parado, sem escrita e sem substituição.
- 2
Leia o estado real do pool sem importar
Rode zpool import sem argumentos: ele lista os pools visíveis, o estado de cada vdev e por que a importação falha. Complemente com zdb -l /dev/disk/by-id/<disco> em cada membro para ver se os labels ZFS ainda existem. Isso é leitura pura, não altera nada.
- 3
Avalie a saúde física de todos os discos
smartctl -a em cada membro, olhando setores realocados, pending sectors e erros de UDMA/CRC (que costumam indicar cabo ou backplane, não disco). Se dois ou mais discos mostram problema físico, o caso é de laboratório: cada tentativa de importação a mais reduz o que ainda se lê.
- 4
Faça imagem dos discos suspeitos antes de qualquer importação
Discos com setores instáveis pioram a cada leitura. Clone com ddrescue ou hardware de imagem, com log de progresso, e trabalhe sobre as cópias. Se todos os discos estão fisicamente sãos e o problema é lógico, pode-se seguir direto no passo 5 — com importação somente leitura.
- 5
Importe somente leitura, corrigindo o caminho dos discos
zpool import -o readonly=on -d /dev/disk/by-id <pool>. O -d resolve a maioria dos casos em que o pool 'sumiu' após troca de HBA ou reinstalação, porque os discos mudaram de nome. Se a recusa for por hostid de outra máquina, o -f junto com readonly=on é seguro; sozinho, não é.
- 6
Recupere a configuração e as chaves de criptografia
Antes de reinstalar qualquer coisa, resgate /data/freenas-v1.db do boot-pool — é ele que devolve shares, datasets e, no caso de pools criptografados, as chaves. Em TrueNAS CORE antigo com GELI, o arquivo de chave e a passphrase são obrigatórios: sem eles, nem o laboratório recupera.
- 7
Extraia os dados antes de tentar reparar o pool
Com o pool importado em somente leitura, copie o conteúdo para storage externo, de preferência com zfs send dos datasets ou rsync com verificação. Só depois de ter cópia validada faz sentido tentar rewind de transação (zpool import -F ou -X) ou substituição de disco — operações que, se falharem, deixam o pool pior do que estava.
Perguntas frequentes
Meu pool TrueNAS aparece como UNAVAIL. Os dados foram perdidos?
Provavelmente não. UNAVAIL significa que faltam membros suficientes para montar com segurança, não que os dados sumiram. Discos desconectados, HBA com defeito, cabo ruim ou nomes de dispositivo trocados produzem exatamente essa mensagem com 100% dos dados intactos. Diagnostique antes de tocar em hardware.
Perdi o pendrive de boot do TrueNAS. Perdi tudo?
Não. O boot-pool não guarda dados. Reinstale a mesma versão do TrueNAS, importe o pool e, se tiver o arquivo de configuração salvo, suba-o para restaurar shares e permissões. Sem a configuração, o pool ainda importa — você só refaz os compartilhamentos manualmente. A exceção é dataset criptografado sem chave exportada.
Quantos discos posso perder em um pool ZFS antes de perder tudo?
Depende do vdev, não do pool: mirror de 2 discos tolera 1; RAIDZ1 tolera 1; RAIDZ2 tolera 2; RAIDZ3 tolera 3 — por vdev. Como os vdevs são somados em stripe, perder um vdev inteiro derruba o pool completo, mesmo que os demais estejam perfeitos. Por isso RAIDZ1 com discos grandes é arriscado: a chance de um segundo disco falhar durante o resilver é real.
Dá para recuperar um pool ZFS que foi exportado ou destruído por engano?
Na maioria dos casos sim, se nada foi gravado depois. O destroy não apaga os dados, apenas invalida os labels. A recuperação usa zpool import -D ou reconstrução dos labels a partir dos uberblocks antigos, sempre sobre imagem dos discos. Cada escrita nova no pool reduz essa janela — desligue o equipamento.
TrueNAS CORE ainda é seguro de usar em 2026?
Funciona, mas está em fim de vida: o 13.3-U1.2 foi a última versão da linha CORE e o desenvolvimento seguiu no SCALE, hoje TrueNAS Community Edition. Para ambiente de produção, planeje a migração — e faça backup completo antes, porque conversão de pool e mudança de esquema de criptografia (GELI para nativa do ZFS) são momentos de risco.
Vocês recuperam TrueNAS com dataset criptografado?
Sim, desde que exista a chave ou a passphrase. Criptografia nativa do ZFS e GELI são matematicamente sólidas: sem material de chave não há recuperação, por laboratório nenhum. Se você tem o arquivo de chave ou o freenas-v1.db, o caso é tratável normalmente.
Preciso enviar o servidor inteiro ou só os discos?
Em geral só os discos, identificados na ordem original das baias — fotografe antes de remover. Guarde também o boot-pool ou uma cópia da configuração. Se o pool usa vdev special ou SLOG em NVMe, esses dispositivos precisam vir junto: sem o special, o pool não reconstrói.
TrueNAS fora do ar? Não troque disco antes de diagnosticar.
Diagnóstico em 24h para pools ZFS, TrueNAS CORE e SCALE. NDA antes do envio.