O que faz com que os checksums dos ficheiros mudem após a cópia através de uma partilha SMB?

O SMB normalmente transporta os bytes dos ficheiros sem alterações, pelo que uma incompatibilidade de checksum significa que o conteúdo comparado foi alterado, foi lido de forma inconsistente ou não correspondia ao mesmo fluxo de dados.

A incompatibilidade pode resultar do cálculo do hash da origem antes de uma aplicação terminar a escrita, da comparação de um resource fork ou fluxo alternativo de um dos lados, de uma aplicação multimédia ou de segurança reescrever o destino, da leitura através de uma cache obsoleta do cliente ou de erros de armazenamento e transporte. O teste correto congela a origem, calcula o hash de ambos os ficheiros com a mesma ferramenta e no mesmo modo e repete a transferência através de um caminho controlado antes de atribuir a culpa ao próprio SMB.

Verifique se ambos os checksums abrangem os mesmos dados do ficheiro

Registe o caminho exato da origem, o caminho do destino, o comando de hashing, o algoritmo, o modo binário ou de texto e a hora em que cada checksum foi gerado. Confirme que nenhum dos comandos leu um atalho, o destino de um link simbólico, um ficheiro temporário ou um ficheiro auxiliar.

O utilitário SHA-256 calcula um resumo a partir dos bytes que lê do ficheiro especificado. A referência do sha256sum permite utilizar o mesmo algoritmo e a mesma invocação em ambos os endpoints.

Se os tamanhos forem diferentes, diagnostique uma cópia incompleta ou modificada antes de comparar os hashes. Se os tamanhos coincidirem, mas os hashes forem diferentes, prossiga com a verificação da estabilidade da origem, do âmbito dos fluxos, das leituras do armazenamento e das modificações no destino.

Impeça que as aplicações modifiquem a origem durante a cópia

Pare bases de dados, clientes de transferência, máquinas virtuais, editores multimédia, ferramentas de sincronização e qualquer aplicação que escreva no ficheiro de origem. Gere um checksum novo da origem apenas depois de o ficheiro ser fechado.

A documentação do Rsync avisa que os ficheiros só devem ser movidos para um diretório de origem monitorizado depois de estarem completamente escritos, porque um ficheiro de origem em alteração pode ser transferido de forma inconsistente.

Compare o checksum da origem imediatamente antes e depois da cópia SMB. Se os dois hashes da origem forem diferentes, o SMB não é a primeira causa; a origem foi alterada durante o teste.

Verifique os oplocks, os processos locais de escrita e o estado dos ficheiros em cache

Apresente os identificadores SMB abertos e os processos locais que acedem à origem e ao destino. Preste especial atenção quando a mesma partilha é escrita simultaneamente através de SMB e diretamente no anfitrião do NAS.

O Samba explica que os bloqueios oportunistas permitem a um cliente colocar localmente em cache as alterações aos ficheiros e sincronizá-las de volta com o servidor quando necessário. O seu modelo de bloqueios e oplocks demonstra por que motivo os processos locais e SMB que escrevem em simultâneo devem ser controlados durante os testes de integridade.

Não desative os oplocks em todo o servidor como primeira resposta. Feche as aplicações concorrentes, abra uma sessão nova e repita a cópia de um único ficheiro para confirmar se houve concorrência.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separe o conteúdo do ficheiro dos atributos estendidos e dos fluxos alternativos

Determine se o checksum esperado abrange apenas os dados principais do ficheiro ou um arquivo que também inclui resource forks, atributos estendidos, fluxos alternativos, ACLs e metadados. Utilize o mesmo âmbito em ambos os lados.

A ArchWiki descreve os atributos estendidos como metadados armazenados separadamente do conteúdo normal dos ficheiros. A perda ou conversão desses metadados pode alterar o hash de um arquivo ou pacote sem alterar o checksum do fluxo de dados principal.

No caso de ficheiros macOS, compare separadamente o data fork principal com qualquer resource fork ou ficheiro auxiliar AppleDouble. Não interprete uma incompatibilidade de metadados como prova de que os bytes do ficheiro principal foram alterados.

Utilize uma ferramenta de cópia com reinício e registo

Repita a transferência com um único método de cópia conhecido e um novo nome de ficheiro no destino. Guarde o registo de novas tentativas, reinícios, ficheiros ignorados e falhas, em vez de depender da janela de progresso de um navegador de ficheiros.

A Microsoft define o SMB como um protocolo que permite às aplicações ler, criar e atualizar ficheiros remotos. O seu modelo de acesso a ficheiros SMB permite tratar um checksum alterado como um problema no caminho dos dados ou num processo de escrita, e não como uma transformação esperada do protocolo.

Se uma cópia de linha de comandos com registo coincidir e a operação de arrastar e largar não coincidir, compare a aplicação, o comportamento de novas tentativas, o tratamento de ficheiros parciais, a análise antivírus e o processamento posterior à cópia, em vez de alterar o servidor SMB.

Compare o destino antes de este ser reescrito por indexadores ou aplicações

Calcule o hash do destino imediatamente depois da cópia, enquanto este estiver fechado e antes de os analisadores multimédia, conversores de documentos, gestores de fotografias, ferramentas antivírus ou clientes de sincronização o poderem alterar.

O guia da Robocopy da Oregon State salienta a cópia com registo e reinício, que estabelece um limite mais claro entre a conclusão da transferência e o acesso posterior das aplicações ao destino.

Se o hash imediato do destino coincidir, mas mudar mais tarde, identifique o primeiro processo que abre o ficheiro para escrita. A solução permanente pertence ao comportamento dessa aplicação relativamente a metadados, otimização ou sincronização.

Repita o teste através dos limites do armazenamento e da rede

Copie o mesmo ficheiro de teste fechado localmente no NAS de origem, localmente no sistema de ficheiros de destino, através de SMB a partir de outro cliente e através do cliente original. Calcule o hash após cada passo.

O guia da ZimaSpace sobre a preservação de metadados durante a migração de NAS fornece a regra complementar: os hashes do conteúdo e os campos de metadados devem ser validados como critérios de aceitação separados.

O problema está resolvido quando um ficheiro de origem fechado produz hashes coincidentes em cópias repetidas e permanece inalterado depois de os serviços pós-cópia serem executados. Pare a migração e proteja a origem se as incompatibilidades seguirem um disco, controlador ou cliente específico, ou um deslocamento de ficheiro reproduzível.