Um modelo de IA treinado representa horas de GPU, datasets curados e conhecimento proprietário da empresa. Perder esse ativo por falha de storage, erro humano ou ransomware é tão grave quanto perder um banco de dados de produção. Este guia mostra como proteger seus modelos.
O que precisa de backup em um projeto de IA
Um ambiente de IA tem múltiplas camadas de ativos — cada uma com requisitos diferentes de backup:
| Ativo | Tamanho típico | Frequência de backup | Retenção |
|---|---|---|---|
| Pesos do modelo final | 5–140 GB | Cada release | Permanente |
| LoRA adapters (fine-tuning) | 100 MB–2 GB | Cada run completo | Permanente |
| Checkpoints de treinamento | Igual ao modelo final × N | A cada N steps | Últimos 3–5 + final |
| Dataset processado | 1 GB–10 TB | Após processamento | Versão atual + anterior |
| Código de treinamento | MB | Continuous (git) | Git history completo |
| Metadados de experimento | MB–GB | Continuous (MLflow) | Permanente |
Estratégia 3-2-1 adaptada para IA
A regra 3-2-1 clássica (3 cópias, 2 mídias, 1 offsite) funciona bem para IA com algumas adaptações para o tamanho dos arquivos:
Cópia 1 — Storage de produção (rápido)
O modelo em uso fica no NVMe do servidor de inferência. Essa é a cópia “quente” — atualizada a cada novo release e acessada com frequência.
Cópia 2 — NAS local (capacidade)
Replicação automática para NAS de capacidade (SATA SSD ou HDD com RAID). Para modelos de 140 GB (Llama 70B FP16), guarde os 3 últimos releases + o checkpoint final de cada treinamento. Com 5× 140 GB = 700 GB de modelos, um NAS de 10 TB é mais que suficiente.
Cópia 3 — Offsite (segurança)
Para o offsite, backup apenas dos modelos finais (não checkpoints intermediários) e adapters LoRA. Opções:
- MinIO em segundo data center: S3-compatible, self-hosted, dados ficam no Brasil
- AWS S3 com região sa-east-1 (São Paulo): dados em solo brasileiro, compliance LGPD mais simples
- Object storage da Adentro Cloud: backup gerenciado com retenção configurável
Ferramentas: DVC, MLflow e armazenamento
DVC (Data Version Control)
DVC é o “git para dados e modelos”. Ele versiona arquivos grandes (que não cabem no git) usando o git para os metadados e um backend de armazenamento (S3, GCS, SSH, etc.) para os dados reais.
# Inicializar DVC dvc init # Adicionar modelo ao controle de versão dvc add models/llama-finetuned-v2.safetensors # Configurar storage remoto (MinIO) dvc remote add -d minio s3://ai-backup/models dvc remote modify minio endpointurl http://minio.interna:9000 # Push do modelo para o backup dvc push
MLflow para experimentos
MLflow registra automaticamente hyperparâmetros, métricas de treinamento (loss, accuracy por epoch) e artefatos (pesos do modelo) de cada run. O servidor MLflow pode ser self-hosted com PostgreSQL como backend — backup do banco + pasta de artefatos = backup completo do histórico de experimentos.
Rclone para sincronização
Para backups simples sem framework de ML, rclone sincroniza diretórios de modelos para qualquer destino S3-compatible:
# Sincronizar modelos para MinIO offsite (rodar via cron) rclone sync /modelos/ minio-backup:ai-models/prod/ --checksum --progress --log-file /var/log/model-backup.log
Gestão de checkpoints de treinamento
Checkpoints são snapshots do estado do modelo a cada N steps de treinamento. São essenciais para retomar um treinamento interrompido mas consomem storage rapidamente.
Política recomendada de checkpoints
- Salvar a cada 500–1.000 steps durante treinamento ativo
- Manter apenas os 3–5 checkpoints mais recentes em storage rápido
- Manter o melhor checkpoint por época (lowest validation loss) em storage de médio prazo
- Manter apenas o checkpoint final em backup offsite
Com HuggingFace Trainer, configure save_total_limit=3 para manter automaticamente apenas os 3 checkpoints mais recentes e deletar os anteriores.
Disaster recovery para ambientes de IA
Um plano de DR para IA precisa responder: quanto tempo levo para restaurar a capacidade de inferência se o servidor principal falhar?
RTO e RPO para modelos de IA
- RPO (perda máxima de dados): quanto do histórico de treinamento posso perder? Para a maioria das empresas, perder o checkpoint das últimas 24h é aceitável — backups diários são suficientes.
- RTO (tempo de restauração): quanto tempo para ter o modelo rodando de novo? Com hardware reserva e modelo em backup local, 2–4 horas são atingíveis. Com hardware reserva + modelo em NAS + imagem de SO pré-configurada, pode-se chegar a <1 hora.
Estratégias de DR para inferência crítica
- Servidor hot standby: segundo servidor com o mesmo modelo carregado, pronto para receber tráfego. Custo alto, RTO de segundos.
- Fallback para API externa: se o servidor local falhar, redirecionar automaticamente para OpenAI/Anthropic enquanto o servidor é restaurado. RTO de minutos, custo de API enquanto dura o downtime.
- Container pré-configurado: imagem Docker com modelo embutido ou montado via volume. Deploy em qualquer servidor disponível em 15–30 minutos.
Perguntas frequentes
Quanto espaço preciso para guardar backup de um modelo de 70B?
O modelo Llama 3 70B em FP16 ocupa ~140 GB. Em Q4 (GGUF), ~38 GB. Para backup de produção, guarde ao menos 3 versões: 3 × 140 GB = 420 GB em FP16, ou 3 × 38 GB = 114 GB em Q4. Somando dataset processado e checkpoints, planeje 1–2 TB para o conjunto completo de artefatos de um projeto com modelo de 70B.
Preciso fazer backup do dataset bruto ou só do processado?
Depende do custo de reprocessar. Se o pré-processamento leva horas (tokenização, augmentation, filtragem), faça backup do dataset processado — economiza tempo de recuperação. Se leva minutos e o dataset bruto é pequeno, guarde apenas o bruto. Para datasets de terceiros (comprados ou licenciados), sempre guarde uma cópia — você pode perder acesso à fonte original.
Ransomware pode afetar modelos de IA? Como me proteger?
Sim. Arquivos de modelo (.safetensors, .gguf, .pt) são alvos como qualquer outro dado valioso. Proteção: (1) backup offsite imutável — object storage com Object Lock ativado não pode ser deletado nem sobrescrito mesmo com credenciais comprometidas; (2) rede isolada — o servidor de GPU não deve ter acesso direto à internet; (3) snapshots do NAS com retenção de 30 dias — ransomware frequentemente permanece dormente antes de atacar; (4) monitoramento de integridade — alertas se arquivos grandes forem modificados ou deletados fora do horário de deploy.
Como versionar modelos junto com o código?
A prática recomendada é git + DVC: o código (scripts, configs, prompts de sistema) fica no git; os pesos do modelo ficam no DVC apontando para storage externo. Cada commit do git referencia uma versão específica do modelo via arquivo .dvc. Assim, qualquer commit do repositório pode ser reproduzido exatamente — código + pesos + configuração — o que é fundamental para auditoria, debugging e rollback.
