Um NAS doméstico parece “configurar e esquecer” até ao momento em que um disco sai do array, o volume aparece como degradado ou alguém apaga a pasta errada num compartilhamento. A forma mais comum de transformar uma situação recuperável num desastre é fazer algo irreversível cedo demais: reconstruir no disco errado, reinicializar um pool, executar uma reparação enquanto o sistema ainda está a escrever ou trocar a ordem dos discos sem registos. Este guia é um fluxo de trabalho prático e cauteloso que pode seguir em Synology, QNAP e TrueNAS em 2026: travar o dano, registar evidências, criar cópias seguras e só depois decidir se deve reconstruir, reverter um snapshot ou fazer recuperação de ficheiros.
Primeira regra: reduza novas escritas no NAS ao mínimo. Novas escritas podem sobrescrever ficheiros apagados (sobretudo em partilhas thin-provisioned) e também podem empurrar um RAID frágil para o colapso. Pause tarefas agendadas de backup, clientes de sincronização, indexação multimédia, ferramentas de download e contentores de máquinas virtuais. Se o NAS estiver online e responsivo, mude para um modo “quase só leitura”: desligue alvos iSCSI, desmonte partilhas nos PCs e desative serviços que geram atividade constante (miniaturas, torrents, logging pesado). Se houver suspeita de ransomware ou malware, isole o NAS da rede imediatamente e não “limpe” nada ainda — a evidência conta.
Segunda regra: documente o que tem antes de mexer no hardware. Tire capturas de ecrã do estado no gestor de armazenamento, lista de discos, layout do RAID/pool e quaisquer avisos de “degradado”. Exporte logs do sistema se o equipamento permitir, porque estes logs mostram muitas vezes qual disco começou a dar timeouts primeiro e se houve erros de metadados. No caso da QNAP, o comportamento do firmware/OS pode variar entre versões do QTS/QuTS hero, por isso registar a versão e o build exatos ajuda quando comparar sintomas com notas de versão e problemas conhecidos.
Terceira regra: não inicie uma reconstrução ou “reparação” só porque o botão existe. A reconstrução escreve paridade e metadados em todo o array; se o problema for, na verdade, vários discos fracos, ordem de discos incorreta, corrupção silenciosa ou uma eliminação acidental que ainda pretende recuperar, uma reconstrução pode reduzir as opções. Trate a reconstrução como um passo tardio — depois de ter pelo menos uma cópia verificada de cada disco membro (ou um snapshot/replicação limpos do dataset). Esta abordagem “primeiro não destrutiva” é o que torna a recuperação doméstica realista em vez de um jogo de sorte.
Use os sintomas para classificar o incidente. A eliminação acidental costuma parecer “limpa”: o NAS está estável, os discos parecem saudáveis, mas uma pasta/partilha desapareceu e o espaço livre aumentou. Um RAID degradado normalmente mostra um disco como falhado/removido ou múltiplos erros de leitura nos logs; o desempenho pode piorar, e estatísticas SMART podem revelar aumento de setores realocados ou pendentes. Problemas do sistema de ficheiros surgem frequentemente como falhas ao montar, remontagens em modo apenas leitura, erros repetidos de “metadados” ou um pool que importa mas cujos datasets não montam.
Verifique o SMART de forma que reflita risco real. Um disco pode passar num teste curto e ainda assim não ser seguro para reconstrução. Preste atenção a: Reallocated Sector Count, Current Pending Sector, Offline Uncorrectable, erros UDMA CRC (cabo/backplane) e entradas de log sobre timeouts ou resets. Se vir novos valores de pending/offline-uncorrectable, priorize clonar esse disco primeiro, porque uma reconstrução é uma leitura sustentada do disco inteiro — exatamente o que mata um disco marginal.
Entenda o que “degradado” significa no seu cenário. Synology e muitos modelos QNAP usam frequentemente RAID mdadm do Linux por baixo, por vezes combinado com LVM, e o sistema de ficheiros pode ser ext4 ou Btrfs. O TrueNAS usa pools ZFS; um pool pode ficar degradado com um membro de vdev falhado e ainda servir dados, mas o resilver também é intensivo em escrita e pode expor erros de setores latentes em discos mais antigos. A orientação de versão e ciclo de vida do fabricante importa aqui: a escolha mais segura tende a ser manter o sistema estável, proteger os dados primeiro e só depois mexer em firmware ou definições de armazenamento de grande impacto.
Se o NAS usa snapshots e já os tem ativados, eles costumam ser o caminho mais seguro para cenários de “pasta apagada”. Em Synology e QNAP, as funções de snapshot dependem do tipo de armazenamento e da configuração; se existir um snapshot anterior à eliminação, restaurar ou clonar esse snapshot pode ser muito menos arriscado do que qualquer recuperação de baixo nível. O ponto-chave é restaurar para um local novo primeiro (uma partilha separada ou um dataset temporário) para validar o conteúdo antes de sobrescrever qualquer coisa.
Se não tem snapshots (ou se o pool estiver instável), avance para imagiamento de discos. O objetivo é simples: criar imagens sector-a-sector de cada disco membro (ou pelo menos dos discos suspeitos primeiro) e fazer todo o trabalho de recuperação sobre essas imagens. Imagens protegem contra o cenário “mais um reboot e morreu” e permitem tentar várias estratégias de reconstrução sem mais desgaste. Use um imager que lide com sectores defeituosos com tentativas controladas e produza um log claro do que foi legível.
Quando precisa de extrair ficheiros sem alterar nada, prefira montagem em modo só leitura. Em arrays baseados em mdadm, isso significa montar o RAID numa workstation de recuperação como read-only (muitas vezes a partir de imagens) e montar o volume lógico em read-only. No ZFS, significa importar o pool em read-only (ou importar a partir de cópias) e copiar dados para um destino separado. Na prática: o destino dos dados recuperados deve ser outro armazenamento — outro NAS, um disco externo com espaço suficiente, ou backup na nuvem — nunca “de volta para o mesmo pool degradado”.
Substituir um disco e deixar o NAS reconstruir automaticamente antes de ter cópias é o erro número um. Outro problema frequente é baralhar a ordem dos discos. Etiquete as baias, anote números de série e registe de que slot veio cada disco. “Depois lembro-me” quase sempre acaba em adivinhação — e a reconstrução de RAID detesta adivinhações.
Um erro mais subtil é aceitar prompts de “inicializar”, “criar novo volume” ou “formatar” quando a interface não consegue montar algo. Essas opções servem para provisionamento, não para recuperação. Se a interface sugerir recriar um pool, encare isso como sinal para parar e mudar para passos offline. Mesmo quando o sistema oferece “reparar sistema de ficheiros”, pode reescrever metadados de forma a dificultar a recuperação de ficheiros apagados.
Outro destruidor silencioso é continuar a usar o NAS “até ao fim de semana”. Tarefas em segundo plano (indexação, deduplicação, scrubs, limpeza de snapshots) podem reescrever blocos e eliminar metadados de que precisa. Se não conseguir recuperar de imediato, pelo menos congele o sistema: reduza escritas, desative tarefas não essenciais e planeie um desligar controlado depois de recolher logs e definir a melhor estratégia de clonagem.

