Blog

A migração a quente de 500 TB de moodledata

Sun, 30 Aug 2026 17:55:38 GMT

por Diego Ramos.

Uma pré cópia extensa, sincronizações incrementais, controle de exclusões e um delta final pequeno o suficiente para caber na janela de manutenção.

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.

O que ficou deste projeto

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.

Documentos privados ficaram acessíveis sem autenticação

Tue, 12 Nov 2024 03:00:00 GMT

por Diego Ramos.

Links públicos permitiam abrir arquivos restritos sem entrar no ambiente.

Documentos que deveriam exigir autenticação podiam ser abertos por qualquer pessoa que tivesse o endereço, por isso remover apenas os links das páginas não seria suficiente enquanto os próprios arquivos continuassem respondendo publicamente.

Para não transformar uma suspeita em diagnóstico, conferimos se o endereço usado estava correto, se a conta permanecia ativa, qual método de autenticação estava atribuído, quando havia ocorrido o último acesso bem sucedido e se a falha atingia apenas aquele usuário ou todos que dependiam do mesmo serviço, porque redefinir a senha novamente poderia apenas esconder por alguns minutos uma inconsistência de LDAP, SSO, certificado ou cadastro.

Depois de confirmar o alcance, reproduzimos o login em uma sessão limpa e acompanhamos os registros gerados desde o envio do formulário até a resposta do provedor de identidade, comparando a conta afetada com outra do mesmo perfil que ainda conseguia entrar e verificando horário, origem, retorno recebido e mudanças recentes na configuração.

Foi nessa comparação que o comportamento deixou de parecer aleatório, pois o resumo inicial de que links públicos permitiam abrir arquivos restritos sem entrar no ambiente. passou a coincidir com uma diferença concreta encontrada no caminho da autenticação, então a correção foi testada primeiro de forma controlada e depois repetida com perfis distintos para garantir que o acesso havia voltado sem abrir permissões além do necessário.

Bloqueamos os endereços expostos, identificamos os documentos alcançados e corrigimos as permissões na origem, depois testamos cada caminho em uma sessão sem login e revisamos materiais semelhantes para garantir que a mesma configuração não tivesse sido repetida em outras áreas.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

Uma conta de professor começou a enviar spam

Tue, 24 Sep 2024 03:00:00 GMT

por Diego Ramos.

Uma conta comprometida enviou mensagens indevidas para participantes de vários cursos.

Participantes de vários cursos começaram a receber mensagens indevidas enviadas por uma conta de professor, então o atendimento precisava interromper novos disparos imediatamente e ao mesmo tempo preservar o que ajudaria a entender quando e como o acesso foi usado.

Antes de alterar qualquer configuração, conferimos se o endereço usado estava correto, se a conta permanecia ativa, qual método de autenticação estava atribuído, quando havia ocorrido o último acesso bem sucedido e se a falha atingia apenas aquele usuário ou todos que dependiam do mesmo serviço, porque redefinir a senha novamente poderia apenas esconder por alguns minutos uma inconsistência de LDAP, SSO, certificado ou cadastro.

Com esse primeiro recorte pronto, reproduzimos o login em uma sessão limpa e acompanhamos os registros gerados desde o envio do formulário até a resposta do provedor de identidade, comparando a conta afetada com outra do mesmo perfil que ainda conseguia entrar e verificando horário, origem, retorno recebido e mudanças recentes na configuração.

Só então as evidências começaram a apontar para a mesma direção, pois o resumo inicial de que uma conta comprometida enviou mensagens indevidas para participantes de vários cursos. passou a coincidir com uma diferença concreta encontrada no caminho da autenticação, então a correção foi testada primeiro de forma controlada e depois repetida com perfis distintos para garantir que o acesso havia voltado sem abrir permissões além do necessário.

Suspendemos a conta, encerramos as sessões abertas e guardamos os registros para investigação, depois da redefinição segura revisamos permissões, dispositivos e mensagens enviadas antes de devolver o acesso, orientando também os destinatários para que ignorassem o conteúdo recebido.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

O banco foi atualizado, mas o servidor manteve código antigo

Mon, 05 Aug 2024 03:00:00 GMT

