Retenção e políticas de armazenamento

1) Princípios

1. Purpose & Minimization. Guardamos exactamente o que precisamos para o processamento.
2. Policy as Code. Retenschen é uma política executável, não PDF.
3. Defense in Depth. TTL/ILM + criptografia + auditorias + Legal Hold.
4. Reversibility & Proof. Remoção verificável: logs de ação, cripto-schredding, relatório de conformidade.
5. Cost & Carbon Aware. Retenschen leva em conta $/GB-mi e a pegada de carbono de armazenamento/egress.

2) Classificação de dados e «mapa retensivo»

• Operações (OLTP): pedidos, pagamentos, sessões.
• Analíticos (DWH/datas): eventos, factos logísticos, cortes.
• Pessoal (PII/finanças/saúde): exigem prazos e direitos especiais.
• Logs, métricas, trailers, artefactos CI.
• Documentos/mídia: WORM/arquivo/legasi.

Para cada classe, defina o proprietário, o alvo, o quadro legal, o prazo, o nível de proteção, o armazenamento atual e destino.

3) ILM: ciclo de vida dos dados

1. Ingest (hot) → NVMe/SSD, alta taxa de solicitação.

2. Warm → menos lido, compressão, formatos colinvertebrados.

3. Cold/Arquive → objeto/fita, acesso longo.

4. Purge/Delete → remoção garantida (mapas/bacapes).

yaml dataset: events_main owner: analytics purpose: "product analytics"
classification: "pseudonymized"
lifecycle:
- phase: hot; duration: 7d; storage: nvme; format: row
- phase: warm; duration: 90d; storage: ssd; format: parquet; compress: zstd
- phase: cold; duration: 365d; storage: object; glacier: true
- phase: purge; duration: 0d privacy:
pii: false dp_delete_window: 30d # SLA on personal deletions if ligaments appear

4) Políticas como código (esquetes úteis)

4. 1 Direção-política (tags obrigatória/TTL)

yaml policy: require-retention-tags deny_if_missing: [owner, purpose, classification, retention]
default_retention:
logs:  "30d"
traces: "7d"
metrics:"90d"

4. 2 Gate em CI/CD (Rego) - proibição de deploy sem retenchen

rego package policy. retention deny[msg] {
some d input. datasets[d].retention == ""
msg:= sprintf("Retention missing for dataset %s", [d])
}

4. 3 S3/objeto (fatia lifecyple)

yaml
Rules:
- ID: logs-ttl
Filter: { Prefix: "logs/" }
Transitions:
- { Days: 7, StorageClass: STANDARD_IA }
- { Days: 30, StorageClass: GLACIER }
Expiration: { Days: 180 }
NoncurrentVersionExpiration: { NoncurrentDays: 30 }

5) Retenção em fluxos e filas

• `retention. ms`/`retention. bytes '- Retenschen de janela.
• Compaction (`cleanup. policy = compact ') - Armazenando o último valor da chave.
• Tiered Armazenamento - Levamos a cauda para a tiragem fria.
• O DLQ é um retensivo separado e um TTL.

properties cleanup. policy=delete,compact retention. ms = 604800000 # 7d for tail removal
min. cleanable. dirty. ratio=0. 5 segment. ms=86400000

• Defina a retenha dos topics-chave ≈ janela de negócios de replay/recontagem.
• Para eventos billing/auditoria - Retensivo de longa duração ou WORM.

6) Bancos de dados e retensivo

• Particionamento por data/faixa, detach & drop partituras antigas.
• Campos com data - índices para consultas TTL.
• Tabelas temporais (system-versioned) + polishi purge versões antigas.

sql
-- Monthly instalments
CREATE TABLE audit_events (id bigserial, occurred_at timestamptz, payload jsonb) PARTITION BY RANGE (occurred_at);
-- Cleaning over 365 days
DELETE FROM audit_events WHERE occurred_at < now() - interval '365 days';
VACUUM (FULL, ANALYZE) audit_events;

• TTL no nível de chaves (MongoDB TTL index, Redis 'EXPIRE', Cassandra TTL).
• Downsampling para métricas (crus 7d → agregados 90d → longos 365d).
• Políticas de retenção em TSDB (Influx/ClickHouse Materialized Views com adição/agregação).

7) Logs, métricas, trailers

Logi: limitar campos, camuflar PD, TTL 7-30d, arquivo 90-180d.
Métricas: alta frequência crua - 7-14d; downsample (5m/1h) — 90–365д.
Trailers: tail-sampling e armazenamento «interessante» (erros/caudas) por mais tempo.

yaml observability:
logs:  { ttl: "30d", archive: "90d", pii_mask: true }
metrics: { raw: "14d", rollup_5m: "90d", rollup_1h: "365d" }
traces: { sample: "tail-10%", ttl: "7d", error_ttl: "30d" }

8) Remoção: tipos e garantias

Lógico (soft-delete): marca a gravação; Conveniente para recuperação, não adequado a «direito de remoção».
Física (hard-delete): Remoção real de dados/versões/réplicas.
Criptográfico (crypto-erasure): remove/substitui as chaves de criptografia e os dados não são restaurados.
Em cascata: Remoção de derivações passantes (keshi, índice, analista).

