Large migrations · Verification · A prova por trás da barra de progresso

Movendo centenas de GB entre nuvens: como saber se cada arquivo chegou?

Com 500 GB, “o upload parecia concluído” não é evidência. Uma migração confiável precisa de um inventário durável, uma transição de estado para cada objeto, recuperação repetível após interrupções e prova do próprio destino.

Atualizado ; 16 min de leitura.

Resposta curta

FileArk divide a biblioteca em registros por arquivo e mensagens de fila duráveis. Um trabalhador copia uma entrega, armazena o ID de destino retornado, valida o tamanho, lê o objeto exato de volta e compara o SHA-256 com a carga útil de origem. O registro é verificado – e a mensagem é confirmada – somente após essas verificações e a atualização do banco de dados serem bem-sucedidas.

Por que a escala muda o significado de “funcionou”

Dez arquivos são fáceis de inspecionar. Dez mil arquivos não são. Uma grande biblioteca pessoal pode combinar documentos minúsculos, vídeos de vários gigabytes, arquivos vazios, pastas aninhadas, nomes Unicode, projetos arquivados e formatos nativos da nuvem. Uma falha pode se esconder dentro de uma porcentagem impressionante.

Os totais são úteis, mas incompletos. Duas bibliotecas podem mostrar o mesmo tamanho aparente enquanto uma está faltando um objeto ou contém um objeto truncado balanceado por algum arquivo não relacionado. As contagens de arquivos também podem diferir após a exportação de documentos nativos ou objetos de provedor excluídos.

A unidade de verdade útil é o trabalho de arquivo: qual objeto de origem foi lido, qual objeto de destino foi criado, quais bytes foram comparados, quando a verificação foi concluída e se alguma tentativa permanece sem solução.

O ciclo de vida completo do FileArk, anotado

Ciclo de vida anotado mostrando o trabalhador de fila durável do banco de dados do scanner de configuração do navegador FileArk e a verificação SHA-256
O navegador inicia o fluxo de controle; o scanner, a fila persistente, o banco de dados e o trabalhador realizam a migração de longa duração.

Quando Iniciar é aceito, a API primeiro grava um trabalho de verificação no MongoDB e, em seguida, publica uma mensagem de verificação persistente em uma fila durável do RabbitMQ com a confirmação do editor habilitada. Se a publicação falhar, o trabalho será marcado como Com falha e a API informará que não foi possível enfileirar a verificação com segurança.

O scanner autentica ambos os provedores, inventaria a origem selecionada, verifica a cota de destino finita em relação aos bytes descobertos e atualiza um registro de banco de dados para cada arquivo de origem. Ele publica mensagens de migração persistentes e marca a verificação como concluída somente após essas publicações serem bem-sucedidas.

O trabalhador de migração usa confirmações manuais e uma contagem de pré-busca de um. Uma entrega permanece sem confirmação enquanto o conteúdo é lido, carregado, relido, verificado e persistido. Uma conexão ou processo interrompido pode, portanto, retornar trabalho inacabado para a fila.

Uma linha do banco de dados é um item da lista de verificação, não uma contabilidade descartável

Cada registro de arquivo começa como Pendente, passa para InProgress durante uma tentativa e chega a Carregado somente após a verificação. A contagem de tentativas, a hora da última tentativa, os detalhes do erro, o ID do objeto de destino, os resumos SHA-256, o método de verificação e o VerifiedAt permanecem anexados ao registro.

Os registros concluídos permanecem no banco de dados como progresso e trilha de auditoria. “Riscar um arquivo” significa uma mudança de estado controlada, não a exclusão da evidência. As entregas de fila duplicadas inspecionam esse estado e reconhecem imediatamente um registro já marcado como Carregado com VerifiedAt.

Após três tentativas malsucedidas, um problema persistente se torna Falha com um carimbo de data/hora de conclusão para o ciclo de tentativa. Isso torna as exceções visíveis e evita que uma mensagem suspeita gire para sempre enquanto o painel parece travado.

A porta de conclusão para um arquivo
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

Por que um arquivo pode ser entregue mais de uma vez

Filas confiáveis geralmente fornecem entrega pelo menos uma vez, e não uma promessa mágica de exatamente uma vez em uma API de nuvem, um agente de mensagens e um banco de dados. Uma falha pode ocorrer depois que o OneDrive ou o Google Drive aceita um upload, mas antes que o trabalhador grave a conclusão.

FileArk lida com essa incerteza com registros idempotentes e recuperação de destino. O trabalhador primeiro verifica se o registro já foi verificado. Caso contrário, ele poderá usar o ID de destino armazenado ou pesquisar o caminho de destino esperado e o tamanho exato do resultado interrompido antes de decidir fazer o upload novamente.

Os candidatos à recuperação são então submetidos à mesma verificação de hash do objeto exato. Encontrar um nome de arquivo familiar não é suficiente. A questão é converter uma tentativa interrompida novamente em evidência, e não num sucesso optimista.

A capacidade é verificada no destino e no trabalhador

Antes da publicação dos trabalhos por arquivo, o scanner totaliza os tamanhos de metadados de origem não negativos e compara o requisito com o armazenamento restante relatado do destino sempre que o provedor fornece uma cota finita. Um destino subdimensionado falha na verificação em vez de levar o trabalho a um beco sem saída conhecido.