por Diego Ramos.

Uma publicação incompleta deixou o banco em uma versão nova enquanto parte dos arquivos do servidor permaneceu antiga.

Páginas diferentes exibiam erros de versões incompatíveis depois da atualização, algumas funcionavam e outras carregavam código antigo, um comportamento que mostrava que a publicação não havia chegado da mesma forma a todos os arquivos usados pelo servidor.

Em vez de começar pela correção mais provável, identificamos o curso, a atividade, a versão do material, o dispositivo e a forma de acesso, porque um conteúdo pode funcionar no navegador e falhar no aplicativo, abrir conectado e ficar antigo no modo offline ou depender de um formato que apenas alguns aparelhos conseguem reproduzir.

A partir dos horários e usuários reunidos, repetimos a abertura em condições equivalentes às relatadas, acompanhamos requisições, cache, versão local, tamanho de tela e arquivos entregues, depois comparamos o material recebido com a origem para distinguir falha de publicação, sincronização incompleta, pacote antigo e problema de apresentação.

O detalhe decisivo surgiu ao repetir o caminho completo sem pular nenhuma etapa, pois uma publicação incompleta deixou o banco em uma versão nova enquanto parte dos arquivos do servidor permaneceu antiga. apareceu de forma consistente sempre que o mesmo caminho era repetido, a correção foi seguida de um novo download ou carregamento limpo e o conteúdo inteiro foi percorrido até o envio final, evitando considerar resolvido um caso que apenas voltara a mostrar a primeira página.

Reunimos os registros e comparamos as versões carregadas, comprovando que o banco havia avançado enquanto a cópia do código ficou incompleta, refizemos a publicação de maneira íntegra e limpamos os caches de execução, depois percorremos administração, cursos e tarefas automáticas para confirmar que todo o ambiente usava a mesma versão.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

Um plugin essencial desapareceu após a migração

Mon, 17 Jun 2024 03:00:00 GMT

por Diego Ramos.

Os dados do plugin continuavam no banco, mas seu código não havia sido copiado para o novo servidor.

Depois da migração os dados ainda estavam presentes no banco e mesmo assim as funcionalidades de um plugin essencial não apareciam, uma combinação que apontava para uma mudança incompleta entre aquilo que foi levado como informação e aquilo que precisava existir como código.

O primeiro cuidado foi preservar o cenário como ele aparecia naquele momento, marcamos o horário exato da lentidão, as páginas envolvidas, os perfis afetados e o que continuava respondendo normalmente, depois reunimos aplicação, banco, tarefas agendadas, cache, armazenamento e integrações no mesmo intervalo, pois olhar apenas para uso médio de processador costuma esconder consultas bloqueadas e filas concentradas.

Quando já sabíamos quem era afetado, reproduzimos a ação com medição em cada etapa e comparamos o comportamento em cursos, contas e volumes diferentes, verificando consultas, quantidade de linhas, chamadas repetidas, bloqueios e trabalho executado em segundo plano, sempre mudando uma variável por vez para não atribuir a melhora ao ajuste errado.

A causa apareceu quando colocamos lado a lado o que funcionava e o que falhava, pois os dados do plugin continuavam no banco, mas seu código não havia sido copiado para o novo servidor. coincidiu com uma alteração mensurável nos registros e no tempo de resposta, a solução foi validada repetindo o cenário que provocava a falha e acompanhando o período seguinte para confirmar que a fila não estava apenas sendo empurrada para outro horário.

Comparamos os componentes dos dois servidores e confirmamos que a pasta do plugin não havia sido copiada, instalamos exatamente a versão compatível com os dados existentes e concluímos a atualização necessária, depois testamos as funções principais antes de liberar novamente o uso para a equipe.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

Uma atualização quebrou o tema em todas as páginas

Mon, 29 Apr 2024 03:00:00 GMT

por Diego Ramos.

Menus, blocos e conteúdos perderam a organização depois da atualização e foi necessário ativar temporariamente um tema padrão.

Depois da atualização o conteúdo ainda existia, mas menus, blocos e páginas ficaram desorganizados e algumas ações importantes quase não podiam ser alcançadas, por isso a aparência deixou de ser apenas uma questão visual e começou a impedir o uso do ambiente.

