Por que é que um snapshot de um NAS doméstico pode preservar dados que já estão corrompidos?

Um snapshot de um NAS doméstico pode preservar dados corrompidos porque a sua função é reter um estado do sistema de ficheiros, não decidir se cada ficheiro nesse estado está saudável. Se uma base de dados, documento, foto ou ficheiro multimédia já estiver danificado quando o snapshot é criado, restaurar esse snapshot pode reproduzir a mesma versão danificada.

O momento da corrupção é importante. Um snapshot pode proteger uma versão anterior de uma sobrescrição posterior, mas não pode criar uma versão limpa que nunca foi capturada. A partilha de blocos copy-on-write cria também um segundo caso: danos físicos num bloco podem afetar mais do que uma vista do sistema de ficheiros que ainda referencia esse bloco.

Um Snapshot Preserva um Estado do Sistema de Ficheiros, Não uma Cópia Conhecida como Boa

Um snapshot do sistema de ficheiros regista um estado de armazenamento num determinado momento. No OpenZFS, por exemplo, um snapshot é uma versão só de leitura de um sistema de ficheiros ou volume, e inicialmente partilha dados com o conjunto de dados ativo em vez de duplicar cada ficheiro. A documentação do snapshot OpenZFS descreve como o snapshot retém dados que, de outra forma, permaneceriam partilhados até que o conjunto de dados ativo mudasse.

Essa operação não determina se o conteúdo armazenado é semanticamente correto. Um sistema de ficheiros pode preservar um ficheiro estruturalmente legível mesmo quando uma aplicação escreveu registos inválidos, uma ferramenta de sincronização copiou a versão errada ou um ransomware substituiu os bytes originais por conteúdo encriptado. O sucesso do snapshot significa, portanto, que um estado foi retido; não certifica que o estado era bom.

A Corrupção Presente no Momento do Snapshot Torna-se Parte do Ponto de Recuperação

Considere um snapshot agendado criado à meia-noite. Se uma aplicação corrompe uma base de dados às 22:00, o snapshot da meia-noite regista o estado do sistema de ficheiros após a corrupção. Reverter para esse snapshot devolve a base de dados ao estado da meia-noite, mas a meia-noite já é tarde demais para fornecer uma cópia saudável.

A mesma sequência pode ocorrer após uma sincronização defeituosa, uma importação incompleta, uma gravação acidental ou uma encriptação não autorizada. O snapshot não “incorpora” a corrupção como uma propriedade especial; simplesmente retém a versão que existia no momento da captura. Um snapshot mais antigo pode ainda conter uma versão utilizável, mas cada snapshot criado após o dano pode conter o mesmo erro lógico.

O Tempo da Corrupção Determina se um Snapshot Pode Ajudar

Um snapshot é mais útil quando a alteração lógica indesejada ocorre após o ponto de recuperação. Se o snapshot de segunda-feira contém um ficheiro saudável e o ficheiro ativo é sobrescrito na terça-feira, a vista de segunda-feira ainda pode mostrar os dados anteriores. Se o ficheiro já estava errado na segunda-feira, esse mesmo ponto de recuperação não pode resolver o problema.

O dano no armazenamento subjacente cria um caminho diferente. Um snapshot pode ter estado saudável quando criado, mas tornar-se ilegível mais tarde se um bloco físico que ainda referencia for danificado e o sistema de ficheiros não conseguir reconstruir uma cópia verificada. Por isso, o momento da corrupção deve ser considerado juntamente com a partilha de blocos e a redundância do armazenamento.

A partilha de blocos por cópia por escrita pode expor um bloco danificado através dos snapshots

Snapshots por cópia por escrita são eficientes em espaço porque os dados não alterados são partilhados. A documentação do modelo de armazenamento Btrfs explica que um snapshot e o seu subvolume de origem partilham os seus dados comuns e não modificados. Um snapshot é, portanto, uma visão histórica do sistema de ficheiros, não automaticamente uma segunda cópia física em mídia separada.

Quando o ficheiro ativo é modificado normalmente, a cópia por escrita aloca novo armazenamento para a alteração enquanto o snapshot continua a referenciar os blocos anteriores. Esta separação é o que torna possível o rollback. No entanto, se um bloco não alterado ainda for partilhado e esse bloco armazenado se tornar ilegível ou retornar dados incorretos, todas as visualizações que dele dependem podem encontrar a mesma falha.

Somas de verificação e armazenamento redundante podem alterar o resultado ao detetar a discrepância e fornecer outra cópia, mas o snapshot em si não cria essa proteção. A cópia por escrita fornece separação de versões; não cria um domínio independente de falha de hardware.

Somas de verificação e verificações testam a integridade; snapshots não

Snapshots, somas de verificação e verificações fazem parte de diferentes componentes da pilha de proteção. Um snapshot preserva o histórico, uma soma de verificação ajuda a determinar se os bytes armazenados mudaram inesperadamente, e uma verificação lê proativamente os dados armazenados para procurar erros. Tratar estas funcionalidades como intercambiáveis leva a uma falsa confiança sobre o que um ponto de recuperação pode comprovar.

As Somatórias de Verificação Podem Detetar Alterações Inesperadas nos Blocos