request → locate subject data (index by subject_id) → revoke tokens & unsubscribe jobs → delete in OLTP → purge caches → enqueue erasure in DWH/lakes → crypto-shred keys (per-tenant/per-dataset) → emit audit proof (receipt)

9) Direito de remoção, Legal Hold e eDiscovery

Direito de remoção/correção: SLA execução (por exemplo, ≤30 dias), ações traçadas, recibos.
Legal Hold: quando solicitada legalmente, a remoção para os conjuntos/chaves especificados será congelada; política de prioridade sobre TTL.
eDiscovery: diretório de dados, pesquisa de texto completo/atributo por artefatos, exportação em formatos alinhados.

yaml legal_hold:
dataset: payments scope: ["txn_id:123", "user:42"]
from: "2025-10-31"
until: "2026-03-31"
reason: "regulatory investigation"

10) Bacapes vs arquivos vs WORM

Bacapes - para a recuperação da perda/estrago; Retensivo curto, RTO rápido.
Arquivos - armazenamento de longo prazo para auditoria/analistas, baratos, acesso longo.
WORM - mídia de complacência imutável (finanças/relatórios); políticas «write-once, read-many».

• Não contem com o bacap como um «arquivo de séculos».
• Ensaios de recuperação (Dr. Dias), relatório de tempo e abrangência.
• Catálogo de bacapes com retenha, criptografia e chaves separados do armazém.

11) Privacidade e anonimato

Pseudônimo: vinculação PII adiada através da tabela de chaves (permite crypto-erasure por chave).
Anonimato: técnicas irreversíveis (k-anonimato, ruído, generalização); documenta o método, o risco de reidratação e o prazo de validade.

12) Monitoramento de conformidade e relatórios

Painéis de controle: proporção de datasets com retenção valida, volume em fase ILM, erros de remoção.
Alerts: excesso de destino em tiragens quentes, remoções «pendentes» que expiram Legal Hold.
Relatórios: auditoria mensal de remoção (solicitações, prazo médio, falhas), impressão de cripto-shredding.

13) Integração em processos: gates e ciúmes

Design-gate: o novo dataset não passa por um revezamento sem 'owner/purpose/retence'.
Release-gate: as migrações que aumentam o retensivo sem dono/justificativa são bloqueadas.
Costa-gate: volume em hot/warm superior ao orçamento - desencadear para o endurecimento ILM.
Segurança-gate: impede a inclusão de PD em logs/trailers sem disfarce e TTL.

14) Anti-pattern

«Guardamos tudo para sempre».
TTL severamente codificado em aplicativos que não foram incluídos em políticas.
PD em logs e trens sem disfarce/TTL/remoção.
Remoção incompleta (deixada em dinheiro/DWH/bacaps).
Falta de Legal Hold - apagar dados sob investigação.
Uma chave de encriptação compartilhada para tudo. Não se pode apagar «cripto».
«Acreditamos que foi removido», mas não há provas.

15) Folha de cheque do arquiteto

1. Cada dataset tem owner, purpose, classificação, retenção, armazenamento tier?
2. As políticas ILM/TTL são declaradas como código e aplicadas automaticamente?
3. Os PD são camuflados em logs/trailers; proibidos fora dos conjuntos brancos?
4. Existem processos de remoção pessoal (SLA, auditoria, recibos)?
5. Crypto-erasure é possível (para-tenante/para-dataset chaves, KMS/rotation)?
6. Backaps, programação, encriptação, testes de recuperação, chaves individuais?
7. Legal Hold/eDiscovery: Apoiados, prevalecendo sobre a TTL, registos de ação em curso?
8. Kafka/filas: definida por retenschen/competition/tiering, DLQ tem políticas separadas?
9. Métricas e alertas para respeitar o retenschen e quantidades com tiragens são ajustadas?
10. Revezamentos e gates no SDLC bloqueiam artefatos sem retino?

16) Mini-receitas

16. 1 ClickHouse: «cortar a cauda» acima de 180 dias

sql
ALTER TABLE events DELETE WHERE event_date < today() - 180;
OPTIMIZE TABLE events FINAL;

16. 2 Redis: TTL и lazy-purge

bash
SET session:123 value EX 3600
CONFIG SET maxmemory-policy allkeys-lru

16. 3 Tail-sampling para trilhas

yaml tail_sampling:
policies:
- name: keep-errors-and-slow latency_threshold_ms: 500 status_codes: ["5xx"]
rate_limit_per_min: 5000 default_ttl: "7d"

16. 4 Crypto-erasure (ideia)

keys:
dataset: users_pii key_id: kms://pii/users/tenant-42 erase(user_id=42):
rotate_or_destroy (key_id) # inability to restore former purge_indexes blocks ("user _ id = 42")
audit("crypto-erasure", user_id)

Conclusão

As políticas de armazenamento são o «esqueleto» da sua plataforma de dados: eles descrevem quantas classes diferentes de dados vivem, onde estão a cada momento, como ficam baratos com o tempo e quando desaparecem sem vestígios - legal, transparente e verificável. Tornem o retensivo uma política como código, conectem o ILM com segurança e custo, ativem a observabilidade e gates - e você terá um sistema que é eficiente, completo e pronto para crescer ao mesmo tempo.