Políticas de Retenção

BackupAlly gerencia automaticamente a limpeza de backups antigos.

Formatos Suportados

Formato Simples

Número de dias:

retention = "7"
# Mantém backups dos últimos 7 dias

Formato Compacto

Múltiplos períodos separados por vírgula:

retention = "7d,4w,6m"
# 7 dias, 4 semanas, 6 meses

Formato Verboso

Mais legível:

retention = "daily 7, weekly 4, monthly 6"

Períodos

Período Abreviação Descrição
daily d Backups diários
weekly w Backups semanais
monthly m Backups mensais
yearly y Backups anuais

Como Funciona

Seleção de Backups

Para cada período, o BackupAlly:

  1. Daily: Mantém o backup mais recente de cada dia
  2. Weekly: Mantém o backup mais recente de cada semana (domingo)
  3. Monthly: Mantém o backup mais recente de cada mês (dia 1)
  4. Yearly: Mantém o backup mais recente de cada ano (1 de janeiro)

Exemplo Visual

Com retention = "daily 7, weekly 4, monthly 6":

Hoje: 2026-02-11

Daily (últimos 7 dias):
├── 2026-02-11 (hoje)
├── 2026-02-10
├── 2026-02-09
├── 2026-02-08
├── 2026-02-07
├── 2026-02-06
└── 2026-02-05

Weekly (últimas 4 semanas):
├── 2026-02-09 (domingo)
├── 2026-02-02 (domingo)
├── 2026-01-26 (domingo)
└── 2026-01-19 (domingo)

Monthly (últimos 6 meses):
├── 2026-02-01
├── 2026-01-01
├── 2025-12-01
├── 2025-11-01
├── 2025-10-01
└── 2025-09-01

Sobreposição

Backups podem pertencer a múltiplos períodos. Um backup de 01/01 conta como:

  • Daily (se nos últimos 7 dias)
  • Weekly (se no domingo)
  • Monthly (primeiro do mês)
  • Yearly (primeiro do ano)

Exemplos

Retenção Curta

Para dados de desenvolvimento:

retention = "daily 3"
# Apenas 3 dias

Retenção Padrão

Para a maioria dos casos:

retention = "daily 7, weekly 4, monthly 3"
# 7 dias + 4 semanas + 3 meses

Retenção Longa

Para compliance ou dados críticos:

retention = "daily 14, weekly 8, monthly 12, yearly 3"
# 14 dias + 8 semanas + 12 meses + 3 anos

Retenção Mínima

Para logs ou dados temporários:

retention = "3"
# Apenas 3 dias

Retenção Infinita

Para arquivos críticos (não recomendado):

retention = ""
# Nunca remove (use com cuidado!)

Retenção por Storage

Cada storage pode ter política diferente:

[[storage]]
id = "local-quick"
driver = "local"
path = "/backup/quick"
retention = "daily 3"

[[storage]]
id = "s3-archive"
driver = "s3"
bucket = "archive"
retention = "daily 30, weekly 12, monthly 24, yearly 5"

Execução da Limpeza

A limpeza (GC) é executada automaticamente após cada backup bem-sucedido. A partir da v0.10.0, a retenção é aplicada diretamente no storage remoto (B2, S3, Local) — o executor itera sobre cada storage configurado na task e chama gc_target, que lista os arquivos por prefixo do target, aplica a política de retenção e deleta os excedentes.

Nota: Versões anteriores a v0.10.0 tinham um bug onde a retenção era aplicada apenas em um catálogo local temporário, sem tocar nos arquivos remotos. Se você está rodando < v0.10.0, atualize para que a limpeza funcione corretamente.

Task com espaço ou pontuação no nome nunca era limpa (corrigido na 0.35.0). O GC comparava o nome cru da task com o prefixo sanitizado do arquivo no storage (espaço e pontuação viram _ na gravação) e nunca casava — toda task com esse tipo de nome (ex.: "Prova fase 1") acumulava cópia para sempre, sem aplicar retention nenhuma. A primeira execução depois do upgrade para 0.35.0 limpa o acumulado de uma vez — pode remover mais arquivos que o normal nessa run específica. Se a task tem nome com espaço/pontuação e histórico antigo, espere isso na primeira execução pós-upgrade, não é um bug novo.

A limpeza é executada:

  1. Após cada backup bem-sucedido (automático)
  2. No horário configurado (se usando scheduler)

Forçar Limpeza Manual

backupally cleanup --target mysql-prod

Ver Backups que Seriam Removidos

backupally cleanup --target mysql-prod --dry-run

Notas

  • Backups são removidos apenas se a retenção for atendida
  • Em caso de dúvida, o sistema mantém o backup
  • Logs de limpeza disponíveis em /var/log/backupally/
  • Use --dry-run para simular antes de aplicar
By Borlot.com.br on 11/02/2026