A documentação do Btrfs sobre soma de verificação afirma que as somas de verificação são calculadas antes das escritas e verificadas após os blocos serem lidos do armazenamento. Uma discrepância pode revelar que o bloco recuperado não é o mesmo que o bloco que o sistema de ficheiros esperava armazenar.

Uma soma de verificação correspondente não prova que um documento, base de dados ou ficheiro multimédia está logicamente correto. Se uma aplicação escrever dados incorretos através do caminho normal de escrita, o sistema de ficheiros pode calcular uma soma de verificação válida para esses bytes incorretos. O bloco está intacto do ponto de vista do sistema de ficheiros, mesmo que o conteúdo ao nível da aplicação seja inutilizável.

A Redundância Determina Se um Scrub Pode Reparar o Dano

Um scrub pode detetar erros de soma de verificação, erros de leitura e certos problemas de metadados, mas a deteção não é o mesmo que reparação. A documentação do Btrfs scrub explica que a reparação automática em armazenamento replicado usa dados bons verificados de outra réplica. Sem uma cópia alternativa válida, o sistema de ficheiros pode identificar o bloco danificado sem conseguir reconstruí-lo.

Um estudo USENIX sobre integridade de dados no ZFS separa de forma semelhante a deteção baseada em soma de verificação da recuperação usando redundância. A lição prática é mais restrita do que “scrubs corrigem corrupção”: um scrub pode reparar apenas as falhas para as quais o sistema de armazenamento consegue localizar ou reconstruir dados de substituição confiáveis.

A Retenção de Instantâneos Só Ajuda Se Ainda Existir um Estado Saudável

A corrupção nem sempre é detetada imediatamente. Uma fotografia, arquivo ou ficheiro de projeto raramente aberto pode permanecer danificado durante semanas antes de alguém tentar usá-lo. Se a rotação dos instantâneos já removeu todas as versões anteriores ao dano, uma coleção profunda de instantâneos recentes pode ainda assim não conter nenhum ponto de recuperação saudável.

A retenção deve, portanto, refletir a janela provável de deteção, e não apenas a frequência com que os instantâneos são criados. Instantâneos horários fornecem um histórico recente detalhado, enquanto pontos diários, semanais ou mensais de maior duração estendem o período em que um erro não detetado pode ser ultrapassado. Não existe um calendário universal: o intervalo útil depende da taxa de alteração, da capacidade disponível e da rapidez com que os ficheiros importantes são normalmente verificados.

Verifique uma Snapshot Antes de Substituir Dados Ativos no NAS

Escolher uma snapshot pela data é apenas o primeiro passo. Antes de reverter um conjunto de dados inteiro ou substituir o ficheiro ativo, restaure uma versão candidata para um local separado quando a plataforma home NAS o permitir. Isto evita que uma tentativa de recuperação não verificada sobrescreva dados mais recentes que ainda podem ser úteis.

1. Estime quando a corrupção apareceu pela primeira vez.
2. Selecione uma snapshot anterior a essa data.
3. Restaure o candidato numa pasta ou clone alternativo.
4. Abra, valide ou compare o conteúdo recuperado antes de substituir os dados ativos.

A validação deve corresponder ao tipo de dados. Uma soma de verificação conhecida pode verificar um arquivo inalterado, enquanto uma base de dados pode requerer a sua própria verificação de consistência e uma foto ou vídeo pode precisar de ser decodificado. Para a relação mais ampla entre pontos de recuperação, cópias independentes e proteção fora do dispositivo, veja esta estratégia de backup para NAS doméstico.

Perguntas Frequentes

Pode uma Snapshot Tirada Antes da Corrupção Ainda Tornar-se Ilegível?

Sim. Uma snapshot protege um estado lógico anterior contra alterações posteriores dos ficheiros, mas pode ainda partilhar o mesmo pool de armazenamento e blocos físicos. Se um desses blocos estiver danificado e não houver uma cópia redundante verificada disponível, a snapshot anterior pode tornar-se ilegível mesmo que seja anterior à corrupção lógica que está a ser investigada.

Uma Snapshot Bem-Sucedida Significa que Cada Ficheiro Dentro Dela Está Saudável?

Não. Uma snapshot bem-sucedida indica que o sistema de ficheiros criou o ponto de recuperação. Não significa que cada ficheiro foi aberto, decodificado, verificado contra uma versão confiável ou validado pela aplicação que o criou.

Pode um Scrub de Dados Reparar Corrupção Escrita por uma Aplicação?

Normalmente não, quando a aplicação escreveu o conteúdo incorreto normalmente. Nesse caso, o sistema de ficheiros pode armazenar os bytes errados com uma soma de verificação válida, não deixando nenhuma discrepância ao nível do bloco para o scrub detetar. A recuperação requer uma versão saudável anterior, um processo de reparação consciente da aplicação ou uma cópia independente.

Substituir um Ficheiro Ativo Corrompido Repara Snapshots Mais Antigas?

Não. Substituir os ficheiros ativos grava ou referencia dados saudáveis para o conjunto de dados ativo, mas as snapshots mais antigas continuam a representar os seus estados históricos. Uma snapshot que reteve a versão corrompida normalmente permanece corrompida até expirar ou ser eliminada.