Para não transformar uma suspeita em diagnóstico, identificamos o curso, a atividade, a versão do material, o dispositivo e a forma de acesso, porque um conteúdo pode funcionar no navegador e falhar no aplicativo, abrir conectado e ficar antigo no modo offline ou depender de um formato que apenas alguns aparelhos conseguem reproduzir.

Depois de confirmar o alcance, repetimos a abertura em condições equivalentes às relatadas, acompanhamos requisições, cache, versão local, tamanho de tela e arquivos entregues, depois comparamos o material recebido com a origem para distinguir falha de publicação, sincronização incompleta, pacote antigo e problema de apresentação.

Foi nessa comparação que o comportamento deixou de parecer aleatório, pois menus, blocos e conteúdos perderam a organização depois da atualização e foi necessário ativar temporariamente um tema padrão. apareceu de forma consistente sempre que o mesmo caminho era repetido, a correção foi seguida de um novo download ou carregamento limpo e o conteúdo inteiro foi percorrido até o envio final, evitando considerar resolvido um caso que apenas voltara a mostrar a primeira página.

Ativamos temporariamente um tema padrão para devolver navegação e acesso aos usuários, então isolamos as incompatibilidades do tema personalizado e corrigimos cada uma fora do ambiente principal, a identidade visual só voltou quando as páginas mais usadas funcionaram novamente em telas grandes e pequenas.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

Um curso restaurado abriu sem vídeos, PDFs e anexos

Wed, 06 Mar 2024 03:00:00 GMT

por Diego Ramos.

O backup havia sido criado sem incluir os arquivos e trouxe apenas a estrutura das atividades para o novo ambiente.

A restauração terminou sem erro e todas as seções apareceram, mas vídeos, PDFs e anexos estavam ausentes, um resultado que parecia problema no novo servidor até compararmos o tamanho do backup com a quantidade de materiais existentes na origem.

Antes de alterar qualquer configuração, identificamos o curso, a atividade, a versão do material, o dispositivo e a forma de acesso, porque um conteúdo pode funcionar no navegador e falhar no aplicativo, abrir conectado e ficar antigo no modo offline ou depender de um formato que apenas alguns aparelhos conseguem reproduzir.

Com esse primeiro recorte pronto, repetimos a abertura em condições equivalentes às relatadas, acompanhamos requisições, cache, versão local, tamanho de tela e arquivos entregues, depois comparamos o material recebido com a origem para distinguir falha de publicação, sincronização incompleta, pacote antigo e problema de apresentação.

Só então as evidências começaram a apontar para a mesma direção, pois o backup havia sido criado sem incluir os arquivos e trouxe apenas a estrutura das atividades para o novo ambiente. apareceu de forma consistente sempre que o mesmo caminho era repetido, a correção foi seguida de um novo download ou carregamento limpo e o conteúdo inteiro foi percorrido até o envio final, evitando considerar resolvido um caso que apenas voltara a mostrar a primeira página.

Descobrimos que a cópia havia sido criada sem os arquivos, geramos um novo backup com a opção correta e repetimos a restauração, depois percorremos o curso como aluno e abrimos materiais de tipos diferentes para confirmar que não havia apenas links e nomes apontando para arquivos inexistentes.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

A migração de um bilhão de linhas de logs

Mon, 22 Jan 2024 03:00:00 GMT

por Diego Ramos.

Como reduzimos a pressão sobre o banco operacional sem perder histórico, auditoria e relatórios, movendo dados antigos em lotes enquanto novos eventos continuavam chegando.

O banco ainda respondia, mas cada mês custava mais

A tabela de logs crescia todos os dias e por muito tempo o aumento foi absorvido com mais espaço, manutenção e índices, até que relatórios começaram a percorrer períodos enormes, rotinas de limpeza demoravam cada vez mais e operações comuns do banco disputavam recursos com consultas históricas, então medimos o volume total, o crescimento diário, a distribuição por tipo de evento, usuário, componente e período, identificando também integrações que registravam informações em excesso, porque migrar um bilhão de linhas sem reduzir a causa apenas transportaria o mesmo problema para um lugar novo.

