Retention e regole di storage

1) Principi

1. Purpose & Minimization. Conserviamo esattamente quanto serve agli obiettivi di lavorazione.
2. Policy as Code. Il retenschen è un criterio eseguibile, non un PDF.
3. Defense in Depth. TTL/ILM + crittografia + verifiche + Legale Hold.
4. Reversibility & Proof. Eliminazione verificabile: login di attività, crypto-shredding, report di conformità.
5. Cost & Carbon Aware. Retenschen prende in considerazione $/GB mes e l'impronta di carbonio di stoccaggio/egress.

2) Classificazione dei dati e «mappa del retenschen»

• Operazioni (OLTP): ordini, pagamenti, sessioni.
• Analitici (DWH/Data) - Eventi, loga-fatti, tagli.
• Personali (PII/finanza/salute): richiedono tempi e diritti speciali dei soggetti.
• Attrezzature tecniche, metriche, roulotte, manufatti CI.
• Documenti/media: WORM/archivio/legasi.

Per ciascuna classe, specificare il proprietario, l'obiettivo, il quadro legale, i tempi, il livello di protezione, lo storage corrente e mirato.

3) ILM: ciclo di vita dei dati

1. Ingest (hot) → NVMe/SSD, alta frequenza di richieste.

2. Warm → è meno leggibile, compressione, formati colinvertebrali.

3. Cold/Archive, oggetto/nastro, accesso lungo.

4. Purge/Delete consente l'eliminazione garantita (con repliche/backap).

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) Criteri come codice (sketch utili)

4. 1 Criterio Admision (tag obbligatori/TTL)

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

4. 2 Gate in CI/CD (Rego) - Divieto di deposito senza retenschen

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

4. 3 S3/oggetto (porzione lifecycle)

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) Retention in flussi e code

• `retention. ms`/`retention. byti'e'il retenschen delle finestre.
• Compaction (`cleanup. policy = compact ') - Memorizza l'ultimo valore della chiave.
• Tiered Storage - Trasciniamo la coda in un tir freddo.
• DLQ - Retenschen separato e TTL.

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

• Definire il retensing dei topic chiave nella finestra di lavoro della replica/ricalcolazione.
• Per gli eventi, bollo/controllo è un retenschen o WORM di lunga durata separato.

6) Database e retenschen

• Partizionamento per data/intervallo, detach & drop vecchie partiture.
• I campi data sono indici per le query TTL.
• Tabelle temporali (system-versioned) + polizze purge versioni precedenti.

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 a livello di chiavi (MongoDB TTL index, Redis 'EXPIRE', Cassandra TTL).
• Downsampling per le metriche (7d crude agregate 90d lunga 365d).
• Policy Retention in TSDB (Influx/ClickHouse Materialized Views con deducibilità/aggregazione).

7) Loghi, metriche, roulotte

Loghi: limitare i campi, mascherare il PD, TTL 7-30d, archivio 90-180d.
Metriche: ad alta frequenza cruda - 7-14d; downsample (5m/1h) — 90–365д.
Trailer: tail-sampling e conservare «interessanti» (errori/code) più a lungo.

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) Eliminazione: tipi e garanzie

Logico (soft-delete) - Segna un record; Facile da ripristinare, non compatibile con «diritto di eliminazione».
Fisico (hard-delete) - Consente di eliminare effettivamente dati/versioni/repliche.
Crittografico (crypto-erasure) - Consente di eliminare o sostituire le chiavi di crittografia e di ripristinare i dati.
A cascata: rimozione completa delle derivazioni (cache, indici, analisi).

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) Diritto di eliminazione, Legale Hold e eDiscovery

Diritto di rimozione/correzione: SLA esecuzione (ad esempio, ≤30 giorni), azioni da tracciare, ricevute.
Legale Hold: congelamento dell'eliminazione per gli insiemi/chiavi specificati; Criterio di priorità TTL.
eDiscovery: catalogo dei dati, ricerca full text/attributi per manufatti, esportazione in formati coerenti.

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

