Backups antigos do Moodle guardando dados de quem já saiu
Caso real de produção, contado sem identificar o cliente. Numa revisão de segurança e dados, encontramos um problema que quase ninguém olha até ser tarde: backups antigos que ainda guardavam dados pessoais e credenciais de professores que há muito não usavam a plataforma. Contas de gente já desligada, preservadas indefinidamente dentro de arquivos de backup que se acumulavam sem prazo para sumir.
Ninguém tinha feito nada de errado de propósito. É o cenário mais comum: o backup foi feito "por segurança", ninguém definiu por quanto tempo guardar, e o tempo foi empilhando arquivos. O detalhe é que, do ponto de vista da LGPD, isso é justamente o que não se deve fazer.
Por que isso é um problema (mesmo sem ter havido vazamento)
Um backup que inclui usuários carrega dados pessoais — nome, e-mail, campos de perfil — e informações de conta. A LGPD trabalha com dois princípios simples de entender e fáceis de furar:
- Minimização: guardar só o dado necessário.
- Retenção por prazo: não manter dado pessoal por mais tempo do que se justifica.
Backups eternos, com dados de pessoas que nem estão mais na instituição, quebram os dois. E há o agravante prático: quanto mais dado parado guardado, maior a superfície de risco. Se um arquivo mal protegido cai em mãos erradas, o estrago é proporcional ao que estava guardado sem uso. Dado que não deveria mais existir não pode vazar.
O diagnóstico
O trabalho começou por um inventário, sem chute: quantos backups existiam, onde estavam, o que continham e quem ali já não era usuário ativo. Ficou claro o padrão — ausência de política de retenção, backups incluindo dados de usuários por padrão, e nenhuma rotina de revisão de contas inativas. O dado não estava "exposto" por uma falha exótica; estava exposto por ficar guardado a mais, sem necessidade e sem prazo.
A solução
A correção é de governança, não de heroísmo técnico:
- Política de retenção: definir por quanto tempo cada backup vive e descartar o que passou do prazo.
- Separar os propósitos: um backup técnico, protegido e com prazo, para conseguir restaurar a plataforma — não um arquivo permanente de dados pessoais.
- Tratar as contas inativas: desativar, anonimizar ou remover usuários que já não pertencem à plataforma, conforme a regra do negócio.
- Proteger o armazenamento: acesso restrito a quem realmente precisa dos backups.
O resultado
Superfície de exposição reduzida, backups que continuam servindo para o que existem — restaurar — sem virar um depósito eterno de dados de quem já saiu, e a operação alinhada ao que a LGPD espera. O que antes era um passivo silencioso virou um processo com prazo e responsável.
A lição do caso: backup não é só "ter uma cópia". É decidir o que guardar, por quanto tempo e com que proteção. Sobre fazer isso direito, veja como fazer backup do Moodle (e restaurar sem susto); e sobre a parte de conformidade, o checklist de LGPD no treinamento corporativo cobre os pontos que decidem se o seu projeto é tranquilo ou uma dor de cabeça.