Ridurre i costi dei backup cloud: Lifecycle-Policies, classi di storage e ottimizzazione del recupero

Chi vuole ridurre i costi dei backup cloud dovrebbe prima accettare che «backup» nel cloud non significa solo costi di storage. Nella pratica i costi si generano lungo l’intero ciclo di vita dei dati: scrittura (PUT), listing/metadata, spostamento tra classi di storage, crittografia/richieste chiave, replicazione, monitoring e, soprattutto, al momento del recupero (retrieval), inclusi eventuali costi di egress (trasferimento dei dati fuori dalla cloud). Proprio su questo intervengono le policy di ciclo di vita (regole automatizzate per il passaggio e la cancellazione degli oggetti), le classi di storage (livelli di prezzo e pRESTazioni come «Standard», «Infrequent Access», «Archive») e una pianificata ottimizzazione del recupero.

L’errore più frequente in esercizio: i backup vengono trattati come “un grande ammasso di dati”. Tutto finisce nella stessa classe, viene mantenuto per lo stesso periodo e diventa “inaspettatamente costoso” solo al momento del ripristino. Questo contributo fornisce un approccio operativo con cui i team di amministrazione possono ridurre i costi senza mettere a rischio RTO/RPO (tempo di ripresa e perdita massima di dati) e i requisiti di compliance. Il focus è su passi di verifica realizzabili, trappole tipiche, policy concrete e una strategia di fallback. Poiché il tema in molte infrastrutture è legato ai database, è inclusa una sezione dedicata ai backup MySQL e ai percorsi di ripristino.

1) Kosten entstehen nicht nur im Speicher: Das Cloud-Backup-Kostenmodell verstehen

Prima di definire regole serve un modello condiviso: quali sono i driver di costo e quando si manifestano? Per storage object-based (compatibile S3) le voci tipiche sono:

• Storage per GB/mese per classe di storage: Standard è più costosa, Archive più economica, ma con vincoli.
• Richieste (es. PUT/GET/LIST): molti file piccoli, inventari frequenti o strumenti “chatty” aumentano i costi per richieste.
• Costi di transizione del ciclo di vita: lo spostamento in altre classi non è sempre gratuito; a volte ci sono commissioni per oggetto/transizione.
• Costi di retrieval: il recupero da classi Cold/Archive può avere un costo per GB e/o requisiti di prelievo minimo per oggetto/periodo.
• Durata minima di conservazione: alcune classi applicano una retention minima; una cancellazione anticipata può generare costi residui.
• Egress/Traffico: il ripristino verso un’altra rete/on‑prem può generare egress; il ripristino nella stessa regione cloud spesso costa meno, ma non è automaticamente “gratuito”.
• Replicazione/multi-regione: la replica cross-region aumenta storage e traffico.
• Immutabilità: Object Lock/WORM (Write Once Read Many, cioè non modificabile) protegge dal ransomware, ma può impedire le operazioni di “pulizia”.

La domanda operativa centrale è: quali scenari di ripristino sono realistici – e con quale frequenza? Un backup che viene quasi mai utilizzato va gestito diversamente da uno impiegato regolarmente per test o per il recupero di singoli file. Senza questa classificazione, le transizioni del ciclo di vita portano rapidamente a „storage economico, RESTore costoso“.

2) Prerequisito: classificare dati e backup in classi (invece di trattare tutto allo stesso modo)

Le policy di ciclo di vita funzionano solo se gli oggetti sono assegnabili in modo univoco. Serve quindi una tassonomia: convenzioni di denominazione, prefissi (prefissi di percorso nel bucket) e/o tag degli oggetti. Dal punto di vista operativo i tag sono più flessibili (p.es. system, data_class, retention), i prefissi sono più semplici da visualizzare e compatibili con gli strumenti. Molti team combinano entrambe le cose: prefisso per una separazione grossolana, tag per il dettaglio.

Schema pragmatico per oggetti di backup

• Prefisso per sistema: /prod/mysql/, /prod/files/, /stage/mysql/
• Prefisso per tipo di backup: /full/, /inc/, /logs/ (p.es. Binlogs/WAL)
• Tag in base alla conservazione: retention=7d, retention=30d, retention=1y
• Tag in base alla criticità: tier=mission_critical vs. tier=standard
• Tag in base all’immutabilità: immutability=on (se viene utilizzato Object Lock)

