Backup, export e data retention

Distingui subito due meccanismi che l’esame ama confondere. Gli automated scheduled backup (disponibili su Cloud SQL e AlloyDB) girano in una finestra configurabile, hanno una retention definita e vivono legati all’istanza/progetto: sono la difesa operativa quotidiana. L’export/import verso Cloud Storage (dump SQL o CSV) è invece un artefatto indipendente, utile per portabilità, migrazione cross-project o cross-region, conservazione a lungo termine oltre la finestra di retention dei backup e per test o compliance.

Regola pratica: se ti serve conservare dati oltre la retention dei backup, o spostarli fuori dall’istanza, usi un export su GCS; se ti serve ripristino rapido dell’istanza, usi backup + PITR. Un backup non è un export e viceversa.

RTO, RPO e Point-in-time recovery

RPO misura quanti dati puoi permetterti di perdere (la finestra tra l’ultimo punto ripristinabile e il guasto); RTO misura quanto a lungo puoi restare giù. Il PITR consente di ripristinare a un istante preciso ricostruendo dai binary log (MySQL) o dai WAL (PostgreSQL) a partire da un backup base: richiede che l’archiving dei log sia abilitato. Abbassa l’RPO potenziale a pochi minuti, ma il restore genera tipicamente una nuova istanza, quindi incide sull’RTO.

Tieni separati due concetti. HA = failover replica in un’altra zona della stessa region, con failover automatico dello scrittore → protegge dal guasto zonale con RTO basso. DR = backup/PITR più read replica cross-region promuovibile → protegge dal guasto regionale e, soprattutto, dalla corruzione logica o dall’errore umano. Il PITR è l’unica difesa contro un DROP TABLE sbagliato: il failover HA replicherebbe anche l’errore.

Ottimizzare costo e performance

Scale up (verticale) significa più CPU/RAM sulla stessa istanza: semplice, ma con un limite fisico e spesso un riavvio. Scale out (orizzontale) con read replica distribuisce il carico di lettura su più repliche. Punto chiave: la read replica scala le letture, non le scritture, è tipicamente asincrona (può avere replication lag) e per default non è un failover automatico dello scrittore. Se il collo di bottiglia sono le scritture o serve scala orizzontale globale con strong/external consistency, la risposta è Spanner, non l’aggiunta di read replica.

Sul fronte performance: query tuning con indici appropriati, riscrittura delle query e analisi dei piani di esecuzione. AlloyDB aggiunge un columnar engine per accelerare i workload analitici in-place, mantenendo la compatibilità PostgreSQL. Memorystore (Redis/Memcached) alleggerisce il DB primario facendo da cache in-memory sulle letture ripetute, ma non è uno store durevole. Infine il right-sizing: monitorare l’utilizzo reale per non sovradimensionare e non pagare capacità inutile.

Automazione dei task operativi

L’obiettivo è ridurre il toil. Programma backup e export schedulati, gestisci gli upgrade dei database managed dentro una maintenance window controllata, pianifica manutenzione come il rebuild degli indici, e presidia gli SLA/SLO con monitoraggio e alerting su metriche di disponibilità, lag di replica e latenza. In un ambiente managed molta automazione è nativa: sfrutta ciò che il servizio offre invece di ricostruirla.

Trappole tipiche d’esame

  • Proteggersi da una cancellazione logica errata → PITR/backup, non HA: il failover replica propaga anche l’errore; solo PITR ti riporta a un istante precedente al DROP.
  • “Serve failover automatico dello scrittore” → HA replica, non read replica: la read replica scala le letture ed è async; non promuove automaticamente un nuovo primary.
  • Conservare dati oltre la retention o per compliance → export su GCS, non backup: i backup sono legati all’istanza e alla loro finestra di retention.
  • Scalare le scritture o andare global/consistent → Spanner, non più read replica: aggiungere repliche non risolve il limite di scrittura del primary.
  • RPO vicino a zero → PITR con binary log/WAL abilitati: senza archiving dei log il PITR non è possibile e l’RPO resta pari all’ultimo backup.
  • Ridurre il costo di un’istanza sovradimensionata → right-sizing/scale up-down, cache con Memorystore: non confondere il tuning dei costi con l’aggiunta di capacità non necessaria.