A projeção mostrou que ampliar a infraestrutura adiaria a dificuldade, mas não mudaria a relação entre uma base operacional, que precisa responder rapidamente às ações atuais, e um histórico usado para auditoria e análise, que aceita outra organização e outras formas de consulta, por isso levantamos todos os consumidores antes de mover qualquer registro, incluindo relatórios do Software Moodle™, ferramentas de BI, integrações, investigações de suporte, obrigações de retenção e consultas manuais que existiam apenas na rotina de uma pessoa.

Esse mapeamento revelou dependências inesperadas, como relatórios que presumiam encontrar toda a vida do aluno na tabela principal, processos que guardavam o último identificador lido e rotinas externas que buscavam novamente períodos já processados, então cada consumidor recebeu uma decisão, continuar consultando a janela recente no banco operacional, passar a usar a base histórica ou combinar as duas fontes por uma camada controlada, evitando que o corte terminasse com dezenas de consultas apontando silenciosamente para dados incompletos.

Laboratório com tamanho suficiente para dizer a verdade

Os primeiros ensaios com alguns milhões de linhas funcionaram rápido demais e produziram uma confiança enganosa, pois índices, cache, ordenações e espaço temporário se comportam de outra maneira quando a tabela e os lotes crescem, então montamos uma base proporcional ao volume real, preservando distribuição de datas, tipos de evento e tamanhos de campos, depois repetimos extração, importação, consulta e exclusão enquanto observávamos uso de disco, geração de logs internos, bloqueios, replicação e tempo de recuperação após uma interrupção.

Definimos uma janela recente que continuaria no banco operacional e uma estrutura histórica preparada para consultas por período, usuário, curso, componente e evento, sem copiar todos os índices da origem por hábito, porque cada índice aumenta o custo de importação e armazenamento, então começamos pelos caminhos realmente usados, medimos os planos de execução e deixamos espaço para ajustar depois que os relatórios estivessem trabalhando com o volume verdadeiro.

A migração foi dividida por intervalos de tempo e limites de identificadores, com lotes pequenos o suficiente para serem retomados e grandes o bastante para não desperdiçar a maior parte do tempo abrindo transações, cada lote recebia situação, primeira e última linha esperada, contagem, horário, checksum calculado sobre campos estáveis e resultado da importação, permitindo que uma falha de rede ou armazenamento voltasse ao ponto de controle em vez de reiniciar meses de eventos.

Mover o passado enquanto o presente continuava chegando

Começamos pelos períodos mais antigos e mantivemos o Software Moodle™ em funcionamento, pois os novos eventos eram gravados em uma faixa muito distante daquela que estava sendo transferida, mesmo assim limitamos ritmo e concorrência para que a leitura de grandes lotes não retirasse recursos das atividades dos alunos, ajustando o processo conforme latência do banco, tamanho da fila e horários de maior uso, uma migração quente que demorava mais no calendário, porém reduzia bastante o trabalho necessário durante a parada definitiva.

Depois de cada importação comparávamos contagens por período e tipo, limites de identificadores, checksums e amostras escolhidas de diferentes componentes, mantendo os registros na origem até a validação e separando o ato de copiar do ato de remover, porque apagar imediatamente tornaria a recuperação mais difícil e misturaria duas operações de risco, então somente lotes confirmados entravam na fila de retenção e ainda respeitavam o prazo definido para retorno.

O ponto de controle guardava o último evento incluído na migração quente e permitia buscar, perto do corte, apenas aquilo que havia sido criado depois, enquanto relatórios eram adaptados e testados contra as duas fontes, primeiro comparando resultados no mesmo período e depois medindo consultas longas, paginação e filtros, pois o sucesso não seria apenas ter um bilhão de linhas em outro banco, mas permitir que auditoria e análise continuassem encontrando a informação com tempo previsível.

O corte e o trabalho que veio depois