Importante: se il vostro tool di backup esegue già la rotazione (retention nello strumento) e in aggiunta una Lifecycle-Policy cancella oggetti, dovete definire in modo univoco il „proprietario“ della logica di cancellazione. La rotazione duplicata provoca incoerenze e può innescare vincoli di conservazione minima se gli oggetti scompaiono „troppo pRESTo“.

3) Scegliere correttamente le classi di storage: i modelli di accesso determinano la scelta

Le classi di storage non sono solo „economico vs costoso“, ma combinano prezzo, latenza di accesso e costi di recupero. Per gli amministratori è utile una classificazione semplice:

• Hot (Standard): accesso rapido, adatto per backup recenti e per RESTore frequenti o test di RESTore.
• Warm (Infrequent Access / Cool): storage più economico, ma il recupero può comportare costi aggiuntivi. Adatto per backup raramente richiesti ma che devono rimanere disponibili in tempi ragionevoli in caso di incidente.
• Cold/Archive: storage molto economico, ma con ritardi di recupero (ore) e costi di retrieval. Adatto per conservazione a lungo termine, audit e casi forensi rari.

L’ottimizzazione tipica in esercizio non è „tutto in Archive“, ma una strategia a livelli: i backup nuovi RESTano per un periodo in Hot/Warm, poi migrano in Cold/Archive e vengono eliminati solo dopo la scadenza dei termini di conformità. Così riducete i costi senza penalizzare i casi di RESTore quotidiani.

Insidie: classi Archive e RTO

RTO (Recovery Time Objective) è un impegno verso l’operatività: „quanto rapidamente dobbiamo tornare operativi?“ Lo storage Archive spesso ha tempi di recupero che non sono compatibili con un RTO di 4 ore. Verificate quindi per ogni classe di sistema: quale quota dei backup può essere mandata in Archive? Per i database spesso si tratta dei „vecchi full“, non degli elementi più recenti della catena (p.es. l’ultima full più i log più recenti).

4) Lifecycle-Policies: come creare regole che funzionino nella pratica operativa

Le lifecycle policy sono regole automatizzate a livello di bucket: «dopo X giorni cambiare la classe di storage», «dopo Y giorni cancellare», «pulire i Multipart-Uploads non più necessari». È cruciale che le regole non „anticipino“ i vostri processi di backup: se un RESTore richiede una catena composta da backup completo + incrementali + log, parti di quella catena non devono essere archiviate prima delle altre se il vostro RTO non lo consente.

Componenti di regole consigliati

• Transizione in base all’età (es. 0–14 giorni Hot, 15–60 giorni Warm, da 61 giorni Archive).
• Scadenza in base alla retention (es. 90 giorni, 1 anno, 7 anni per classe di dati).
• Abort Incomplete Multipart Uploads: Previene «dati fantasma» e costi dovuti a upload interrotti.
• Noncurrent Version Expiration (con versioning): eliminare/spostare le versioni vecchie, altrimenti l’utilizzo dello storage aumenterebbe in modo incontrollato.

Esempio: S3-Lifecycle-Policy in JSON (punto di partenza operativo)

L’esempio mostra regole separate per mysql/full, mysql/logs e backup di file generici. Adattate i valori Days a RTO/RPO e requisiti di conformità e testate in un bucket separato.

