DSM, SHR-1, SHR-2, Btrfs, ext4, snapshots, SSD cache e iSCSI podem existir em várias camadas sobre os mesmos discos. Se o Repair já falhou, mais de um drive está instável ou o volume entrou em Crashed, preserve o conjunto antes de iniciar novas escritas.
O que é recuperação de NAS Synology?
O melhor caminho depende do estado real. Se apenas um drive falhou, os demais estão saudáveis, o volume continua acessível e existe backup validado, o Repair oficial do DSM pode ser a manutenção correta. Se vários membros estão instáveis, o Repair já travou, o volume está Crashed ou não existe backup, o objetivo muda: preservar e adquirir antes de novas escritas.
Guia completo de recuperação de NAS Synology
Quando um Synology precisa de recuperação de dados?
Storage Pool Degraded
Um membro deixou o conjunto ou não está saudável. O pool perdeu redundância, mas pode continuar montado.
Volume Crashed
DSM identifica uma condição grave no volume. A documentação Synology separa falhas de drive e filesystem e orienta preservar dados ainda acessíveis.
SHR não repara
Repair não inicia, para em uma porcentagem ou outro disco apresenta erros durante a reconstrução.
Btrfs com checksum mismatch
Checksums identificam inconsistências. Se a redundância não consegue fornecer uma cópia válida, arquivos ou metadados podem ficar inacessíveis.
DSM não inicializa
Boot incompleto, luz azul piscando ou NAS ausente na rede podem envolver hardware, memória, sistema ou discos.
Múltiplos discos em falha
SHR-1 ou RAID 5 podem perder a tolerância quando um segundo membro fica indisponível. SHR-2 e RAID 6 têm tolerância maior, mas não ilimitada.
Snapshot inacessível
Snapshot Replication pode ter versões úteis, mas elas dependem do pool Btrfs estar acessível ou reconstruível.
Ransomware
Arquivos podem ser criptografados com o RAID saudável. Snapshots, backups e evidências do ataque precisam ser preservados.
iSCSI ou VM offline
O storage pode montar parcialmente, mas LUNs, Virtual Machine Manager ou discos virtuais ficam inacessíveis.
SHR e SHR-2: por que não devem ser tratados como um único RAID simples
A Synology define SHR como seu sistema automatizado de gerenciamento RAID. A documentação oficial atual informa que SHR é baseado em gerenciamento RAID Linux e que um SHR pode ser composto por vários arrays RAID integrados em um único storage pool. Essa flexibilidade permite aproveitar discos de capacidades diferentes com mais eficiência que muitos layouts clássicos.
SHR-1
É a opção SHR com proteção equivalente a uma falha de drive em configurações compatíveis. Quando os discos possuem tamanhos diferentes, o DSM pode criar mais de um conjunto interno para aproveitar a capacidade disponível.
SHR-2
Adiciona tolerância equivalente a duas falhas em configurações compatíveis. A reconstrução pode envolver sub-arrays de dupla paridade e uma camada de agregação até o storage pool.
Por que isso importa em recuperação?
Se um SHR de capacidades mistas contém vários arrays internos, simplesmente aplicar parâmetros de um RAID 5 único pode produzir offsets e fluxos de blocos incorretos. A reconstrução precisa identificar os conjuntos que realmente compõem o pool e depois remontar a camada lógica superior.
Discos, SHR/RAID, storage pool, volume e Btrfs ou ext4
DSM apresenta uma interface única, mas o caminho até uma pasta compartilhada passa por várias estruturas.
Discos físicos
HDDs ou SSDs podem apresentar bad sectors, falha mecânica, firmware, eletrônica, NAND ou problemas de link.
SHR ou RAID
Basic, SHR-1, SHR-2, JBOD, RAID 0, 1, 5, 6, 10 e RAID F1 aparecem nas especificações DSM, conforme modelo e tipo de drive.
Storage Pool
O pool agrega a capacidade dos arrays e serve de base para volumes, cache, expansão e outras funções do Storage Manager.
Volume
DSM pode criar volumes Btrfs ou ext4, dependendo do modelo e da configuração.
Snapshots
Snapshot Replication protege shared folders Btrfs e LUNs em modelos e configurações compatíveis.
Aplicações
iSCSI, VMM, Active Backup, bancos de dados e pacotes podem adicionar outras camadas sobre o volume.
10 passos quando o Synology mostra Volume Degradado ou SHR Corrompido
O que não fazer em Synology com SHR degradado ou Volume Crashed
Repair repetitivo
Repair é uma função oficial válida em storage dentro das condições previstas. Se ele já falhou por leitura ou outro disco instável, repetir sem diagnóstico pode aumentar a carga.
Data Scrubbing para tentar recuperar dados
Scrubbing é manutenção de integridade. Em discos fisicamente instáveis, uma leitura extensa pode consumir a janela de aquisição antes da clonagem.
Atualizar DSM durante o incidente
Atualizações são importantes para segurança, mas não devem ser usadas como tentativa genérica para reparar um volume já inacessível.
Criar novo volume ou pool
Novas estruturas escrevem metadados e não restauram o estado anterior.
Formatar porque o PC não reconhece
Um membro isolado não representa necessariamente o volume final SHR, RAID, LVM ou Btrfs.
Forçar filesystem repair sem cópia
Repair busca consistência do estado atual. Em recuperação, preserve antes de modificar árvores, journal ou metadados.
Como funciona a recuperação profissional de NAS Synology
A recuperação é conduzida por camadas. Primeiro preserva-se a mídia física. Depois são reconstruídos os arrays e o storage pool. Só então Btrfs, ext4, snapshots, LUNs ou VMs são analisados.
Tecnologias conforme o tipo de mídia
PC-3000 pode auxiliar no diagnóstico e acesso técnico a HDDs e SSDs suportados. DeepSpar pode ser utilizado em imaging de HDDs instáveis. Data Extractor auxilia aquisição e análise lógica em cenários compatíveis. A reconstrução RAID Low Level é feita sobre a melhor aquisição possível dos membros.
Btrfs em Synology: checksums, metadata mirroring e self-healing
A Synology documenta Btrfs como um filesystem com checksums para dados e metadados, duas cópias de metadados e recursos de self-healing quando existe redundância compatível e a opção de checksum está habilitada. Isso é importante para integridade, mas não elimina cenários de recuperação.
Checksums
Checksums permitem detectar quando o conteúdo lido não corresponde ao valor esperado. Detectar corrupção não é a mesma coisa que possuir uma cópia saudável para substituí-la.
Metadata mirroring
Manter múltiplas cópias aumenta a disponibilidade das estruturas que descrevem pastas, nomes, permissões e localização de arquivos. Em um volume comprometido, essas cópias podem divergir ou estar em regiões com erros físicos.
Self-healing
Em configurações suportadas, o Btrfs pode usar redundância RAID para recuperar dados corrompidos. As especificações DSM atuais limitam essa recuperação a determinados níveis e exigem que a opção de data checksum esteja habilitada na shared folder.
Quando o filesystem não consegue reparar
A própria Synology documenta que, quando Btrfs não consegue restaurar dados após checksum mismatch, o arquivo pode ficar inacessível. Em recuperação, o trabalho passa a buscar árvores e cópias utilizáveis sobre uma imagem do storage, em vez de depender do volume montado pelo DSM.
Synology EXT4 ainda exige reconstruir o RAID antes do filesystem
DSM continua suportando ext4 em modelos e configurações compatíveis. O filesystem possui superblocos, journal, inodes, extent trees e diretórios. Em um volume sobre RAID 5, RAID 6 ou SHR, essas estruturas só aparecem corretamente depois que a camada inferior fornece a sequência lógica de blocos correta.
Superblocos e cópias
EXT4 mantém estruturas redundantes conforme a geometria do filesystem. Superblocos alternativos podem ajudar quando partes da região principal estão ilegíveis.
Journal
O journal reduz inconsistências após desligamentos inesperados, mas executar fsck diretamente no volume original modifica metadados. Em dados críticos, a análise deve ser feita em uma cópia.
SHR + ext4
SHR e filesystem são camadas diferentes. Mesmo um ext4 íntegro não pode ser lido se os arrays internos que compõem o pool estiverem remontados com parâmetros incorretos.
Quando Repair é correto e quando a prioridade muda para recuperação
A documentação DSM orienta Repair para storage pools em estado Degraded quando um drive defeituoso deve ser substituído por um drive saudável compatível. A mesma plataforma oferece Data Scrubbing para manter integridade em Btrfs e determinados níveis RAID. Essas funções fazem parte da manutenção normal.
| Cenário | Conduta mais coerente | Motivo |
|---|---|---|
| Um drive falhou, volume acessível, backup validado, demais drives saudáveis | Seguir Repair oficial Synology | Storage ainda está dentro da tolerância prevista |
| Pool Degraded e segundo drive com bad sectors ou reconnects | Preservar e adquirir antes do Repair | Repair exige leitura extensa dos membros restantes |
| Drive foi removido acidentalmente e está saudável | Avaliar procedimento oficial de reinserção e Repair | Synology documenta essa situação especificamente |
| Repair travou ou falhou | Não repetir sem diagnosticar os membros | A causa pode ser outra mídia instável |
| Volume Crashed mas dados ainda acessíveis | Copiar dados imediatamente | A documentação Synology prioriza backup antes de remover estruturas |
| Data Scrubbing programado em storage saudável | Manutenção normal | Verifica integridade em níveis e filesystems suportados |
| Disco com falha física severa e dados sem backup | Não iniciar scrubbing completo | A prioridade é adquirir o máximo possível da mídia |
Essa distinção é importante para SEO e para o cliente: nem "clique sempre em Repair" nem "Repair sempre destrói dados" são regras corretas. O estado dos outros discos e a existência de backup definem a decisão.
Snapshots podem ser o caminho mais rápido para arquivos apagados ou alterados
A versão atual do Snapshot Replication suporta snapshots de shared folders em volumes Btrfs e LUNs, com navegação, cópia e recuperação. A Synology também documenta snapshots imutáveis em modelos compatíveis.
Synology com SSD cache ou storage pool em SSD
As especificações DSM atuais suportam SSD cache group, cache read-only e read-write e, em modelos específicos, M.2 SSDs como storage pool. Isso adiciona novas decisões em recuperação.
Read-only cache
Serve para acelerar leitura. A cópia de autoridade permanece no storage principal, embora a configuração de cache deva ser preservada para entender o ambiente.
Read-write cache
Pode participar de um caminho de escrita e também pode manter metadados Btrfs fixados no cache em condições suportadas. Remover ou recriar cache sem registrar o estado original não é prudente em incidente de perda de dados.
SSD-only storage pool
Quando o próprio pool é formado por SSDs, entram em cena firmware, controladora, NAND, FTL, TRIM e desgaste. A recuperação passa a combinar análise de SSD individual e reconstrução SHR/RAID.
Synology corporativo pode ter várias camadas acima do Btrfs
iSCSI LUN
O LUN pode conter NTFS, ReFS, VMFS ou outro filesystem usado por servidores externos.
Virtual Machine Manager
VMs e discos virtuais podem depender do volume Btrfs, snapshots e configuração do VMM.
Banco de dados
MDF/LDF, PostgreSQL, MySQL, Oracle e outras bases precisam ser validadas estruturalmente após a extração.
Recuperar uma pasta no NAS não significa automaticamente recuperar uma aplicação. Em ambientes empresariais, o escopo deve chegar ao objeto final que o cliente precisa abrir e utilizar.
Synology afetado por ransomware: snapshots, backup e preservação
Quando ransomware criptografa arquivos compartilhados, SHR e Btrfs podem continuar tecnicamente saudáveis. O problema está na camada de dados e segurança. Por isso, a estratégia precisa combinar contenção, preservação e restauração.
Não é seguro afirmar que todo ransomware deixa blocos originais recuperáveis ou que determinada família pode ser revertida apenas por carving. A recuperabilidade depende do comportamento da variante, do filesystem, snapshots e do que ocorreu após a criptografia.
Cenários técnicos de recuperação de NAS Synology
SHR-1 Degraded: segundo disco apresenta bad sectors durante Repair
Contexto: um drive falha e o DSM inicia Repair com um substituto. Durante a leitura dos membros restantes, outro HDD começa a apresentar erros.
Ação de risco: repetir Repair, trocar mais discos sem mapear bays ou executar Data Scrubbing.
Estratégia: interromper novas escritas, adquirir os membros instáveis e reconstruir os sub-arrays SHR e o storage pool sobre imagens.
Aprendizado: Repair é correto quando os demais membros estão saudáveis. O surgimento de uma segunda falha transforma a situação em recuperação.
SHR-2 com discos de capacidades diferentes e pool inacessível
Contexto: um storage pool mistura capacidades e, após falhas e substituições anteriores, DSM não consegue montar o volume.
Ação de risco: tratar todo o conjunto como um único RAID 6 linear ou criar um novo pool.
Estratégia: identificar os arrays internos que compõem o SHR, reconstruir cada segmento e integrar a estrutura do storage pool antes do filesystem.
Btrfs com checksum mismatch e snapshots disponíveis
Contexto: o volume monta parcialmente, mas certos arquivos apresentam checksum mismatch e existem snapshots anteriores.
Ação de risco: apagar snapshots para liberar espaço ou insistir em reparos antes de copiar os dados íntegros.
Estratégia: preservar o volume, validar snapshots, copiar versões legíveis para outro destino e analisar as regiões corrompidas sobre uma imagem.
Synology com iSCSI LUN e VMs inacessíveis após queda de energia
Contexto: DSM volta a iniciar, mas o LUN usado por um host de virtualização não fica disponível.
Ação de risco: recriar o LUN com o mesmo nome ou formatar o datastore no host.
Estratégia: reconstruir RAID/pool, localizar o objeto iSCSI, extrair a imagem e depois validar VMFS, VMDK ou outro filesystem do host.
Arquivos criptografados com snapshots imutáveis anteriores
Contexto: ransomware atinge compartilhamentos, mas o NAS possui snapshots protegidos anteriores ao incidente.
Ação de risco: resetar o storage ou apagar dados cifrados antes de verificar recovery points.
Estratégia: isolar, preservar evidências, verificar snapshots e restaurar conteúdo para um ambiente limpo, tratando a causa do incidente antes de retornar à produção.
Perguntas frequentes sobre recuperação de NAS Synology
NAS Synology com Storage Pool Degraded tem recuperação?
Pode ter. Degraded significa que o pool perdeu parte da redundância ou um membro esperado não está participando normalmente. Se o volume ainda está acessível, a prioridade é validar backup dos dados críticos e avaliar os demais discos. Quando há mais membros instáveis, erros de leitura ou Repair anterior com falha, preserve o conjunto antes de nova reconstrução.
SHR corrompido pode ser reconstruído fora do Synology?
Em muitos cenários, sim. O SHR é baseado em gerenciamento RAID Linux e pode ser composto por múltiplos arrays que são integrados em um único storage pool. Quando os discos podem ser adquiridos, esses conjuntos podem ser analisados e reconstruídos virtualmente, seguida da camada de volume e Btrfs ou ext4.
Qual a diferença entre SHR-1 e SHR-2?
SHR-1 oferece proteção equivalente a uma falha de drive no contexto compatível, enquanto SHR-2 oferece tolerância a duas falhas. A estrutura exata pode variar com capacidades e configuração. A recuperação precisa identificar os sub-arrays e a topologia real, não apenas assumir um RAID 5 ou RAID 6 convencional.
Devo clicar em Repair no DSM quando o storage pool está Degraded?
Quando apenas um drive falhou, os demais estão saudáveis e existe backup validado, Repair é um procedimento oficial da Synology para restaurar a redundância. Porém, em um incidente sem backup, com múltiplos discos instáveis, erros de leitura ou Repair anterior interrompido, primeiro vale preservar e avaliar os membros.
Volume Crashed no DSM significa que os arquivos foram apagados?
Não necessariamente. Crashed é um estado de volume ou storage que pode decorrer de erros de drive, filesystem, memória ou outras condições. A documentação Synology orienta copiar os dados ainda acessíveis antes de remover estruturas. Em recuperação, não recrie o volume se os dados antigos ainda são necessários.
Btrfs corrompido em Synology tem recuperação?
Pode haver recuperação, mas depende do estado do RAID, metadados, árvores Btrfs, checksums, snapshots e regiões legíveis. Btrfs possui metadados redundantes, checksums e recursos de self-healing em configurações compatíveis, mas esses recursos não substituem recuperação quando a mídia física ou o pool está comprometido.
Data Scrubbing deve ser executado para recuperar um volume corrompido?
Data Scrubbing é uma função oficial de manutenção de integridade, combinando file system scrubbing em Btrfs e RAID scrubbing em níveis compatíveis. Em storage saudável ele é útil. Em perda de dados com discos fisicamente instáveis, múltiplas falhas ou volume já Crashed, não deve ser usado como substituto da aquisição e preservação.
Snapshots Synology podem recuperar arquivos apagados?
Se Snapshot Replication estava configurado e existe um snapshot anterior, arquivos e pastas podem ser navegados, copiados ou recuperados. Isso é especialmente útil em exclusão acidental. Snapshots locais, porém, continuam dependentes do storage pool e não substituem uma cópia independente.
Btrfs e ext4 são usados em Synology?
Sim. As especificações atuais do DSM suportam Btrfs e ext4, dependendo do modelo e da configuração. Btrfs oferece recursos adicionais como snapshots, checksums e self-healing em condições suportadas. A recuperação precisa identificar qual filesystem existia no volume.
Synology com luz azul piscando significa falha de disco?
Não é um diagnóstico conclusivo. Problemas de boot, hardware, memória, alimentação ou discos podem impedir a inicialização. A análise deve separar falha do gabinete e do sistema DSM de falha do storage, especialmente quando os dados estão íntegros nos discos.
SSD Cache pode afetar a recuperação do Synology?
Pode. DSM suporta cache SSD read-only e read-write em modelos compatíveis, e metadados Btrfs podem ser fixados em cache read-write. Antes de remover SSDs, resetar cache ou migrar o pool, registre a configuração original.
É seguro mover os discos para outro Synology?
A Synology possui mecanismos oficiais de montagem e migração em determinados cenários e modelos compatíveis. Se o problema é apenas o gabinete e os discos estão saudáveis, isso pode ser uma rota legítima. Em perda de dados com múltiplos discos instáveis ou pool já inconsistente, a prioridade deve ser preservar os membros antes de iniciar um novo DSM sobre o conjunto.
Ransomware em Synology pode ser recuperado por snapshots?
Pode, se existirem snapshots válidos anteriores ao ataque e o storage pool estiver acessível. Também podem existir backups independentes. Sem snapshot, backup ou outra cópia íntegra, a viabilidade depende da variante e do estado dos arquivos. Não existe garantia universal de descriptografia.
Synology com iSCSI LUN ou Virtual Machine Manager exige recuperação diferente?
Sim. O NAS pode conter LUNs, máquinas virtuais e discos virtuais dentro do Btrfs ou storage pool. Depois de reconstruir o RAID e o volume, pode ser necessário extrair e validar iSCSI, VMM, VMDK, VHDX, bancos de dados ou outras estruturas.
A SECURITY atende NAS Synology de todo o Brasil?
Sim. A SECURITY atende clientes de diferentes regiões do Brasil e orienta envio seguro do NAS ou dos discos quando necessário. Em Barueri, este artigo prioriza Alphaville, além dos pontos de atendimento em São Paulo e Campinas.
Atendimento para NAS Synology em São Paulo e todo o Brasil
A SECURITY atende clientes de diferentes regiões do Brasil e orienta o envio seguro do NAS ou dos discos 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, HDD, SSD, PC-3000, Data Extractor e análise RAID Low Level.
Synology por dentro: SHR, Linux RAID, storage pool, Btrfs, snapshots e reconstrução virtual
Esta seção aprofunda o que acontece entre os discos e a shared folder do usuário e ajuda a separar manutenção normal do DSM de recuperação de dados.
1. SHR é uma camada de gerenciamento sobre RAID Linux
A Synology descreve SHR como sistema automatizado de gerenciamento RAID. Documentação recente também explica que SHR pode ser composto por múltiplos arrays RAID integrados em um único storage pool. Assim, a estrutura final pode ser mais complexa que um único md array.
2. Discos de capacidades diferentes podem gerar vários sub-arrays
Quando os tamanhos variam, o SHR busca aproveitar melhor a capacidade disponível. Isso pode criar zonas em que subconjuntos diferentes participam de arrays com tamanhos distintos. Em recuperação, essas regiões precisam ser remontadas na ordem correta antes de formar o pool.
3. SHR-2 adiciona uma tolerância maior, não invulnerabilidade
SHR-2 foi criado para tolerar duas falhas em condições compatíveis. Se três membros estiverem indisponíveis ou se setores críticos faltarem em vários discos dentro das mesmas regiões, parte dos dados pode continuar irrecuperável apesar da dupla paridade.
4. Storage Pool é diferente de Volume
O pool agrega a capacidade fornecida pelo SHR ou RAID. O volume Btrfs ou ext4 é criado sobre esse pool. Um Storage Pool Degraded pode manter volume acessível; um Volume Crashed pode ocorrer mesmo com parte da estrutura RAID ainda presente. Diagnóstico precisa identificar qual camada falhou.
5. Btrfs usa árvores e copy-on-write
Btrfs organiza metadados em estruturas de árvore e usa copy-on-write para atualizações. Isso ajuda em snapshots e consistência, mas também significa que reconstrução exige localizar raízes válidas, extent mapping e referências coerentes entre diferentes gerações.
6. Metadata mirroring é útil, mas não garantia
A Synology informa que Btrfs mantém duas cópias de metadados no volume. Se uma região está danificada, a outra pode permitir recuperação. Se ambas estão em áreas afetadas ou o RAID não consegue fornecer blocos corretos, o filesystem pode permanecer incompleto.
7. Checksums detectam corrupção silenciosa
Com data checksum habilitado, Btrfs consegue detectar divergências entre conteúdo e checksum. Em RAIDs suportados, o sistema pode tentar obter uma cópia válida a partir da redundância. Quando não existe cópia válida, a detecção apenas informa que o dado não é confiável.
8. Data Scrubbing combina funções diferentes
As especificações DSM informam que Data Scrubbing pode executar file system scrubbing em Btrfs e RAID scrubbing em RAID 5, RAID 6 e RAID F1. É uma função de manutenção programável. Em recuperação física, a decisão de não rodá-la se baseia no risco de submeter discos instáveis a leitura extensa, não em uma ideia de que scrubbing seja destrutivo por definição.
9. Repair é uma reconstrução legítima de redundância
DSM oferece Repair para pools Degraded. Em um cenário normal, substitui-se o drive defeituoso e a redundância é reconstruída. Se o pool depende de discos que já apresentam erros, o mesmo processo pode expor essas mídias a leituras intensas. Por isso, backup e health dos membros devem vir antes da decisão.
10. Um drive removido acidentalmente é diferente de um drive fisicamente falho
A Synology publicou procedimento específico em 2026 para reinserir drive removido acidentalmente e executar Repair em DSM 7.2.1 e versões mais recentes. Isso demonstra por que não é correto tratar toda condição Degraded como falha física ou recomendar desligamento permanente em qualquer alerta.
11. Volume Crashed exige preservar o que ainda é acessível
Artigos atuais da Synology distinguem volume crash por erros de drive ou filesystem. Quando o volume ainda permite acesso parcial, copiar dados para outro destino antes de remover estruturas é uma prioridade. Em caso sem acesso, a análise de baixo nível passa a ser necessária.
12. Snapshot Replication protege shared folders Btrfs e LUNs
A versão 7.4 do Snapshot Replication suporta criação, browse, copy e recovery de snapshots, inclusive snapshots imutáveis em modelos compatíveis. Em exclusão lógica, essa pode ser a melhor recuperação. Se o pool não monta, os snapshots também dependem de reconstrução do Btrfs.
13. SSD cache pode manter metadados Btrfs
As especificações DSM atuais informam que metadados de volumes Btrfs podem ser pinned em read-write cache. Assim, em ambientes com cache SSD, a configuração não deve ser tratada como irrelevante sem verificar o modelo e modo de cache.
14. SSD-only pools adicionam FTL e TRIM
Em modelos compatíveis, DSM permite SSD storage pools e SSD TRIM. Se a perda envolve SSD formatado, excluído ou com firmware instável, além da reconstrução SHR existe a camada interna de controladora, NAND e FTL de cada SSD.
15. iSCSI LUN e VMM podem conter um segundo universo lógico
Um LUN pode apresentar um filesystem externo ao NAS. VMM pode armazenar máquinas virtuais com seus próprios discos. Recuperar o Btrfs é apenas uma etapa. O objeto final precisa ser validado em sua própria estrutura.
16. RAID Low Level sobre imagens
Quando os metadados não bastam, a reconstrução pode usar coerência de filesystem, padrões de dados e paridade para confirmar ordem, offsets e segmentos. Trabalhar sobre imagens permite repetir testes sem alterar os discos originais.
17. Lacunas em discos instáveis
Se clones contêm setores ilegíveis, a redundância pode reconstruir algumas regiões. Em SHR com múltiplos sub-arrays, a capacidade de recompor uma lacuna depende de quais discos participam daquela região específica e de quantos membros estão ausentes naquele sub-array.
18. Matriz técnica de decisão
| Sintoma | Camada a investigar | Prioridade | Evitar |
|---|---|---|---|
| Pool Degraded, volume acessível | Drive + SHR/RAID | Backup e health dos demais drives | Repair antes de validar backup |
| SHR Repair travado | Segundo drive instável / sub-arrays | Diagnóstico e clonagem | Repetir Repair |
| Volume Crashed | Drive, pool, filesystem | Copiar dados acessíveis ou preservar membros | Criar novo volume |
| Btrfs checksum mismatch | Checksum, redundância e Btrfs trees | Preservar versões e snapshots | Apagar snapshots por impulso |
| ext4 não monta | SHR/RAID + ext4 | Reconstruir fluxo lógico primeiro | fsck no membro isolado |
| Drive removido acidentalmente | Membership do pool | Avaliar procedimento oficial | Assumir falha física |
| SSD cache crashed | Cache + pool | Registrar modo e members | Recriar cache sem contexto |
| Ransomware | Dados, snapshots e segurança | Isolar e validar recovery points | Apagar evidências |
19. Conclusão técnica
Recuperação Synology precisa evitar dois extremos: tratar todo alerta Degraded como desastre forense e, no outro extremo, executar Repair e scrubbing automaticamente em qualquer situação. O estado dos membros, backup disponível, número de falhas, filesystem e histórico de intervenções definem o caminho. Quando o conjunto sai das condições normais de manutenção, preservar e reconstruir sobre cópias é a abordagem mais conservadora.
Referências utilizadas neste guia
A página da E-Recovery foi usada apenas como benchmark editorial, de Hero, intenção de busca e cobertura semântica. O conteúdo técnico da SECURITY foi redigido de forma original e confrontado com documentação oficial Synology atual.
- Synology Knowledge Center: What is Synology Hybrid RAID (SHR)?
- Synology Knowledge Center 2026: estrutura SHR e múltiplos arrays
- Synology DSM 7.4 Technical Specifications
- Synology: Btrfs, checksums, metadata mirroring e self-healing
- Synology DSM: Repair a Storage Pool
- Synology 2026: Repair após drive removido acidentalmente
- Synology DSM: Data Scrubbing
- Synology Snapshot Replication 7.4 Technical Specifications
- Synology 2026: recuperação de arquivos por snapshots
- Synology 2026: What can I do if one of my volumes crashed?
