Agentes de programação agora têm acesso ao shell de máquinas reais. Eles executam migrações, limpam diretórios, redefinem branches e removem arquivos que parecem desnecessários. Na maioria das vezes, é exatamente isso que você pediu. Mas surgiu um novo modo de falha, que tornou o backup de agentes de IA uma categoria própria: uma cópia ao alcance do agente também pode ser destruída por ele, geralmente enquanto cumpre uma tarefa legítima.
Esse não é um risco hipotético criado para vender armazenamento. Quem executa agentes em um checkout ativo provavelmente já viu algum deles apagar o que deveria preservar. Esta página apresenta um padrão de backup capaz de reduzir esse risco quando configurado corretamente e deixa claro o que ele não cobre.
Por que seu backup atual não é um backup para agentes de IA
O modelo de ameaça tradicional considera falhas de hardware, erros humanos ou ransomware. Os agentes atravessam as três categorias, pois atuam com suas credenciais, na velocidade da máquina e com justificativas aparentemente plausíveis.
Uma unidade de rede montada fica visível para tudo que roda como seu usuário. O mesmo vale para uma pasta sincronizada, uma unidade mapeada ou um bucket de objetos cujas chaves estejam em um arquivo de ambiente legível pelo agente. Se ele concluir que um diretório contém uma compilação antiga, que o repositório precisa ser redefinido ou que é necessário liberar espaço, tudo o que vê pode entrar no escopo. A sincronização então propaga a exclusão para a cópia em que você confiava, exatamente como foi projetada para fazer.
Portanto, a diferença de um backup para agentes de IA não é estar na nuvem ou no local. É a cópia ser ou não acessível a partir do ambiente onde o agente trabalha.
O padrão de backup: enviar, nunca sincronizar
Este é o ponto que costuma causar confusão e merece uma seção própria.
A sincronização é bidirecional por natureza. Ao apagar o arquivo local, o remoto acompanha, comportamento adequado para arquivos de trabalho, mas perigoso para um arquivo histórico. Muitas soluções chamadas de backup são, na verdade, sincronização: protegem contra falha do disco, não necessariamente contra exclusão. Há anos, orientações nacionais sobre ransomware reforçam esse princípio. Segundo a recomendação da CISA, uma cópia deve ficar isolada do sistema protegido. Um agente com acesso ao shell é apenas uma maneira nova e rápida de falhar nesse teste.
Um backup adequado envia novos materiais sem espelhar remoções. Destinos com data ou horário fazem cada execução adicionar uma cópia, em vez de substituir a anterior. Em muitas configurações, trinta cópias diárias de um dump de banco de dados custam menos que o tempo gasto explicando por que não havia uma cópia restaurável.
A separação de credenciais é o ponto central
O mecanismo é simples, uma qualidade em backups. Você precisa de um caminho de envio unidirecional e de credenciais que nunca fiquem disponíveis no ambiente de trabalho.
O Drive permite criar no painel senhas de aplicativo vinculadas a um dispositivo e revogáveis separadamente. O padrão mais seguro usa uma credencial exclusiva de backup, presente apenas na máquina ou na tarefa agendada que faz o envio: nunca no diretório do projeto, em um arquivo de ambiente compartilhado ou em qualquer local apresentado ao agente. O agente trabalha livremente na cópia ativa, mas não tem um caminho até o destino.
Se a tarefa de envio roda na mesma máquina do agente, mantenha a credencial fora da árvore do projeto e aplique permissões mínimas do sistema operacional. Se ela roda em outro equipamento, como um dispositivo sempre ligado ou um executor agendado, a separação é ainda mais clara, pois não há sistema de arquivos compartilhado. Em ambos os casos, o backup só resiste enquanto o agente e seus processos não conseguem ler nem obter a credencial.
O que esse backup protege e o que não protege
A precisão importa mais do que uma mensagem tranquilizadora.
Ele pode proteger contra um agente apagar ou sobrescrever arquivos no ambiente de trabalho, um script limpar um diretório, uma redefinição acidental do repositório e erros humanos comuns, desde que já exista uma cópia completa e isolada. Também cobre a propagação por sincronização de uma exclusão não intencional.
Ele não protege contra quem tenha seu login do painel e o segundo fator, pois essa pessoa pode revogar senhas de aplicativo e esvaziar a lixeira. Também não cobre o comprometimento do destino, uma política de retenção inadequada ou a exclusão deliberada do arquivo. E não substitui o controle de versão do código-fonte, que resolve outro problema.
O backup de agentes de IA é apenas uma camada. Não é um programa completo de segurança, e qualquer afirmação diferente exagera sua função.
O que vale a pena enviar
A lista é menor do que parece, porque boa parte de um diretório de trabalho pode ser reproduzida.
- Dumps do banco de dados. São dados que de fato não podem ser recriados. Gere uma cópia noturna com data e retenha-a conforme os limites do plano e sua política de retenção.
- Arquivos de ambiente e configuração. Pequenos, muitas vezes esquecidos e difíceis de reconstruir, eles também podem conter segredos. Criptografe-os, limite o acesso e planeje a rotação das credenciais.
- Conteúdo enviado pelos usuários. Não está no controle de versão, não pode ser regenerado e costuma ser ignorado até desaparecer.
- Artefatos gerados importantes. Relatórios e exportações produzidos por um processo que mudou desde então.
Em geral, o código-fonte não precisa estar aqui quando um repositório git remoto e devidamente protegido já preserva o histórico. Incluí-lo não causa prejuízo, mas não é a finalidade desta camada.
Como é uma tarefa noturna
A implementação pode ser curta e fácil de auditar, o que reduz a manutenção, embora não garanta que sempre funcionará.
Uma tarefa agendada roda uma vez por noite. Ela exporta o banco de dados para um arquivo temporário, inclui a data no nome, envia-o para um caminho datado na unidade, confirma que o upload terminou corretamente e só então apaga a cópia temporária local. Arquivos de configuração e conteúdo enviado seguem o mesmo processo. A tarefa mantém sua própria credencial, não lê segredos do diretório do projeto e não possui lógica de exclusão remota.
Dois detalhes separam um backup útil de outro que falha silenciosamente. Primeiro, o caminho de destino precisa conter a data, para que cada execução crie uma nova cópia. Usar o mesmo nome toda noite deixa exatamente um backup, o da noite anterior, insuficiente para um problema percebido na quinta-feira. Segundo, falhas devem gerar alertas verificados. Um backup que não funciona há seis semanas pode criar uma falsa sensação de proteção.
Teste da restauração
Uma cópia que ninguém restaurou ainda é uma hipótese, não um backup comprovado. Esse costuma ser o ponto mais fraco das configurações.
Uma vez por trimestre, baixe uma cópia e restaure-a de verdade em um ambiente descartável. Verifique três coisas: se o arquivo foi baixado íntegro, se está completo e não truncado por uma tarefa interrompida e se você conhece o procedimento. O terceiro ponto é importante, porque uma emergência não é a hora de descobrir como restaurar.
A restauração também valida um aspecto específico dessa arquitetura: o acesso ao destino e o processo de recuperação ainda funcionam. Sozinha, ela não comprova que a credencial de envio continua válida e atualizada. Monitore separadamente cada upload e seu horário, pois a etapa de envio pode falhar enquanto o restante parece normal.
Por quanto tempo manter as cópias
A retenção depende do risco, das obrigações e do orçamento de armazenamento, não de uma regra técnica universal. O período adequado costuma ser maior do que a primeira escolha.
Nem toda falha é percebida imediatamente. Um diretório removido pode ser notado em poucas horas, mas uma corrupção sutil dos dados ou a exclusão de algo usado apenas mensalmente pode passar semanas despercebida. Trinta cópias diárias oferecem um mês de histórico. O custo, porém, depende do volume real, do crescimento dos dados e do plano contratado.
Um padrão comum é manter todas as cópias diárias por um mês e depois uma por mês durante um ano. Isso limita o crescimento e preserva um histórico mais longo. Seja qual for a regra, faça a limpeza com uma tarefa distinta, outra identidade e controles adequados. Se o próprio processo de upload também puder apagar, parte do risco que a arquitetura pretendia reduzir volta a existir.
Onde armazenar
O Drive fica vinculado à mesma conta do e-mail, o que pode reduzir a quantidade de serviços e faturas. Na oferta descrita aqui, o adicional começa em 250 GB por $3.20 mensais, com um controle que chega a 100 TB, sujeito aos termos e limites do plano. A ausência de cobrança de saída anunciada para essa oferta é útil durante uma restauração, mas confirme as condições aplicáveis à conta.
Conforme a configuração, o armazenamento pode ser compartilhado pela conta ou separado por caixa postal, mantendo o destino de backup afastado de outros consumos. Os uploads podem usar WebDAV ou a API quando esses métodos forem compatíveis. Os detalhes de montagem estão no guia de WebDAV. Também é possível compartilhar pastas com outra conta para facilitar a restauração, conforme explica o funcionamento dos links de compartilhamento. Esse recurso não substitui permissões mínimas, criptografia nem auditoria.
O princípio não é complexo: uma pasta com data, uma credencial ausente do ambiente de trabalho e uma tarefa que apenas adiciona. Os agentes tornaram essencial outra vez um conselho antigo: a cópia capaz de ajudar é aquela na qual nada do ambiente de trabalho consegue se autenticar, dentro dos limites do isolamento realmente configurado.