{
  "Rules": [
    {
      "ID": "mysql-full-tiering",
      "Filter": { "Prefix": "prod/mysql/full/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 14, "StorageClass": "STANDARD_IA" },
        { "Days": 60, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    },
    {
      "ID": "mysql-logs-keep-hot-longer",
      "Filter": { "Prefix": "prod/mysql/logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" }
      ],
      "Expiration": { "Days": 90 }
    },
    {
      "ID": "file-backups-tiering",
      "Filter": { "Prefix": "prod/files/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 7, "StorageClass": "STANDARD_IA" },
        { "Days": 45, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 180 }
    },
    {
      "ID": "abort-incomplete-mpu",
      "Filter": {},
      "Status": "Enabled",
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Perché la separazione è importante: i log di MySQL (es. Binlogs) sono spesso piccoli ma decisivi per il Point-in-Time-Recovery (PITR, ripristino a un punto nel tempo). Se i log vengono archiviati troppo pRESTo, il tempo di RESTore aumenta in modo sproporzionato, anche se il full backup rimarrebbe rapidamente disponibile.

5) Ottimizzazione del recupero: rendere pianificabili costi e tempi del ripristino

L’ottimizzazione del recupero è la parte che molti team prendono sul serio solo dopo il primo «ripristino costoso». Si compone di tre elementi: minimizzare i casi di ripristino, ridurre l’ambito dei ripristini e scegliere percorsi di ripristino che mantengano bassi traffico e costi di recupero.

5.1 Minimizare i casi di ripristino (senza perdere sicurezza)

• Test automatizzati di ripristino con campionamento ridotto: invece di ripristinare regolarmente interi sistemi, testate i percorsi critici in modo mirato (p. es. schema + dati di riferimento + controlli di integrità). Questo riduce il volume di recupero garantendo comunque sicurezza.
• Processi self-service chiari per il «ripristino di singoli file»: molti recuperi avvengono per cancellazioni accidentali. Un processo definito evita il comportamento «ripristiniamo velocemente tutto il backup».
• Igiene dei dati: se i set di backup contengono grandi quantità di dati temporanei (cache, artefatti di build, dump non necessari), pagate due volte — su storage e in fase di ripristino.

5.2 Ridurre l’ambito del ripristino: formati di backup e dimensione degli oggetti

Le dimensioni degli oggetti hanno impatti diretti: molti oggetti piccoli aumentano i costi per richiesta, oggetti molto grandi complicano i ripristini parziali. Per i database si è spesso rivelato efficace: pochi artefatti coerenti per backup (p. es. un archivio di Full Backup più metadati/checksum di accompagnamento). Allo stesso tempo i log dovrebbero RESTare separati, perché ruotano con politiche diverse.

Un approccio pratico è conservare per ogni backup un piccolo manifest: timestamp, tipo di backup, file inclusi, checksum, oggetti dipendenti necessari (p. es. l’intervallo di log). Questo aiuta in un incidente a recuperare miratamente solo il necessario.

5.3 Ottimizzare il percorso di ripristino: “ripristino in cloud” vs. “ripristino on‑prem”

Se gestite workload in cloud, spesso è più economico e veloce eseguire prima il ripristino nella stessa regione su istanze compute e poi trasferire selettivamente i dati. Così evitate spesso picchi di traffico in uscita (egress) e riducete il tempo in cui grandi volumi vengono movimentati. Per i ripristini on‑prem (p. es. emergenza senza compute cloud) è opportuno verificare in anticipo se esistono linee dedicate, cache o percorsi di trasferimento alternativi.

6) MySQL al centro: catene di backup, PITR e insidie del ciclo di vita

Nei contesti MySQL i costi elevati di backup cloud spesso non derivano «dal database in sé», ma da conservazione prolungata dei log, backup completi pianificati in modo errato e processi di ripristino che recuperano più dati del necessario. Termini importanti qui: Full Backup (backup completo), Incremental (solo le modifiche), Binary Logs (binlog, registri delle modifiche per replica e PITR), PITR (ripristino a un punto nel tempo).

6.1 Obiettivo: Hot per la catena più recente, Warm/Cold per i dati storici

Nella pratica spesso funziona questo schema:

• Le ultime copie complete e gli incrementi più recenti rimangono Hot, perché in caso di incidente sono quelli più probabilmente necessari.
• I Binlogs rimangono Hot oder Warm a seconda dei requisiti RPO e della finestra di ripristino.
• Le copie complete più vecchie vengono spostate in Cold/Archive per conservazione a lungo termine e per audit.

Perché ciò funzioni, le lifecycle-policy devono rispettare la logica a catena: se un RESTore richiede la copia completa del giorno 10 più i Binlogs fino al giorno 12, i Binlogs non devono essere già in Archive quando l’RTO è breve.

6.2 Prüfschritt: Welche Objekte braucht ein realer MySQL-RESTore?

Redigete un semplice RESTore-runbook che elenchi esplicitamente quali artefatti sono necessari. Senza imporre dettagli interni specifici degli strumenti, la logica è sempre simile: backup completo + eventuali incrementi + Binlogs fino al punto temporale desiderato + chiavi/passphrase + checksum.

Per il funzionamento operativo è utile un controllo automatizzato “Cosa sarebbe necessario?”, che legge solo i metadati e compila i percorsi degli oggetti. Se lavorate in ambiente S3-compatibile, potete ad esempio selezionare un intervallo temporale via CLI. Esempio (sintassi AWS CLI, trasferibile ad altri provider):

#!/usr/bin/env bash
set -euo pipefail

BUCKET="s3://backup-bucket"
PREFIX="prod/mysql/logs/"
START="2026-08-01"
END="2026-08-02"

aws s3 ls "${BUCKET}/${PREFIX}" --recursive | 
  awk '{print $1" "$2" "$4}' | 
  while read -r d t key; do
    ts="${d}T${t}"
    if [[ "${ts}" >= "${START}T00:00:00" && "${ts}" <= "${END}T23:59:59" ]]; then
      echo "${key}"
    fi
  done

Perché è importante: i team di amministrazione spesso sottovalutano quanti piccoli oggetti di log si accumulano. Questo può aumentare i costi di request e retrieval durante il ripristino, anche se il volume dei dati è moderato.

6.3 Typische MySQL-Stolperfallen mit Kostenwirkung

• I Binlogs vengono mantenuti troppo a lungo: senza una chiara esigenza PITR (es. 7 giorni) i log crescono senza controllo. Questo comporta costi di storage e maggiore onere gestionale.
• Backup completi troppo frequenti senza necessità: i backup completi sono costosi in termini di spazio e trasferimento. Spesso è sufficiente un full settimanale più incrementi giornalieri (dipende dal tasso di modifica e dall’RTO).
• I test di ripristino richiedono set completi: meglio: campionamento e controlli di integrità. I ripristini completi solo in piani programmati e raramente.
• Compressione senza considerare CPU/tempo di ripristino: la compressione riduce lo spazio, ma può allungare i tempi di RESTore. I costi non sono quindi solo cloud, ma anche tempo operativo durante un incidente.

7) Checkliste: Cloud-Backup-Kostenanalyse im laufenden Betrieb

Prima di modificare le policy, create una base dati solida. La checklist che segue è volutamente agnostica rispetto agli strumenti, ma può essere implementata con la maggior parte dei report sui costi cloud e degli inventari di storage.

7.1 Inventar und Klassifizierung

• Quali bucket/container appartengono ai backup (inclusi i bucket di test „nascosti“)?
• Quali Prefixe/Tags sono già presenti? Dove mancano?
• Quanto è grave il problema del numero di oggetti (molti oggetti piccoli)?
• Il versioning è attivo? Se sì: quale è la quota di versioni non correnti?

7.2 Kosten- und Zugriffsdaten

• Quali classi di storage sono utilizzate e come è distribuito il volume?
• Qual è la media giornaliera o settimanale di GET/LIST/PUT?
• Quanto spesso si sono verificati recuperi da Cold/Archive? Per quale motivo?
• Qual è l’egress nel contesto di RESTore, test-RESTore e migrazione dei dati?

7.3 Requisiti di RESTore (RTO/RPO) e conformità

• Per sistema: RTO/RPO documentati? O aspettative implicite?
• Esistono periodi di conservazione (p.es. 1/6/10 anni) per classe di dati?
• Protezione ransomware: Object Lock/WORM o strategia air-gap presente?

8) Implementazione a fasi: modificare in sicurezza, misurare, affinare

Le modifiche a lifecycle e alle classi di storage non sempre hanno effetto immediato; alcuni processi di transizione operano in modo asincrono. Prevedete quindi fasi per controllare i rischi e misurare l’effetto.

Fase 1: „No regret“-misure

• Attivare l’annullamento dei multipart upload incompleti.
• Limitare i bucket di test (retention breve, prefissi separati).
• Disciplina per tagging/prefissi nei job di backup.
• Assegnare il responsabile della retention: lo strumento o il ciclo di vita dello storage, non entrambi senza regole chiare.

Fase 2: Tier e retention per classe di dati

• Definire per sistema un piano Hot/Warm/Cold (almeno per «critico» vs. «normale»).
• Impostare le transizioni inizialmente in modo conservativo (es. Warm solo dopo 14 giorni invece che dopo 3).
• Aggiornare il runbook di RESTore e effettuare un test di RESTore con le nuove condizioni.

Fase 3: Ottimizzazione del retrieval e percorsi di RESTore

• Archiviare manifest/metadati per ogni backup, per permettere RESTore mirati.
• Valutare l’opzione «RESTore in Cloud» (risorse di calcolo vicino allo storage) per ridurre l’egress.
• Automatizzare controlli di RESTore regolari e piccoli (es. campione settimanale).

9) Troubleshooting: quando lifecycle o cambi di classe si comportano in modo imprevisto

