> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/retencao-de-dados.md).

# 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:

```bash
# 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](/product-docs/product-guide/configuracoes/rmm/modulos.md#lgpd) 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.