Retenção de Dados

O DataDike RMM guarda automaticamente cada coleção do tenant por um período definido — depois desse prazo, os registros expiram e são deletados sem intervenção manual. Isso mantém o storage previsível e ajuda no atendimento à LGPD (Art. 15 — princípio da necessidade / dados mantidos apenas pelo tempo necessário).

Tabela de retenção padrão

Coleção	Retenção padrão	Variável de ambiente	Motivo
-devicesLocation	90 dias	TTL_LOCATION_DAYS	Séries temporais de localização — janela suficiente para investigar incidentes recentes sem inchar o storage
-batteryHistory	180 dias	TTL_BATTERY_DAYS	Análise de degradação de bateria funciona bem com ~6 meses de histórico
-deviceDataConsumption	365 dias	TTL_DATA_USAGE_DAYS	Consumo de dados é usado em relatórios anuais / comparativos ano-a-ano
-devicesCallHistory	90 dias	TTL_CALL_HISTORY_DAYS	Metadados de chamadas (sem gravação — Google bloqueia) — janela curta por LGPD
-geofenceStatus	180 dias	TTL_GEOFENCE_DAYS	Eventos de entrada/saída — meio ano cobre investigações típicas
-alertHistory	365 dias	TTL_ALERTS_DAYS	Alertas retidos por 1 ano para relatórios de compliance
-logs	365 dias	TTL_LOGS_DAYS	Audit trail — mínimo comum de LGPD / SOC 2 para logs de ações administrativas
-broadcasts / -broadcastAcks	180 dias	TTL_BROADCASTS_DAYS	Histórico de comunicados enviados + acknowledgments
-autoRemediationsHistory	180 dias	TTL_REMEDIATIONS_DAYS	Log de ações automáticas disparadas por regras de auto-remediation

Coleções sem retenção automática

Estas coleções armazenam estado atual — não faz sentido expirar. Elas são gerenciadas pelas operações normais de CRUD (o admin apaga o que quer apagar):

• -devices — inventário de dispositivos

• -policies — políticas AMAPI

• -users — usuários administradores

• -departments, -employees, -lines, -invoices, -terms, -tags — cadastros de asset management

• -customFields — definições de campos customizados

• -permissionGroups — grupos de permissão

• -branding, -tenantSettings, -customDomain — configurações do tenant

• -costConfig — configuração de TCO

• -alertRules — regras (o histórico de disparo -alertHistory sim tem TTL)

Ajuste da retenção

Todos os TTLs são configuráveis via variáveis de ambiente. Exemplos:

# Aumentar retenção de localização para 1 ano
TTL_LOCATION_DAYS=365

# Diminuir logs para 6 meses (por política interna de dados)
TTL_LOGS_DAYS=180

# Bateria por 2 anos para análise de warranty
TTL_BATTERY_DAYS=730

A mudança tem efeito no próximo tick do enforcer (roda a cada 60 s por padrão). Documentos que já ultrapassaram o novo TTL são expirados na primeira passada — não há grace period, então cuidado ao reduzir a retenção de uma coleção grande.

Como o TTL funciona internamente

• Time-series collections (-devicesLocation, -batteryHistory, etc.) usam o mecanismo expireAfterSeconds no metaField — nativo do MongoDB time-series

• Coleções regulares com um campo timestamp ou createdAt usam um índice TTL padrão

• O enforcer roda continuamente e aplica o collMod correto em cada coleção nova que aparece no cluster (ex: quando um tenant novo é criado, os TTLs são aplicados assim que a coleção existe)

Conformidade LGPD

A tabela acima cobre o princípio da necessidade (Art. 6 III) e do livre acesso (Art. 6 IV — o titular pode ver o que tem sobre ele até o vencimento da retenção). Para eliminação antecipada (Art. 15) — quando um titular pede apagamento antes do TTL — use o módulo LGPD DSR que anonimiza / apaga registros sob demanda mantendo a integridade referencial da frota.

Backup e recuperação

Antes do TTL expirar, os documentos ficam disponíveis para backup pelo cluster MongoDB do cliente (ou do provedor de hospedagem, quando aplicável). Depois de expirados, não é possível recuperar dentro do RMM — só via restore do backup. Ajuste os TTLs alinhados com sua janela de backup / disaster recovery.