Porque pode uma verificação da integridade do repositório ser bem-sucedida enquanto um ficheiro continua a falhar ao ser restaurado?

Uma verificação do repositório pode ser concluída com êxito enquanto um ficheiro não é restaurado, quando a verificação valida metadados ou dados amostrados em vez desse percurso de recuperação exato.

A verificação de cópias de segurança não é uma operação universal. Algumas verificações confirmam a estrutura do repositório, índices, manifestos e blocos referenciados sem ler todos os bytes armazenados. Outras analisam uma amostra dos dados, ignoram ficheiros que nunca foram capturados ou não dizem nada sobre os nomes, permissões, ACLs, etiquetas, espaço livre e bloqueios de aplicações do sistema de ficheiros de destino. Trate o ficheiro que falhou como um percurso desde a seleção do instantâneo, passando pelos objetos armazenados, até à criação no destino.

Identifique exatamente o que a verificação concluída com êxito validou

Guarde o comando de verificação, as opções, a versão da ferramenta de cópia de segurança, o backend do repositório, o ID do instantâneo e o registo final. Determine se foram verificadas a estrutura do repositório, os metadados do arquivo, os blocos referenciados, os dados armazenados ou uma extração efetiva.

O Borg indica que a sua verificação padrão do arquivo lê os metadados, mas não os dados dos ficheiros por predefinição, salvo se a verificação dos dados for solicitada explicitamente.

Assim, um resultado positivo pode provar que as referências são internamente consistentes, deixando alguns blocos de dados por ler. Não considere o repositório totalmente restaurável até extrair ficheiros representativos.

Determine se os dados armazenados do ficheiro foram realmente lidos

Localize o ficheiro no instantâneo pretendido e identifique os pacotes, blocos ou objetos necessários para o reconstruir. Compare o restauro que falhou com o âmbito de leitura de dados da verificação do repositório.

O Restic documenta as verificações read-data e read-data-subset, mostrando que uma verificação estrutural de rotina e uma leitura completa dos dados são níveis de verificação diferentes.

Se apenas foi lido um subconjunto, o ficheiro que falhou pode depender de um pacote não verificado. Execute uma verificação de dados direcionada ou completa, conforme suportado, antes de tentar reparar.

Confirme que o ficheiro foi incluído nesse instantâneo

Liste o caminho relativo exato no instantâneo selecionado. Verifique filtros, exclusões, avisos relativos a fontes ilegíveis, regras para ligações simbólicas, limites de montagem e se a interface de restauro selecionou outra versão.

O Kopia avisa que as políticas de ignorar omitem os caminhos correspondentes, pelo que a consistência do repositório pode ser validada mesmo quando o ficheiro pretendido nunca foi capturado.

Um caminho de marcador ou uma entrada do diretório principal não prova que a carga útil do ficheiro exista. Compare o inventário do instantâneo, o tamanho, o hash e o carimbo de data/hora com o registo esperado da origem.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique as restrições de nomes de ficheiros e caminhos do destino

Restaure o mesmo ficheiro para um caminho local curto e vazio, utilizando um nome simples. Compare caracteres inválidos, nomes reservados, conflitos entre maiúsculas e minúsculas, espaços no final, comprimento do caminho e normalização Unicode.

A documentação da Microsoft sobre nomes de ficheiros descreve as restrições de nomes de ficheiros e caminhos do Windows, que podem rejeitar um único caminho restaurado enquanto o próprio repositório permanece íntegro.

Se o ficheiro for restaurado para um caminho temporário curto, o conteúdo armazenado está disponível. Corrija a disposição do destino ou o mapeamento de renomeação, em vez de reparar o repositório.

Verifique o restauro de ACLs, atributos estendidos e propriedade

Repita o restauro com a preservação de metadados desativada, apenas num destino descartável, e compare-o com o restauro normal com preservação de metadados. Registe o primeiro atributo que falhar.

O GNU tar documenta separadamente o restauro de ACLs e atributos estendidos, ilustrando por que motivo os dados do ficheiro podem ser legíveis enquanto a aplicação dos metadados falha.

Não aceite um restauro sem metadados como solução para produção quando as aplicações dependem de ACLs, propriedade, intervalos esparsos ou xattrs. Utilize-o apenas para identificar a camada que está a falhar.

Verifique as etiquetas de segurança e a política do destino

Inspecione as etiquetas SELinux, o antivírus ou a proteção de endpoints, os controlos contra ransomware, os sinalizadores de imutabilidade, as permissões da partilha e os bloqueios de aplicações no destino do restauro.

A Red Hat documenta o restauro dos contextos de segurança predefinidos quando os ficheiros chegam com etiquetas em falta ou inadequadas.

Um ficheiro que é extraído mas não pode ser aberto pode indicar uma falha da política do destino, e não do repositório. Teste com o mesmo utilizador e a mesma aplicação que irão utilizar o ficheiro restaurado.

Faça um restauro isolado antes de qualquer reparação

Restaure o ficheiro que falhou, os metadados do respetivo diretório principal e vários ficheiros próximos para um conjunto de dados vazio ou um diretório temporário. Guarde os hashes, os registos e o estado do repositório antes de executar comandos de reparação.

O guia da ZimaSpace sobre verificação de checksums e metadados apresenta a distinção relacionada entre a integridade do conteúdo armazenado e uma recuperação utilizável pela aplicação.

O problema está resolvido quando o ficheiro selecionado é restaurado a partir do instantâneo pretendido, corresponde ao conteúdo esperado, recebe os metadados necessários e é aberto através do percurso da aplicação em produção.

Perguntas frequentes

Uma verificação do repositório concluída com êxito prova que todos os ficheiros podem ser restaurados?

Não. Isso depende de a verificação ter lido todos os dados armazenados e de o destino conseguir recriar cada caminho e os respetivos metadados.

Devo executar imediatamente uma reparação depois de uma falha no restauro?

Não. Primeiro teste outro destino, confirme que o ficheiro existe no instantâneo e execute uma verificação de dados suportada. A reparação pode remover metadados ou objetos danificados.

Um restauro de teste bem-sucedido é mais conclusivo do que um relatório de verificação?

Sim, para o percurso de recuperação testado. Prova a seleção, a desencriptação, a leitura da carga útil, a criação no destino e o tratamento de metadados para essa amostra específica.