O número é uma simulação, não uma garantia: a atividade da conta pode consumir espaço durante uma execução, os relatórios de cota do provedor podem atrasar e os arquivos exportados nativos da nuvem podem não ter um tamanho de origem convencional. A aplicação do provedor e o tratamento de erros por arquivo permanecem ativos.

O disco do seu computador não é usado para teste. No trabalhador de migração, os arquivos acima do limite de memória serão colocados em um diretório temporário isolado somente depois que o volume tiver espaço para o objeto esperado, além de uma reserva de dois gigabytes. O conteúdo temporário é removido na limpeza, independentemente de a tentativa ser bem-sucedida ou fracassar.

Por que o ID de destino mais SHA-256 é importante

Um nome de arquivo não é uma identidade única. O destino pode já conter dois arquivos com o mesmo nome visível ou a listagem de metadados pode levar algum tempo para ser estabelecida. A resposta de upload fornece um ID de objeto do provedor e o FileArk armazena esse ID antes do estágio final de verificação.

O trabalhador calcula o SHA-256 no fluxo de carga útil de origem, faz upload dele e, em seguida, abre o objeto de destino exato por esse ID e calcula o SHA-256 novamente. Tamanho igual detecta truncamento óbvio; o resumo criptográfico igual é a verificação mais forte em nível de byte.

Somente a representação do arquivo transferido é coberta. Um resumo não pode validar regras de compartilhamento, comentários, versões, rótulos, atalhos, configurações de retenção ou como um documento exportado do Google é renderizado para um usuário. Essas continuam sendo tarefas de aceitação.

A exclusão da fonte está intencionalmente fora do caminho normal de sucesso

O padrão mais seguro é somente cópia e a opção de exclusão do FileArk está desativada, a menos que você a habilite. Com a exclusão desativada, uma falha na verificação não poderá remover o original porque a exclusão nunca é solicitada.

Se você ativar deliberadamente a exclusão após movimentação, o trabalhador ainda aguardará o ID de destino, o tamanho e a validação SHA-256 antes de chamar a operação de exclusão do provedor de origem. A escolha operacional mais forte para bibliotecas insubstituíveis ou muito grandes ainda é manter a opção desativada e utilizar um período de sobreposição aprovado por humanos.

A migração responde “chegou uma cópia verificada?” A retenção responde “quando a cópia antiga pode ser removida?” Trate-as como decisões separadas com evidências separadas.

O mesmo modelo de controle funciona em ambas as direções

Do OneDrive para Google Drive, a carga útil de origem é lida no Microsoft Graph e o objeto de destino é verificado por meio do Google Drive pelo ID retornado. Do Google Drive para OneDrive, a fonte é baixada ou exportada por meio do Google Drive e o novo item do OneDrive é lido por meio do Microsoft Graph.

A fila, os estados do banco de dados, as tentativas limitadas, a simulação de capacidade, o resumo de origem, o ID de destino, o resumo de destino e a ordem de confirmação são de direção neutra. Os adaptadores de provedor lidam com diferentes APIs de upload, pasta e conteúdo.

A assimetria é a semântica do conteúdo. Os documentos nativos do Google precisam ser exportados e ambas as plataformas têm compartilhamento específico do serviço e comportamento de versão. O conteúdo do arquivo verificado por bytes não deve ser comercializado como um clone completo de todos os recursos de colaboração.

Use um plano de aceitação de quatro partes

  1. Reconciliar o registro do sistema

    Revise contagens concluídas, pendentes, em andamento e com falha. Nenhum item com falha deve ser descartado porque a porcentagem geral é alta.

  2. Amostra por risco

    Abra os arquivos que mais prejudicariam a perda, além de mídias grandes, arquivos, documentos antigos, nomes em idiomas diferentes do inglês, caminhos aninhados e arquivos convertidos nativos da nuvem.

  3. Validar o comportamento do destino

    Teste o acesso de dispositivos e usuários reais. Reconstrua o compartilhamento necessário e confirme se os arquivos do Office ou exportados do Google abrem conforme esperado.

  4. Manter um período de sobreposição

    Mantenha a fonte disponível e estável enquanto o uso normal exercita o destino. Tome qualquer decisão de cancelamento ou exclusão posteriormente.

Perguntas frequentes

O FileArk usa uma fila para cada arquivo?

Sim. O scanner cria ou reutiliza um registro de banco de dados por arquivo de origem e publica uma mensagem de migração persistente. Os trabalhadores extraem essas mensagens com reconhecimento manual.

Quando uma mensagem da fila é reconhecida?

Após a verificação do ID do objeto de destino, do tamanho e do SHA-256 e da persistência do estado Uploaded e VerifiedAt. Entregas inacabadas podem ser entregues novamente.

Os registros de arquivos concluídos são excluídos do banco de dados?

Não. A conclusão é uma transição de estado no registro durável. A linha mantém a identidade do destino, evidências de verificação, tempo e informações de tentativa para progresso e auditoria.

O SHA-256 pode provar que as permissões e versões foram movidas?

Não. Isso prova que os bytes do arquivo de destino correspondem à carga de origem transferida. Compartilhamento, permissões, versões, comentários, rótulos, atalhos e comportamento nativo do provedor precisam de validação separada.

O OneDrive para Google Drive é verificado da mesma forma que o inverso?

A regra principal é a mesma em ambas as direções: resumo da carga útil de origem, identidade do objeto de destino, tamanho do destino, resumo de novo download do objeto exato, verificação persistente e, em seguida, reconhecimento da fila.

Recursos oficiais utilizados neste guia

Ler o guia