Quinhentos terabytes não eram quinhentos terabytes iguais
O número total chamava atenção, mas planejar a migração exigia entender o que havia dentro dele, então o primeiro inventário separou arquivos ativos do Software Moodle™, vídeos, backups de cursos, temporários, caches, pacotes de processamento e conteúdos que já aguardavam exclusão, relacionando tamanho, quantidade, idade, taxa de mudança e importância para a abertura da plataforma, porque copiar cache como se fosse material pedagógico gastaria dias e transportar um backup antigo sem decisão de retenção apenas mudaria o endereço do excesso.
Cruzamos o armazenamento com as referências do banco para distinguir arquivos conhecidos, órfãos, temporários e objetos que poderiam ser regenerados, mas não removemos nada apenas por não encontrar uma associação na primeira consulta, pois plugins e integrações podem manter estruturas próprias, então os casos duvidosos foram amostrados, classificados e discutidos com as equipes responsáveis, enquanto caches e temporários receberam regras claras de recriação no destino.
Com a taxa real de leitura e escrita medida entre origem e destino, calculamos que uma cópia feita somente durante a manutenção ultrapassaria qualquer janela aceitável, mesmo usando toda a banda disponível, conclusão que levou a dividir o trabalho em uma transferência inicial com a plataforma funcionando, sincronizações intermediárias para reduzir a diferença e um delta final durante a parada, estratégia simples de resumir, porém dependente de controles rigorosos para saber o que havia mudado, o que fora excluído e quais arquivos estavam completos.
Copiar sem confundir movimento com conclusão
A primeira transferência percorreu o conjunto elegível enquanto alunos, professores, tarefas e integrações continuavam criando arquivos, o que significava aceitar que alguns objetos seriam alterados ou desapareceriam antes de a cópia terminar, então o destino recebeu tudo em uma estrutura preparada para sincronizações posteriores e nenhum total parcial foi tratado como prova de consistência, enquanto manifestos registravam caminho, tamanho, horário, hash quando viável, situação e última verificação, oferecendo uma visão independente da saída do programa de cópia.
Arquivos grandes foram tratados de forma diferente dos milhões de objetos pequenos, porque os primeiros exigiam retomada eficiente depois de uma interrupção e os segundos gastavam muito tempo em operações de catálogo, assim ajustamos paralelismo e tamanho de lote por grupo, acompanhando impacto sobre a origem para que a migração não piorasse a experiência de quem usava o Software Moodle™, além de limitar tarefas de verificação pesada nos horários de pico.
As sincronizações seguintes buscavam arquivos novos ou modificados desde a etapa anterior e diminuíam progressivamente a diferença, mas a comparação não dependia somente do horário do sistema, que poderia variar ou ser preservado de maneira diferente, por isso combinamos metadados, manifestos e hashes conforme o tipo de conteúdo, registrando também itens repetidamente instáveis para tratá los perto do corte, em vez de copiar várias vezes um arquivo temporário que ainda estava sendo escrito.
Exclusões também precisavam atravessar a migração
Copiar arquivos novos era apenas metade do trabalho, porque durante as semanas de migração a origem continuava removendo objetos e, sem uma estratégia para exclusões, o destino terminaria cheio de dados que já não existiam, então criamos uma lista baseada em comparações e eventos disponíveis, mas não apagávamos imediatamente, movíamos os candidatos para quarentena com data, origem da decisão e prazo, permitindo recuperar um item caso a ausência tivesse sido causada por uma leitura incompleta ou por uma diferença temporária de catálogo.
A consistência entre banco e moodledata orientou o corte, pois um banco atualizado apontando para uma cópia antiga de arquivos produziria falhas mesmo que cada lado parecesse correto isoladamente, então definimos a ordem de manutenção, parada de tarefas que escreviam dados, último backup do banco, sincronização do delta, aplicação das exclusões confirmadas, restauração no destino e liberação dos serviços, registrando em cada etapa qual sistema ainda era a fonte oficial e em que momento o retorno deixaria de ser apenas uma troca de endereço.
O ensaio completo reproduziu manutenção, interrupção dos trabalhadores, sincronização final, validação de manifestos, troca de configuração, abertura controlada e retorno, medindo não apenas duração da cópia, mas também o tempo para banco, cache, permissões, montagens e serviços auxiliares, porque uma janela calculada somente pelo volume de arquivos costuma ignorar os minutos necessários para confirmar que a aplicação realmente consegue ler, gravar e servir conteúdos no novo ambiente.
Um delta pequeno e uma validação enorme
No corte definitivo os quinhentos terabytes já estavam no destino, então a indisponibilidade ficou concentrada no banco, nos arquivos criados ou alterados depois da última sincronização, nas exclusões validadas e nas verificações finais, ainda assim acompanhamos volume e duração de cada conjunto para comparar com o ensaio e interromper com segurança se a diferença crescesse além do previsto, em vez de descobrir tarde demais que uma tarefa continuara produzindo dados na origem.
A primeira abertura mostrou alertas que pareciam perda de dados, mas parte deles vinha de caches copiados, referências temporárias e artefatos que deveriam ser regenerados, então limpamos e reconstruímos essas áreas antes de classificar uma divergência como falha real, cuidado importante para não iniciar uma transferência emergencial de dados desnecessários e, ao mesmo tempo, não usar a palavra cache como explicação genérica para qualquer arquivo ausente.
A validação combinou contagens por período e diretório, comparação de manifestos, hashes em grupos críticos, referências do banco, amostras de cursos e atividades, reprodução de vídeos, envio e download de arquivos, geração de novos conteúdos e acompanhamento de erros, enquanto as diferenças eram registradas com responsável e decisão, pois em uma massa desse tamanho sempre existem exceções e o objetivo não é fingir que todas desapareceram, mas saber quais são, por que existem e se afetam o uso.
Depois da liberação mantivemos a origem preservada por um período definido, monitoramos leituras ausentes, crescimento, latência e tarefas de arquivos, revisamos a quarentena antes da exclusão definitiva e documentamos a pré cópia, as sincronizações, o delta, o retorno e os tempos reais, transformando uma operação excepcional em conhecimento reutilizável para a próxima expansão de armazenamento ou mudança de infraestrutura.
A janela curta só foi possível porque o trabalho longo aconteceu antes, com inventário, transferência contínua, manifestos e ensaios, deixando para a manutenção apenas a diferença que ainda precisava ser fechada e as provas de que banco e arquivos contavam a mesma história.