Um NAS com Btrfs que ficou inacessível ou perdeu arquivos coloca o responsável diante de um dilema: agir rápido e arriscar apagar qualquer chance de recuperação, ou parar e não saber por onde começar. Pior ainda quando o painel do fabricante não explica o que houve e cada reinício parece enterrar mais fundo o problema. Este texto mostra como recuperar dados de NAS com Btrfs com segurança, do diagnóstico inicial às alternativas quando o volume não monta.
O que muda quando o Btrfs está dentro de um NAS
Recuperar dados de NAS com Btrfs não é a mesma coisa que recuperar um disco interno formatado com esse sistema de arquivos. No desktop, o Btrfs é uma escolha do usuário, com layout previsível e ferramentas que rodam no mesmo ambiente onde o sistema foi criado. Dentro de um NAS, o Btrfs chega empacotado por uma camada de software do fabricante — QNAP, Synology, Asustor, Netgear — que altera a forma como volumes, metadados e redundância são gravados no disco.
Essa camada proprietária é a primeira barreira para qualquer tentativa de recuperação. Um NAS Synology com Btrfs, por exemplo, grava o sistema em uma partição RAID própria do DSM, separada do volume de dados. Um QNAP com QuTS hero usa ZFS em alguns modelos e Btrfs em outros, com estruturas de subvolume que não seguem o padrão de um Linux comum. Quem conecta o disco direto em um computador esperando montar o Btrfs como se fosse um pendrive costuma encontrar um cenário bem diferente: partições com nomes como md0, md1 ou vg1, montadas via LVM ou mdadm antes mesmo de o Btrfs aparecer.
O ponto central é que o Btrfs dentro do NAS raramente está sozinho. Ele opera sobre um RAID via software (mdadm ou RAID próprio do fabricante), dentro de um gerenciador de volumes lógicos e sob um sistema operacional que controla snapshots, cotas e replicação. Recuperar dados de NAS com Btrfs, portanto, exige reconstruir essa pilha na ordem certa — e qualquer erro nessa sequência pode transformar um problema de montagem em perda definitiva.
Btrfs em NAS: volumes, subvolumes e snapshots gerenciados pelo fabricante
O Btrfs organiza dados em subvolumes, que funcionam como sistemas de arquivos independentes dentro do mesmo volume. No NAS, o fabricante usa esses subvolumes para isolar pastas compartilhadas, snapshots e até versões de sistema. Um Synology com Btrfs, por exemplo, cria um subvolume para cada pasta compartilhada quando o recurso de snapshot está ativo; o QNAP faz algo semelhante com snapshots agendados em subvolumes ocultos.
Essa estrutura tem uma consequência direta na recuperação: o arquivo apagado pode ainda existir dentro de um snapshot, mesmo que o subvolume ativo já não o liste. Em um desktop, o usuário saberia navegar por snapshots/ manualmente. No NAS, esses snapshots ficam gerenciados pelo painel do fabricante — e, quando o sistema não sobe, o acesso a eles depende de montar o Btrfs fora do aparelho e percorrer a árvore de subvolumes com ferramentas específicas.
Há também o caso do snapshot corrompido. Se o firmware do NAS gravou um snapshot no momento exato de uma queda de energia, o checksum do Btrfs pode acusar corrupção nesse subvolume. O dado original continua íntegro em outro lugar do disco, mas o sistema de arquivos passa a recusar a montagem ou entra em modo somente leitura. Forçar a remoção do subvolume problemático sem antes mapear a árvore inteira é uma das formas mais rápidas de perder o que ainda estava recuperável.
RAID de Btrfs (single, DUP, RAID1, RAID1C3, RAID10) e o que isso muda na recuperação
O Btrfs tem perfis de alocação próprios que definem como dados e metadados são distribuídos entre os discos. Os principais perfis usados em NAS são:
- single: uma cópia em um único disco, sem redundância
- DUP: duas cópias no mesmo disco, usada para metadados em discos únicos
- RAID1: duas cópias em discos diferentes, tolera a perda de um disco
- RAID1C3: três cópias em discos diferentes, tolera a perda de dois
- RAID10: espelhamento com distribuição por faixas, combina desempenho e redundância
Esses perfis não são equivalentes ao RAID de hardware nem ao mdadm. No Btrfs, o RAID opera no nível de bloco lógico, não de disco inteiro: um volume pode ter dados em RAID1 e metadados em RAID1C3 ao mesmo tempo. Isso muda o diagnóstico, porque um disco fisicamente morto pode não significar perda imediata de dados — desde que o perfil de alocação tenha redundância suficiente e o pool não tenha sido montado em modo degradado por tempo demais.
O perigo aparece quando o NAS é reiniciado com um disco ausente e o Btrfs monta o volume degradado. Nesse estado, o sistema continua gravando — e cada gravação altera a distribuição de blocos entre os discos restantes. Se o disco removido voltar depois, o Btrfs pode considerá-lo obsoleto e iniciar um rebuild que sobrescreve os dados bons com informações inconsistentes. Em cenários assim, a recomendação técnica é clara: não religue o aparelho, não insira o disco de volta e não deixe o scrub rodar antes de uma cópia bit a bit de todos os discos.
O RAID1C3, disponível em kernels Linux mais recentes e adotado por alguns fabricantes para metadados, ilustra bem a complexidade. Ele grava três cópias de metadados, mas o perfil de dados pode continuar em RAID1. Um diagnóstico que enxerga apenas o RAID1 e ignora o RAID1C3 pode concluir erroneamente que o volume está íntegro quando, na verdade, os metadados estão em processo de corrupção silenciosa. Recuperar dados de NAS com Btrfs exige ler os perfis reais de cada bloco, não o rótulo genérico que o painel do fabricante exibe.
Quando o problema é o NAS e não o Btrfs: controladora, backplane e firmware
Nem toda falha em um NAS com Btrfs é falha do sistema de arquivos. Antes de culpar o Btrfs, é preciso separar as camadas: o disco pode estar íntegro, o Btrfs pode estar consistente, e ainda assim o NAS não entregar os dados. As causas mais comuns estão na eletrônica do aparelho, não no software.
- Controladora SATA/SAS defeituosa: corrompe gravações e gera erros de leitura intermitentes
- Backplane com mau contato: disco some e reaparece, forçando rebuilds desnecessários
- Firmware corrompido: impede o boot do sistema, mas os discos continuam íntegros
- Fonte com tensão instável: provoca desligamentos abruptos durante gravações de metadados
- Memória RAM defeituosa: gera checksums inválidos que o Btrfs interpreta como corrupção de dados
O caso da memória RAM é particularmente traiçoeiro. O Btrfs calcula o checksum dos dados antes de gravá-los; se a RAM corrompe o bloco antes do cálculo, o checksum é gravado sobre o dado já corrompido — e o sistema de arquivos passa a considerar aquele bloco como válido. A corrupção só aparece meses depois, quando o arquivo é lido e não bate com o que o usuário esperava. Nesse cenário, o scrub do Btrfs pode não acusar nada, porque o checksum confere com o dado corrompido gravado.
Quando o problema é o backplane ou a controladora, a leitura dos discos fora do NAS é o caminho mais seguro. Conectar cada disco individualmente a uma bancada com bloqueio de gravação permite avaliar se o Btrfs está íntegro sem depender do hardware do aparelho. Se o sistema de arquivos montar em modo somente leitura fora do NAS, o diagnóstico aponta para a eletrônica do equipamento — e a recuperação pode ser feita copiando os dados para outro destino, sem tocar no aparelho original. O artigo sobre disco piscando vermelho detalha como interpretar os sinais físicos do aparelho antes de qualquer intervenção.
Diagnóstico antes de qualquer escrita: o passo que define o resultado
A regra mais importante para recuperar dados de NAS com Btrfs é não escrever nada nos discos antes de entender o que aconteceu. Cada gravação — mesmo uma montagem em modo leitura/escrita, um scrub, um balance ou um rebuild — altera a estrutura do sistema de arquivos e pode sobrescrever exatamente os blocos que ainda continham os dados perdidos.
O diagnóstico deve responder a quatro perguntas, nessa ordem:
- O dado foi apagado logicamente ou há falha física em algum disco?
- O Btrfs está com o pool íntegro, degradado ou com metadados corrompidos?
- Existe snapshot ou subvolume que ainda contenha o dado?
- O problema está no sistema de arquivos ou na eletrônica do NAS?
Sem responder a primeira pergunta, qualquer ação é aposta. Um arquivo apagado em Btrfs pode ter seus metadados ainda presentes na árvore, mas com os extents liberados para reuso; se o NAS continuar ligado, o sistema pode reutilizar esses blocos a qualquer momento. Já uma falha física em um disco exige interromper o funcionamento imediatamente — cada hora ligado aumenta a degradação da superfície e reduz a janela de leitura.
Para quem tem um NAS em produção, a ordem prática é: desligar o aparelho, remover os discos, etiquetar a posição de cada um (slot 1, slot 2, slot 3) e não religar nada até ter uma cópia bit a bit de todos os discos. A etiquetagem importa porque o Btrfs distribui blocos entre os discos conforme a ordem em que foram adicionados ao pool; trocar a posição física não impede a leitura, mas gera confusão na hora de reconstruir o volume em bancada.
Por que ligar o NAS e deixar o scrub ou balance rodar pode destruir a evidência
O scrub do Btrfs lê todos os blocos e verifica checksums; quando encontra um erro, tenta corrigi-lo usando a cópia redundante. O problema é que essa correção grava no disco — e, se o diagnóstico estiver errado, grava por cima de dados que ainda poderiam ser lidos com ferramentas de baixo nível. O scrub não é uma ferramenta de recuperação; é uma ferramenta de manutenção preventiva para sistemas íntegros.
O balance é ainda mais arriscado em cenário de falha. Ele reescreve todos os dados para redistribuir blocos entre os discos, o que significa leitura e gravação massiva. Em um pool degradado ou com metadados corrompidos, o balance pode falhar no meio do processo e deixar o sistema de arquivos em estado inconsistente — pior do que estava antes. Em um disco com falha física incipiente, o balance acelera a degradação ao forçar leituras repetidas em setores instáveis.
Há relatos técnicos bem documentados de volumes Btrfs que montavam em modo somente leitura e, após um scrub automático agendado pelo fabricante, passaram a recusar montagem por completo. O scrub corrigiu um checksum usando uma cópia que também estava corrompida, propagando o erro para o bloco que ainda era legível. Por isso, a primeira ação em um NAS com suspeita de falha é desativar qualquer tarefa agendada de scrub, balance ou snapshot — de preferência, desligando o aparelho antes que a próxima execução aconteça.
Leitura dos discos fora do NAS: imagem bit a bit e montagem somente leitura
A leitura segura começa pela cópia bit a bit de cada disco, feita em hardware com bloqueio de gravação. Essa imagem preserva o estado original do disco e permite trabalhar sobre a cópia sem risco de alterar a evidência. Em discos com setores instáveis, a imagem é feita com ferramentas que pulam setores ilegíveis e seguem adiante, registrando um mapa das áreas não lidas — informação essencial para saber o que pode estar faltando no Btrfs.
Com as imagens prontas, o volume Btrfs é montado em um Linux com as opções ro (somente leitura) e, idealmente, norecovery ou skip_balance para impedir qualquer replay de journal ou retomada de operação pendente. A montagem somente leitura permite navegar pelos subvolumes e snapshots sem que o kernel grave nada — nem mesmo atualização de atime. É nesse ambiente que se verifica se o dado apagado ainda existe em algum snapshot ou se o subvolume ativo está íntegro.
Para quem não tem familiaridade com Linux, a alternativa é enviar os discos a um laboratório que faça essa leitura em bancada. A tentativa de montar o Btrfs no Windows, com drivers de terceiros, não oferece as mesmas garantias de somente leitura e pode gravar metadados no volume sem aviso. O mesmo vale para conectar os discos a outro NAS do mesmo fabricante: o aparelho pode iniciar automaticamente um rebuild ou uma verificação de consistência que grava no volume antes que o usuário perceba.
Snapshots e subvolumes como via de recuperação que quase ninguém explora
O recurso de snapshot do Btrfs é a via de recuperação mais subutilizada em NAS. Quando o fabricante mantém snapshots agendados, cada pasta compartilhada pode ter dezenas de versões anteriores — e o arquivo apagado ou sobrescrito continua intacto em um deles. Em um desktop, o usuário acessaria snapshots/ diretamente; no NAS, esses snapshots ficam ocultos no painel e, com o sistema fora do ar, só aparecem quando o volume é montado fora do aparelho.
A navegação por subvolumes segue uma lógica de árvore: o subvolume raiz contém os subvolumes de dados, e cada subvolume de dados pode ter uma pasta .snapshots com versões datadas. Um arquivo apagado há três dias pode estar em um snapshot de cinco dias atrás, com conteúdo idêntico ao original. A recuperação, nesse caso, é uma cópia simples — sem necessidade de carving, reconstrução de extents ou qualquer escrita no volume original.
Há também o cenário do subvolume deletado. Quando um subvolume inteiro é removido no Btrfs, seus dados não são apagados imediatamente; os extents ficam órfãos até serem reutilizados. Ferramentas de recuperação específicas para Btrfs conseguem localizar esses extents órfãos e reconstruir parte do subvolume removido — desde que nenhuma gravação posterior tenha reutilizado os blocos. Quanto mais cedo o NAS for desligado após a exclusão, maior a chance de recuperação íntegra.
O que fazer quando btrfs check e btrfs rescue não resolvem
As ferramentas nativas do Btrfs — btrfs check, btrfs rescue, btrfs restore — são úteis em cenários específicos, mas têm limitações sérias em falhas reais de NAS. O btrfs check com a opção –repair é documentado pelos próprios desenvolvedores como último recurso, porque pode corromper ainda mais um sistema de arquivos já danificado. O btrfs restore varre o volume em busca de arquivos reconhecíveis, mas não reconstrói a árvore de diretórios com precisão e perde nomes, permissões e estrutura de pastas em muitos casos.
Quando essas ferramentas falham — ou quando o risco de usá-las é alto demais —, restam dois caminhos: a recuperação manual em nível de bloco ou o envio a um laboratório especializado. A recuperação manual exige conhecimento profundo da estrutura interna do Btrfs: árvore de extents, árvore de checksums, superblocos e journal. Um erro na interpretação de um único ponteiro pode levar à sobrescrita de dados que ainda estavam íntegros.
O artigo sobre tentar recuperar HD sozinho detalha por que ferramentas caseiras aumentam o risco de perda definitiva. No contexto de Btrfs em NAS, o risco é multiplicado pela complexidade da pilha: RAID via software, LVM, subvolumes e snapshots interagem de formas que uma ferramenta genérica não consegue mapear sozinha.
Sinais de que o caso exige intervenção profissional
Alguns sintomas indicam que a janela para recuperação caseira já se fechou e que cada nova tentativa só reduz a chance de sucesso:
- O volume não monta nem em modo somente leitura após várias tentativas
- O btrfs check reporta erros na árvore de extents ou no superbloco
- Um ou mais discos apresentam ruído, cliques ou setores ilegíveis
- O NAS foi desligado incorretamente durante um rebuild ou balance
- Há indícios de que o scrub já rodou e piorou o estado do volume
- Os dados têm valor jurídico, contábil ou operacional e não podem ser corrompidos
Em discos com falha física, a leitura em bancada com bloqueio de gravação é pré-requisito. Um laboratório com sala limpa consegue trocar cabeças de leitura ou estabilizar a eletrônica do disco antes de tentar a cópia bit a bit — etapa impossível de improvisar fora desse ambiente. Para empresas, a parada de um NAS com Btrfs pode significar interrupção de produção, como aborda o artigo sobre parada de produção.
O mesmo vale para escritórios contábeis e jurídicos, onde a integridade dos dados é questão regulatória. O artigo sobre escritório de contabilidade mostra como a cadeia de custódia e o sigilo importam tanto quanto o resultado técnico.
Erros que transformam perda recuperável em perda definitiva
Há uma sequência de erros recorrentes em casos de NAS com Btrfs que chegam a laboratórios já em estado irreversível. O primeiro é religar o aparelho repetidamente para “ver se volta”. Cada boot executa scripts de montagem, verificação de RAID e, em alguns fabricantes, scrub automático — tudo isso grava no volume. O segundo é inserir um disco que foi removido de volta no slot errado, forçando o RAID a reconstruir com um disco obsoleto. O artigo sobre dois discos com falha detalha esse cenário.
O terceiro erro é usar ferramentas de recuperação genéricas diretamente sobre os discos originais, sem imagem prévia. Qualquer ferramenta que grave no disco — mesmo que seja para “reparar” o sistema de arquivos — está destruindo a evidência original. O quarto erro é formatar o volume ou recriar o pool para “começar de novo”, acreditando que os dados podem ser recuperados depois. Em Btrfs, a recriação do sistema de arquivos sobrescreve superblocos e árvores de metadados, tornando a recuperação de arquivos íntegros inviável na maioria dos casos.
Por fim, o erro de confiar no backup sem verificar. Um NAS com Btrfs pode ter snapshots locais que parecem backup, mas não são: se o disco falhar, os snapshots morrem junto com os dados. Backup de verdade é cópia externa, em outro dispositivo ou nuvem. Quem descobre isso depois da falha do NAS está exatamente na situação que este artigo descreve — e o tempo entre a falha e a decisão de buscar ajuda técnica é o fator que mais influencia o resultado.