I malfunzionamenti tipici in produzione raramente sono „il provider cloud è rotto“; più spesso derivano da interazioni tra policy, versioning, immutability e comportamento degli strumenti.

9.1 „Perché non viene eliminato?“

• Object Lock/WORM attivo: gli oggetti immutabili non possono essere eliminati prima della scadenza della retention.
• Versioning: l’expiration può cancellare solo la versione corrente (delete marker), non i dati delle versioni precedenti se mancano regole per le versioni non correnti.
• Il filtro di policy non corrisponde: prefix/tags non combaciano; gli oggetti si trovano in un percorso diverso da quello previsto.

9.2 „Perché i costi aumentano nonostante classi di storage più economiche?“

• Più retrieval: test di RESTore o processi effettuano più spesso recuperi da Warm/Cold.
• Troppi oggetti piccoli: i costi per request dominano, specialmente per inventory/listing/RESTore di molti singoli file.
• Overhead di transizione: transizioni frequenti su molti oggetti generano costi addizionali.
• Le versioni non correnti crescono: il versioning senza pulizia è un classico fattore di costo.

9.3 „Il RESTore improvvisamente richiede troppo tempo“

• I pezzi necessari sono in archivio (latenza di retrieval).
• Manca il manifest e vengono eseguite troppe scansioni/caricamenti di oggetti.
• Il percorso di rete/egress è il collo di bottiglia; il compute per il RESTore è troppo distante dallo storage.