10) Backup vs archivi vs WORM

Becap - per il recupero dalla perdita/distruzione; Ritensh corto, RTO veloce.
Archivi - conservazione a lungo termine per verifiche/analisi, a basso costo, accesso a lungo termine.
WORM - supporti invariati per la compilazione (finanza/report) criteri «write-once, read-many».

• Non contate il bacap come «archivio dei secoli».
• Prove di ripristino (DR-Days), resoconto di tempo e completezza.
• Directory dei backup con ricambio, crittografia e chiavi separate dal magazzino.

11) Privacy e anonimato

Alias - Riferimento PII ritardato tramite la tabella chiavi (consente crypto-erasure per chiave).
Anonimato: tecniche irreversibili (k-anonimato, rumore, generalizzazione); documentare il metodo, il rischio di reidentizzazione e la data di scadenza.

12) Monitoraggio e reporting della conformità

Pannelli di controllo - Percentuale di dataset con retino valida, volumi per fase ILM, errori di rimozione.
Alert: eccesso di target nel tiro caldo, rimozioni in sospeso, Legali Hold in scadenza.
Report: controllo mensile dell'eliminazione (query, durata media, fallimento), crypto-schredding.

13) Integrazione nei processi: gate e gelosia

Design-gate: il nuovo dataset non viene invaso senza «owner/purpose/retenzion».
Release-gate - Le migrazioni che aumentano il retenschen senza proprietario/giustificazione vengono bloccate.
Cost-gate - Volume in hot/warm superiore al budget - trigger per la stretta ILM.
Sicurezza-gate - Impedisce l'inserimento del PD nei dischi/roulotte senza occultamento e TTL.

14) Anti-pattern

«Conservare tutto per sempre, potrebbe essere utile».
TTL rigorosamente codificati in applicazioni non inserite nei criteri.
PD in cassetti e roulotte senza occultamento/TTL/rimozione.
Rimozione incompleta (lasciata nella cache/DWH/bacap).
L'assenza di Legale Hold - cancellazione dei dati sotto indagine.
Una chiave di crittografia condivisa su tutto è impossibile cancellare la crittografia.
«Crediamo di aver eliminato», ma non ci sono prove.

15) Assegno-foglia architetto

1. Per ogni dataset sono disponibili owner, purpose, classificazione, retention, storage tier?
2. I criteri ILM/TTL sono dichiarati come codice e vengono applicati automaticamente?
3. I PD vengono mascherati in cassetti/roulotte; Vietato al di fuori dei set bianchi?
4. Ci sono processi di rimozione personale (SLA, controllo, ricevute)?
5. Crypto-erasure è possibile (per-tenante/per-dataset chiavi, KMS/rotation)?
6. Backup: pianificazione, crittografia, test di recupero, chiavi separate?
7. Legale Hold/eDiscovery: supportati, prevalenti sulla TTL, registri d'azione in corso?
8. Kafka/code - Impostato su retenschen/compettion/tiering, DLQ ha criteri separati?
9. Le metriche e gli alert per rispettare il retenschen e i volumi per tiri sono regolati?
10. La ringhiera e i gate della SDLC bloccano i manufatti senza retenschen?

16) Mini-ricette

16. 1 ClickHouse: «ritaglia la coda» oltre 180 giorni

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 per le piste

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 (idea)

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)

Conclusione

Le policy di conservazione sono lo scheletro della piattaforma di dati, che descrive quanto vivono le diverse classi di dati, dove si trovano in ogni momento, come sono a basso costo nel tempo e quando scompaiono senza lasciare traccia - legittimamente, in modo trasparente e verificabile. Rendete la retensica politica come codice, collegate l'ILM alla sicurezza e al costo, attivate l'osservabilità e i gate e ottenete un sistema che sia efficiente, complicato e pronto a crescere.