Quando um arquivo ou uma pasta some do NAS, o reflexo é abrir o gerenciador de snapshots e restaurar dali mesmo. Só que, às vezes, o snapshot não está mais lá, aparece com erro ou simplesmente não monta — e aí a situação deixa de ser um clique de rotina. Este texto mostra como recuperar dados de snapshot do NAS em cenários que fogem do procedimento padrão: snapshot corrompido, retenção expirada, volume inacessível e o que fazer antes de qualquer tentativa.
O que é um snapshot de NAS e por que ele não é um backup
Um snapshot de NAS é um registro pontual do estado de um volume ou dataset em um instante específico. Ele não copia arquivos inteiros para outra mídia: registra metadados e ponteiros que apontam para os blocos de dados como existiam naquele momento. Em sistemas como ZFS e Btrfs, a criação de um snapshot leva segundos e consome pouco espaço inicialmente, porque apenas as alterações posteriores geram novos blocos — o snapshot preserva os blocos antigos por referência.
Essa arquitetura explica o erro mais comum na gestão de NAS: tratar snapshot como sinônimo de backup. Um backup é uma cópia independente, em outra mídia ou outro equipamento, que sobrevive à falha física do NAS original. Um snapshot vive no mesmo conjunto de discos que os dados de produção. Se o volume falhar, o snapshot falha junto. A proteção contra perda definitiva exige ambas as camadas — snapshot para retorno rápido a estados anteriores e backup para recuperação após falha catastrófica de hardware.
Snapshot, versão de arquivo e backup: as diferenças que decidem o resgate
Snapshot, versionamento de arquivo e backup respondem a perguntas diferentes. O snapshot responde “como estava o volume inteiro às 14h de terça-feira?”. O versionamento de arquivo responde “quais versões deste documento existiram nos últimos 30 dias?”. O backup responde “onde está a cópia independente que sobrevive se o NAS queimar?”. Em um NAS Synology com Btrfs, por exemplo, o Snapshot Replication gerencia snapshots de volume, enquanto o versionamento pode ocorrer dentro de pastas compartilhadas — e nenhum dos dois substitui o Hyper Backup gravando em outro destino.
Na prática, a diferença decide o resgate. Um arquivo sobrescrito por engano pode ser recuperado de um snapshot de ontem ou de uma versão anterior do arquivo — ambos resolvem. Já um volume com corrupção de metadados Btrfs pode tornar todos os snapshots ilegíveis, porque eles compartilham a mesma árvore de metadados. Nesse cenário, apenas o backup externo ou a recuperação em laboratório do volume subjacente oferece saída. Entender qual camada falhou é o primeiro passo do diagnóstico.
Sinais de que o snapshot foi corrompido, expirou ou foi apagado
Os sintomas variam conforme o sistema de arquivos e a interface do fabricante, mas alguns padrões se repetem:
- Snapshot listado com tamanho zerado ou data incorreta no Snapshot Manager
- Erro de checksum ao tentar montar ou clonar o snapshot
- Snapshot desaparece da lista após reinício do NAS ou atualização de firmware
- Restauração inicia e falha no meio, com mensagem de I/O error ou inconsistent metadata
- Retenção automática removeu snapshots antigos antes da restauração ser tentada
- Volume entra em modo somente leitura e todos os snapshots ficam inacessíveis
Em QNAP com QuTS hero usando ZFS, um snapshot corrompido costuma aparecer com status de erro no zpool status, indicando falha de checksum em blocos referenciados. Em Synology com Btrfs, o sintoma típico é a impossibilidade de navegar pelo snapshot no File Station, mesmo com o snapshot ainda listado. Identificar o sintoma exato antes de qualquer ação é o que separa um resgate viável de uma perda definitiva por manipulação incorreta.
Antes de restaurar: pare de escrever no volume e preserve a evidência
A regra mais importante na recuperação de dados de NAS é não agravar o problema. Cada gravação no volume — incluindo a própria tentativa de restauração mal planejada, a recriação de snapshots ou a execução de scrub — pode sobrescrever blocos que ainda seriam recuperáveis. Em sistemas copy-on-write como ZFS e Btrfs, o espaço liberado por snapshots apagados volta a ser reutilizado rapidamente, e blocos antigos são os primeiros a serem sobrescritos.
Antes de qualquer comando, o volume deve ser congelado ou o NAS desligado de forma controlada. Em ambiente corporativo com RAID, isso significa também documentar a ordem física dos discos, os números de série e a configuração do arranjo antes de qualquer intervenção. A documentação prévia é o que permite reconstruir um RAID degradado depois, caso a leitura do snapshot exija acesso direto aos discos.
Como congelar o volume e registrar o estado atual do NAS
O congelamento pode ser feito de três formas, em ordem crescente de segurança:
- Colocar o volume em modo somente leitura pela interface do fabricante, se disponível
- Interromper todos os serviços de escrita: SMB, NFS, iSCSI, replicação e tarefas agendadas
- Desligar o NAS pelo botão de energia com o procedimento de shutdown do sistema, nunca por corte brusco
O registro do estado atual inclui a versão do firmware, o modelo exato do NAS, a configuração de RAID, a lista de snapshots com datas e tamanhos, e qualquer mensagem de erro exibida. Em NAS com suporte a SSH, o comando zpool status (ZFS) ou btrfs filesystem show (Btrfs) gera um relatório que deve ser salvo fora do equipamento. Esses dados são a base para qualquer diagnóstico posterior, seja interno ou com suporte especializado.
Quando o snapshot ainda existe mas está inconsistente
Snapshot inconsistente é aquele que aparece na listagem, mas não pode ser montado, clonado ou navegado sem erro. A inconsistência pode ter origem em setores defeituosos nos discos, em corrupção de metadados do sistema de arquivos, em interrupção de energia durante a criação do snapshot ou em bug de firmware após atualização. O sintoma clássico em ZFS é o erro de checksum ao acessar blocos referenciados pelo snapshot; em Btrfs, a falha costuma ocorrer na leitura da árvore de extents.
Nesse cenário, a pior decisão é forçar a remoção do snapshot inconsistente para “limpar” o volume. A remoção pode liberar espaço, mas também elimina a única referência a blocos que ainda contêm os dados originais. A conduta correta é preservar o snapshot no lugar, parar toda escrita e partir para leitura direta do volume ou para diagnóstico em laboratório. Quanto menos operações forem executadas no NAS, maior a chance de resgate dos blocos íntegros.
Recuperar arquivos de um snapshot íntegro pela interface do NAS
Quando o snapshot está íntegro, a restauração pela interface gráfica é o caminho mais rápido e seguro. Cada fabricante implementa o fluxo de forma ligeiramente diferente, mas o princípio é o mesmo: selecionar o snapshot desejado, navegar pela estrutura de pastas como ela existia naquele instante e copiar os arquivos ou pastas de volta ao volume ativo — ou para outro destino, preferencialmente.
A restauração seletiva é sempre preferível à restauração completa do volume. Restaurar o volume inteiro a partir de um snapshot reverte todas as alterações posteriores, incluindo arquivos criados ou modificados depois do snapshot que não deveriam ser perdidos. Copiar apenas o que foi excluído ou corrompido evita esse efeito colateral e reduz o tempo de indisponibilidade.
Synology DSM: Snapshot Replication e File Station
Em um NAS Synology com Btrfs, o Snapshot Replication permite criar e gerenciar snapshots de pastas compartilhadas e LUNs. Para recuperar um arquivo excluído, o caminho mais simples é o File Station: clique com o botão direito na pasta compartilhada, escolha a opção de navegar por snapshots anteriores, selecione a data desejada e copie o arquivo de volta. O File Station monta o snapshot em modo somente leitura, sem risco de alteração acidental.
Para restauração de uma pasta inteira ou de um LUN, o Snapshot Replication oferece o fluxo de restauração com opção de destino — pasta original ou nova localização. A restauração para uma nova localização é a opção mais segura quando há dúvida sobre o estado atual dos dados. O DSM também permite agendar snapshots com retenção por número de versões ou por período, mas essa configuração não substitui a cópia externa.
QNAP QuTS hero: Snapshot Manager e restauração seletiva
No QuTS hero, sistema baseado em ZFS, o Snapshot Manager centraliza a criação, retenção e restauração de snapshots. A restauração seletiva é feita pelo File Station, que exibe os snapshots como pastas somente leitura com a data e hora no nome. Basta navegar até o arquivo desejado e copiá-lo de volta ao volume ativo. O QuTS hero também suporta clonagem de snapshot, que cria um novo dataset gravável a partir do estado congelado — útil quando é preciso trabalhar sobre os dados sem tocar no original.
Uma particularidade do ZFS no QuTS hero é a integração com o zpool status: se houver erros de checksum nos discos, o sistema pode degradar o pool e afetar a leitura dos snapshots. Antes de tentar restaurar, vale verificar a saúde do pool na interface. Se houver disco com falha, a prioridade muda: disco piscando vermelho e estabilizar o arranjo antes de qualquer restauração.
TrueNAS SCALE: snapshots ZFS e clones de dataset
No TrueNAS SCALE, os snapshots são gerenciados na seção Storage > Snapshots, com criação manual ou por tarefas agendadas. A restauração de arquivos individuais pode ser feita navegando pelo diretório oculto .zfs/snapshot dentro de cada dataset, acessível via SMB ou NFS se a opção estiver habilitada. Cada snapshot aparece como uma subpasta com o nome definido na criação, e os arquivos podem ser copiados diretamente.
Para recuperação de um dataset inteiro, o TrueNAS oferece a clonagem: um clone é um dataset gravável criado a partir de um snapshot, sem consumir espaço adicional imediato. O clone pode ser compartilhado na rede e os dados copiados de volta ao dataset original. Essa abordagem é particularmente útil quando a restauração direta representaria risco de sobrescrever dados atuais — o clone preserva tudo enquanto a cópia seletiva é feita.
Recuperação por linha de comando quando a interface falha
Quando a interface gráfica não responde, não carrega a lista de snapshots ou retorna erro ao tentar restaurar, a linha de comando via SSH é o próximo recurso. O acesso por SSH exige habilitação prévia no painel do NAS e conhecimento dos comandos específicos do sistema de arquivos. Um erro de sintaxe em ZFS ou Btrfs pode agravar a corrupção — por isso, a regra de ouro é operar sempre em modo somente leitura e registrar cada comando executado.
A documentação dos comandos é essencial também para o caso de acionar suporte especializado depois. Um técnico de recuperação consegue avaliar melhor o cenário quando sabe exatamente o que foi tentado, em que ordem e com que resultado. Comandos destrutivos executados sem registro transformam um caso recuperável em perda definitiva.
ZFS: listar, montar e clonar snapshots corrompidos
No ZFS, o comando zfs list -t snapshot lista todos os snapshots existentes no pool, com nome, espaço usado e dataset de origem. Para montar um snapshot somente leitura, usa-se zfs mount após definir a propriedade mountpoint. Se o snapshot estiver corrompido, o erro aparecerá na tentativa de leitura — geralmente como checksum error ou I/O error — e o comando zpool status -v indicará quais arquivos ou blocos estão afetados.
A clonagem com zfs clone cria um dataset gravável a partir do snapshot e pode ser a única forma de acessar dados quando a montagem direta falha parcialmente. Em pools com discos defeituosos, porém, a clonagem não resolve a causa: ela apenas replica a referência aos mesmos blocos problemáticos. Nesse ponto, a leitura direta dos discos em ambiente controlado é o caminho — erros de leitura em RAID exigem cautela antes de qualquer tentativa de recuperação.
Btrfs: subvolumes somente leitura e send/receive
Em Btrfs, snapshots são subvolumes criados com btrfs subvolume snapshot -r, onde a flag -r define somente leitura. Para listar os snapshots, usa-se btrfs subvolume list no ponto de montagem do volume. A montagem de um snapshot específico é feita com a opção subvol= no comando mount, apontando para o caminho do subvolume dentro do filesystem Btrfs.
O par send/receive do Btrfs permite transferir um snapshot para outro volume ou equipamento sem montá-lo diretamente. O comando btrfs send serializa o snapshot e o btrfs receive o reconstrói no destino. Essa técnica é útil quando o snapshot não pode ser montado no próprio NAS, mas ainda pode ser lido o suficiente para a transferência. Se o send falhar com erro de checksum, a corrupção está nos dados do snapshot — e a recuperação passa a depender de leitura de baixo nível dos discos.
Montagem de snapshot em Windows, macOS e Linux via SMB/NFS
Snapshots de NAS podem ser acessados de estações de trabalho sem depender da interface do fabricante. Em Synology e QNAP, os snapshots ficam expostos via SMB em um diretório oculto ou em pasta específica, dependendo da configuração. No Windows, o acesso é feito pelo Explorer digitando o caminho UNC da pasta de snapshots; no macOS, pelo Finder com o protocolo SMB; no Linux, pela montagem com mount -t cifs ou mount -t nfs.
O TrueNAS expõe os snapshots via .zfs/snapshot quando a propriedade snapdir está habilitada no dataset. Essa abordagem permite copiar arquivos de um snapshot diretamente para a máquina local, sem passar pela interface web do NAS — útil quando o painel está lento, inacessível ou com falha de renderização. A montagem externa também reduz o risco: a cópia é feita sem gravar nada no volume do NAS, apenas leitura.
Snapshot apagado ou retenção expirada: o que ainda dá para recuperar
Quando o snapshot foi apagado manualmente ou removido pela política de retenção automática, a referência a ele desaparece da listagem — mas os blocos de dados que ele apontava podem continuar no disco até serem sobrescritos. Em ZFS e Btrfs, a remoção de um snapshot libera espaço imediatamente no mapa de alocação, e o sistema passa a reutilizar esses blocos para novas gravações. O tempo entre o apagamento e a primeira gravação no volume é a janela de oportunidade.
Quanto antes o volume for congelado, maior a chance de os blocos ainda estarem intactos. A recuperação nesse cenário não é feita pela interface do NAS — não há mais snapshot para listar. É uma operação de leitura de baixo nível no volume subjacente, buscando blocos órfãos que correspondam aos dados antigos. Esse tipo de trabalho exige ferramentas especializadas e, em muitos casos, acesso direto aos discos fora do NAS.
Recuperação de blocos e setores no volume subjacente
A leitura de baixo nível parte do princípio de que o sistema de arquivos mantém estruturas que podem ser reconstruídas mesmo sem a referência do snapshot. Em ZFS, o uberblock e os block pointers permitem localizar dados antigos se os metadados não foram sobrescritos. Em Btrfs, a árvore de extents pode conter resquícios de blocos que pertenciam a snapshots removidos. A varredura por assinaturas de arquivos — cabeçalhos de JPEG, PDF, DOCX, bancos de dados — é o método complementar quando os metadados já se foram.
Esse processo não deve ser executado no NAS em operação, porque o próprio sistema operacional continua gravando logs e metadados no volume. O correto é retirar os discos, conectá-los a uma estação de trabalho com bloqueio de escrita por hardware e trabalhar sobre imagens setor a setor. A imagem preserva o estado original e permite múltiplas tentativas de reconstrução sem risco adicional. Para arranjos RAID, a leitura direta exige antes a remontagem lógica do arranjo — decisão que envolve avaliar recuperar versus reconstruir.
Reconstrução de RAID degradado antes de tentar ler o snapshot
Em NAS com múltiplos discos, a leitura do volume subjacente só é possível se o RAID estiver montável. Um arranjo degradado — com um ou mais discos ausentes, com falha ou fora de sincronia — precisa ser reconstruído logicamente antes de qualquer tentativa de acessar snapshots apagados. A reconstrução lógica não é o mesmo que rebuild do controlador: ela usa os discos originais, na ordem correta, para remontar o arranjo em software e extrair uma imagem do volume.
- Identificar a ordem física dos discos e os números de série antes de desconectar
- Registrar o tipo de RAID, tamanho de stripe e política de paridade
- Não executar rebuild ou inicialização no controlador do NAS — isso sobrescreve dados
- Trabalhar sempre sobre imagens dos discos, nunca sobre os discos originais
- Validar a consistência do arranjo remontado antes de tentar ler o filesystem
Erros nessa etapa são a causa mais comum de perda definitiva em NAS corporativos. A ordem errada dos discos em um RAID 5, por exemplo, produz uma imagem com paridade inconsistente e arquivos corrompidos — e cada tentativa mal sucedida pode consumir a janela de oportunidade. RAID com dois discos em falha ainda pode ser recuperável, mas exige precisão cirúrgica na remontagem lógica.
Quando o snapshot não basta: montagem de imagem, VM de resgate e suporte do fabricante
Há cenários em que nenhum snapshot — íntegro, inconsistente ou apagado — resolve sozinho. Quando o volume inteiro está corrompido, quando o NAS não inicializa ou quando o firmware entrou em loop, a saída passa por montar uma imagem do volume em ambiente isolado. A imagem setor a setor, gerada a partir dos discos originais, é carregada em uma máquina virtual ou estação de trabalho com o mesmo sistema de arquivos do NAS, permitindo tentativas de reparo sem tocar no hardware original.
A VM de resgate é especialmente útil para NAS com sistema proprietário: o ambiente virtual replica o firmware e o filesystem, permitindo executar ferramentas de verificação e reparo em modo controlado. O suporte do fabricante pode ajudar em casos de bug conhecido de firmware ou de incompatibilidade após atualização, mas tem limitação clara: o suporte oficial raramente atua em recuperação de dados quando o volume está corrompido ou o RAID degradado. A orientação padrão costuma ser reinicializar, restaurar de backup ou recriar o volume — todas destrutivas para os dados.
A decisão entre continuar tentando internamente e acionar recuperação especializada deve considerar três fatores: se já houve gravação no volume após a falha, se o RAID está degradado ou com discos fora de sincronia, e se o valor dos dados justifica o risco de manipulação adicional. Quando qualquer um desses fatores aponta para alto risco, a conduta mais segura é congelar tudo e buscar diagnóstico técnico antes de qualquer nova tentativa. As primeiras horas após uma falha de RAID definem o desfecho do caso.
Como evitar o próximo susto: política de snapshots que realmente protege
Um snapshot só protege contra perda de dados se existir no momento em que for necessário — e se estiver íntegro o suficiente para ser lido. A política de snapshots precisa equilibrar frequência, retenção e espaço disponível, mas principalmente precisa ser testada. Um snapshot que nunca foi restaurado é uma promessa não verificada; a primeira tentativa de restauração em situação de emergência é o pior momento para descobrir que ele não funciona.
A política mínima recomendada para NAS em produção combina snapshots frequentes para recuperação rápida, replicação para outro equipamento para sobreviver a falha de hardware, e cópia imutável para resistir a ransomware. Nenhuma dessas camadas sozinha é suficiente — e todas juntas ainda dependem de teste periódico para terem valor real.
Retenção, replicação para outro NAS e cópia imutável
A retenção define quantos snapshots são mantidos e por quanto tempo. Uma política comum em ambientes corporativos mantém snapshots horários por 24 horas, diários por 30 dias e semanais por 90 dias — mas o número exato depende do volume de alterações e do espaço disponível. O erro mais frequente é configurar retenção longa demais sem monitorar o consumo de espaço, levando o volume a encher e o sistema a apagar snapshots antigos automaticamente em cascata.
A replicação para outro NAS — preferencialmente em local físico diferente — cobre a falha do equipamento inteiro, incluindo controladora, fonte ou múltiplos discos. A cópia imutável, por sua vez, impede que ransomware ou erro humano apague os dados replicados: uma vez gravada, a cópia não pode ser alterada ou removida por um período definido. Em NAS Synology, o recurso de imutabilidade está disponível em modelos específicos com o Hyper Backup; em QNAP, via integração com repositórios imutáveis. A combinação das três camadas reduz drasticamente a chance de precisar de recuperação de emergência.
Teste de restauração periódico e verificação de integridade
O teste de restauração consiste em, em intervalo regular — mensal ou trimestral —, restaurar um arquivo ou pasta de um snapshot aleatório e validar que o conteúdo abre corretamente. O teste não precisa ser complexo: escolher um snapshot de 15 dias atrás, restaurar três arquivos de tipos diferentes e verificar a integridade. O objetivo é confirmar que o mecanismo inteiro funciona: criação, retenção, leitura e cópia de volta.
A verificação de integridade complementa o teste. Em ZFS, o scrub percorre todos os blocos e corrige erros de checksum quando há redundância; em Btrfs, o scrub cumpre papel semelhante. A execução periódica do scrub — semanal ou quinzenal em NAS com muitos discos — detecta setores defeituosos e corrupção silenciosa antes que afetem os snapshots. Um scrub que nunca é executado permite que a corrupção se acumule até o ponto em que múltiplos snapshots ficam ilegíveis simultaneamente, exatamente quando seriam mais necessários.