Na janela de manutenção interrompemos os produtores conhecidos, registramos o último identificador, transferimos os eventos posteriores ao ponto de controle, repetimos as validações e direcionamos os relatórios históricos para a nova estrutura, depois executamos um conjunto curto de consultas conhecidas em ambos os lados para confirmar totais, limites e amostras antes de liberar a plataforma, com um procedimento de retorno que preservava a origem e permitia desfazer o direcionamento sem tentar reimportar todo o histórico às pressas.

As primeiras consultas no destino ainda apresentaram planos inadequados, porque as estatísticas não representavam bem a distribuição recém importada e alguns filtros combinavam colunas de uma forma diferente da observada no laboratório, então atualizamos estatísticas, revimos índices, reescrevemos consultas específicas e medimos novamente com períodos pequenos e extensos, evitando declarar o projeto encerrado no momento em que o último lote havia sido copiado.

Também implementamos uma política contínua de retenção, na qual novos eventos permanecem no banco operacional pelo período necessário e depois seguem para o histórico com os mesmos controles de lote e validação, acompanhada de indicadores de crescimento, divergência, atraso e desempenho, pois sem esse ciclo a plataforma voltaria ao ponto inicial alguns meses depois e a grande migração teria servido apenas como uma limpeza excepcional.

O resultado foi um banco operacional menor e mais previsível, relatórios históricos capazes de consultar períodos longos sem disputar o mesmo espaço das ações atuais e um processo verificável para continuar movendo dados, mantendo a trilha de auditoria sem exigir que toda consulta, antiga ou recente, percorresse um bilhão de linhas no coração da plataforma.

O que ficou deste projeto

Migrar os logs não significou escolher entre desempenho e história, significou reconhecer que dados recentes e históricos têm ritmos diferentes, organizar cada um para seu uso e construir uma passagem contínua entre os dois.

A restauração de um curso urgente ficava parada por horas

Thu, 18 Jan 2024 03:00:00 GMT

por Diego Ramos.

Uma atividade incompatível dentro do arquivo de backup fazia a restauração travar sempre na mesma etapa.

O curso começaria no dia seguinte e a restauração avançava por um longo tempo até parar sempre no mesmo ponto, por isso aumentar o limite e tentar novamente só consumia mais horas sem alterar o comportamento.

O detalhe decisivo surgiu ao repetir o caminho completo sem pular nenhuma etapa, pois uma atividade incompatível dentro do arquivo de backup fazia a restauração travar sempre na mesma etapa. apareceu de forma consistente sempre que o mesmo caminho era repetido, a correção foi seguida de um novo download ou carregamento limpo e o conteúdo inteiro foi percorrido até o envio final, evitando considerar resolvido um caso que apenas voltara a mostrar a primeira página.

Abrimos a análise do arquivo e localizamos uma atividade incompatível com o ambiente de destino, preparamos uma cópia sem aquele componente e concluímos a restauração, depois o conteúdo da atividade foi tratado separadamente e o curso inteiro passou por uma conferência antes da abertura aos alunos.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.

Todos os backups automáticos falharam antes da migração

Mon, 27 Nov 2023 03:00:00 GMT

por Diego Ramos.

O diretório de destino estava sem espaço e nenhum curso possuía uma cópia recente na semana da mudança de servidor.

Na semana da migração descobrimos que os cursos não tinham cópias recentes, embora as tarefas automáticas aparecessem programadas, uma situação que tornava arriscado continuar a mudança antes de saber por que todos os arquivos novos haviam deixado de ser criados.

A causa apareceu quando colocamos lado a lado o que funcionava e o que falhava, pois o diretório de destino estava sem espaço e nenhum curso possuía uma cópia recente na semana da mudança de servidor. coincidiu com uma alteração mensurável nos registros e no tempo de resposta, a solução foi validada repetindo o cenário que provocava a falha e acompanhando o período seguinte para confirmar que a fila não estava apenas sendo empurrada para outro horário.

A análise dos relatórios levou ao diretório de destino completamente ocupado, liberamos espaço, revisamos a retenção e executamos novos backups priorizando os cursos da migração, cada arquivo foi conferido antes de seguir para o outro servidor para que a existência do nome na pasta não fosse confundida com uma cópia válida.

Foi assim que esse caso saiu da fila de chamados e passou a fazer parte dos bastidores da EAD Suporte.