10) Strategia di fallback: tornare in sicurezza se un piano di tiering non è adatto

Una strategia di fallback non è un «rollback con un clic», perché i cambi di classe di storage e le expiration possono essere operazioni irreversibili (i dati cancellati sono perduti; il retrieval dagli archivi richiede tempo). Pianificate quindi in anticipo:

• Rendere le modifiche alle policy disattivabili inizialmente: nuove regole con ID univoca, filtri chiari e nella prima settimana soglie conservative.
• Protezione contro la cancellazione prematura: attivare la scadenza solo dopo che transizione e ripristino sono stati verificati. In alternativa: inizialmente solo transizioni, nessuna cancellazione.
• Prova di ripristino prima della retention rigorosa: un ripristino completo di un sistema rappresentativo nelle nuove condizioni di classe (incluso PITR bei MySQL, se richiesto).
• Processo break-glass: chi è autorizzato, in caso di incidente, ad avviare una più ampia azione di retrieval? Come viene autorizzata e documentata (FinOps/Change-Management)?

Se constatate che gli archivi compromettono l’RTO: riportate gli elementi più recenti della catena in Hot/Warm, ma fatelo in modo mirato. Un generico «riporta tutto» può diventare costoso e spesso è inutile.

11) Buone pratiche che funzionano in ambienti misti

Per concludere alcuni modelli che aiutano particolarmente in scenari eterogenei (On-Prem + Cloud, più team, diversi strumenti di backup):

• Separare gli obiettivi di backup e di ripristino: lo storage di backup non è automaticamente un buon ambiente di lavoro per il ripristino. Pianificate percorsi di compute/rete per i ripristini.
• Un „catalogo di backup“ fa risparmiare: un registro centrale e compatto dei metadati (manifest) riduce le operazioni di ricerca e di listing e previene ripristini errati.
• Le policy fanno parte dell’architettura: il lifecycle, come il monitoraggio e la gestione delle chiavi, deve essere documentato nelle procedure operative e incluso nel change management.
• Testate il percorso costoso: non solo «riesco a leggere?», ma «quanto tempo richiede il recupero dagli archivi e quanto costa?» – altrimenti, in caso di incidente vi mancheranno trasparenza sui tempi e sul budget.

Conclusione: Ridurre i costi dei backup cloud senza sabotare il ripristino

I backup cloud diventano costosi quando classi di storage, retention e processi di ripristino non sono pensati insieme. Con una classificazione dei dati chiara, lifecycle policy introdotte con prudenza e un’ottimizzazione mirata del retrieval è possibile ridurre i costi operativi senza mettere a rischio la ripristinabilità. È fondamentale usare RTO/RPO come limiti tecnici: la classe di storage più economica è inutile se il recupero in caso serio richiede ore o se l’esplosione dei costi si manifesta solo al momento del ripristino. Chi testa il percorso di ripristino, mantiene i dati del manifest e tiene consapevolmente „hot“ le catene (in particolare per MySQL con PITR), ottiene backup pianificabili – e costi pianificabili.

Per questo tema sono importanti anche gli S3 Lifecycle. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.