Comece por capacidades nativas, porque são as menos arriscadas quando usadas corretamente. Para eliminação: verifique a configuração da lixeira do NAS (se ativada), pontos de restauração de snapshots e destinos de replicação. Para arrays degradados: confirme se o NAS marcou um disco como “removido” por causa de algo transitório (energia, backplane, cabo) versus falha real de mídia. Às vezes, voltar a encaixar o disco e reiniciar resolve — mas só faça isso depois de registar o estado atual, porque um reboot pode mudar quais discos são considerados “ativos”.
Se precisar de recuperação mais profunda, software especializado é o que muitos utilizadores domésticos e pequenas equipas de IT acabam por usar. Ferramentas desta categoria normalmente permitem: criar imagens de disco, detetar layouts RAID típicos de NAS, montar arrays virtualmente a partir de imagens e extrair ficheiros para um destino seguro. A funcionalidade mais importante é trabalhar sobre imagens, em vez de forçar discos frágeis com varreduras repetidas e tentativas de reconstrução.
Há também casos em que o DIY deve parar. Se vários discos fazem ruídos anormais, caem do array ou mostram erros de leitura, está numa zona de risco onde uma reconstrução doméstica pode “terminar o serviço” (no mau sentido). Se os dados são valiosos e há sinais de mais de um disco a falhar, pode ser mais barato pausar e recorrer a recuperação profissional do que “tentar algumas coisas” e perder as últimas leituras boas. A recuperação em casa funciona melhor quando mantém ações reversíveis e não empurra discos problemáticos para cargas pesadas.
Se uma pasta foi apagada e o NAS está saudável: procure snapshots primeiro; se existirem, restaure para um local novo e valide. Se não houver snapshots, pare escritas e prepare recuperação a partir de imagens — a recuperação de apagados piora a cada escrita.
Se o array está degradado mas estável e só um disco parece mau: recolha logs, verifique SMART e faça imagem do disco arriscado primeiro (ou de todos, se conseguir). Só depois de ter imagens deve considerar substituir o disco e reconstruir/resilver. Se o SMART estiver limpo e os logs sugerirem desconexão (CRC, queda súbita), investigue encaixe/cabos/backplane antes de comprometer uma reconstrução.
Se o NAS está instável, entra em ciclos de reboot, ou vários discos mostram erros: não continue a desligar e ligar. Priorize criar imagens com tentativas controladas (ou retire os discos e faça imagens numa workstation) e depois reconstrua em cópias. Nesse ponto, ferramentas de reconstrução RAID e extração em modo só leitura tendem a ser mais seguras do que a interface do NAS, porque controla cada escrita e consegue voltar às imagens se algo correr mal.