Backup di Virtual Machines vs Kubernetes

Negli articoli precedenti abbiamo raccontato come siamo passati da una singola VM con Docker Compose a un cluster Kubernetes su Talos OS, e come abbiamo poi consolidato lo zoo di VM verticali in namespace dedicati. Mancava all'appello il tema più scomodo, quello di cui tutti parlano e pochi affrontano per davvero: i backup.

Spoiler: la differenza più grande tra fare backup su VM e farli su Kubernetes non sta negli strumenti, sta in come è progettato il software che ci gira sopra. Ma andiamo per gradi, di questo ne parleremo in un prossimo articolo.

Prima regola: c'è dato e dato

Questa è una posizione che teniamo a prescindere dall'orchestratore. Vale per le VM, vale per Kubernetes, vale per qualunque cosa abbiamo in produzione: i “dati” non sono tutti uguali e mettere tutto nello stesso posto è la ricetta più semplice per rendersi la vita complicata al momento del restore.

Noi distinguiamo due categorie:

1. I file binari (PDF, immagini, ecc.)

Questi vanno su uno spazio S3-compatibile dedicato, non sul filesystem dell'applicativo, e su questo punto siamo molto rigidi:

• Il bucket non è mai pubblico. L'accesso è esclusivamente via API del prodotto, mai diretto.
• L'utente finale non scarica mai un file leggendo direttamente da S3: passa sempre dall'applicativo, che valida la sua identità, controlla i permessi e — se tutto è in regola — gli serve il file (tipicamente via URL firmato a scadenza breve oppure via stream proxato).
• Le credenziali S3 sono in Secret Kubernetes (o nel secret manager equivalente nel mondo VM), mai nel codice, mai in file di configurazione versionati in chiaro.

Il motivo è tanto banale quanto importante: se un utente può scaricare un file senza passare dal vostro software, non avete più il controllo di chi accede a cosa. E quando arriva il momento dell'audit GDPR, o di rispondere a un cliente enterprise che vi chiede “dimostratemi chi ha letto questo documento”, siete nei guai.

Effetto collaterale piacevole: il filesystem dell'applicativo dimagrisce. Niente più VM da 500 GB perché “ci sono dentro gli allegati di sei anni di operatività”. L'applicativo torna ad avere le dimensioni che dovrebbe avere — qualche GB, non centinaia — e il restore in caso di disastro diventa di un ordine di grandezza più rapido.

Questo non significa che il bucket S3 non vada protetto. Va eccome. Ma il backup di un bucket è un problema che si affronta separatamente, con strumenti dedicati: a volte software di terze parti (Veeam, Restic, Kopia, soluzioni MinIO-side per ambienti compatibili), molto spesso direttamente i servizi di backup/replica che il fornitore S3 stesso mette a disposizione. Scaleway, per esempio, offre replica e versioning nativi; gli altri provider seri fanno lo stesso. La parte importante è separare la gestione del backup dei file dalla gestione del backup dell'applicazione.

2. I database

E qui veniamo all'altra metà del problema. Una volta tolti i file binari, quello che resta da preservare con cura sono i database: PostgreSQL, MySQL, MongoDB, Redis se ci tenete davvero allo stato, motori vettoriali se ne avete.

Gli approcci sono noti:

• Script bash con dump a caldo schedulati. Il classico pg_dump/mysqldump lanciato da un cron, con destinazione su storage esterno. Funziona, è solido, ha il pregio della semplicità.
• Strumenti proprietari o specifici per il motore. pgBackRest per PostgreSQL, Percona XtraBackup per MySQL, le utility ufficiali di MongoDB. Più sofisticati, gestiscono incrementali, point-in-time recovery, retention.
• Servizi gestiti dal provider, se il database è managed.

Quale scegliere dipende dalla criticità del dato, dall'RPO/RTO che vi siete dati, dalla complessità che siete disposti a sostenere. Sul dove mandare poi questi backup, sulle regole di retention, sulle implicazioni normative (GDPR, settori regolati, conservazione a norma) ci torneremo in un articolo dedicato, scritto insieme ai colleghi che si occupano specificamente di sicurezza informatica e compliance. Il tema merita più di un paragrafo buttato lì.

E adesso veniamo a Kubernetes

Con il modello sopra in mente — file su S3, database backuppati a parte — la domanda diventa: cosa serve ancora backuppare di un cluster Kubernetes?

Qui il punto più importante di tutto l'articolo:

Non bisogna fare il backup del software.

Se il software è progettato bene — e anche su questo argomento ne parleremo prossimamente — non è altro che immagini Docker versionate, con una tabella di compatibilità chiara tra le versioni dei vari componenti. L'immagine è già nel registry, è già versionata, è già riproducibile. Backupparla sarebbe come fare il backup di una libreria di un linguaggio di programmazione: insensato.

Quello che invece va backuppato è:

1. Il contenuto dei database (di cui abbiamo già parlato sopra).
2. Il contenuto del bucket S3 (idem).
3. Le configurazioni del cluster Kubernetes: namespace, Deployment, Service, Ingress, ConfigMap, Secret, PersistentVolumeClaim, Role/RoleBinding, NetworkPolicy. Tutto lo stato dichiarativo che descrive come il software gira.

Il punto 3 è quello che fa la differenza vera tra il backup di una VM e quello di Kubernetes.

VM vs Kubernetes: la differenza non è banale

Un backup di una VM è il backup di un singolo oggetto monolitico che contiene tutto: sistema operativo, applicativo, configurazione, dati. È pesante (decine o centinaia di GB anche per servizi semplici), è lento da fare e ancora più lento da ripristinare, ed è rigido: difficile estrarne solo un pezzo, difficile ripristinarlo su un'infrastruttura diversa da quella di origine.

Un backup di un namespace Kubernetes, fatto come si deve, è invece pochi MB di YAML più i dati dei database. Si fa in pochi secondi, occupa pochissimo spazio, e — questa è la parte interessante — permette potenzialmente di ripristinare l'intero namespace su un altro cluster Kubernetes in pochi minuti. Cluster diverso, provider diverso, anche distribuzione diversa di Kubernetes: se i manifest sono scritti in modo portabile, vanno.

È la differenza che passa tra trasportare una casa con tutto dentro e trasportare il progetto della casa, l'inventario dei mobili e gli indirizzi dei fornitori. Il secondo approccio è infinitamente più agile.

Il tool che abbiamo dovuto scriverci

A questo punto la domanda naturale è: con tutti gli strumenti che esistono nell'ecosistema Kubernetes, non c'era già qualcosa che facesse esattamente questo? La risposta onesta è: abbiamo cercato, abbiamo provato diverse soluzioni, e nessuna faceva esattamente quello che ci serviva, nel modo in cui ci serviva e con la semplicità operativa che pretendevamo. Né tra i prodotti commerciali, né tra l'open source.

Allora ce lo siamo scritti.

Come è fatto

Il design lo abbiamo voluto deliberatamente minimale:

• Un singolo pod autocontenuto, che si installa nel cluster con un manifest.
• Usa le API native di Kubernetes per leggere e serializzare tutte le risorse di un namespace (e dei volumi associati, quando rilevante).
• Per ogni database utilizza script specifici e parametrici: stessa interfaccia per chi lo usa, implementazione diversa sotto in base al motore (PostgreSQL, MySQL, MongoDB, eccetera). Sia per il backup che per il restore.
• Output portabile: il risultato è un archivio che contiene i manifest YAML del namespace più i dump dei database, ed è restorabile su qualunque cluster Kubernetes con il tool installato.

Niente magie, niente dipendenze esotiche, niente operatore complicato da mantenere. Un pod, le API, gli script. Semplice, pulito, efficace: le tre parole che usiamo sempre come bussola quando progettiamo strumenti interni.

Bonus: backup dell'intero cluster

C'è un'ultima funzione che abbiamo aggiunto e a cui teniamo particolarmente. Lo stesso tool può fare il backup di tutte le configurazioni di base del cluster, esclusi i namespace applicativi: ingress controller, cert-manager, storage class, configurazioni di rete, RBAC di sistema, eccetera.

Perché? Perché in scenario di disaster recovery, la cosa più rognosa non è ripristinare le applicazioni — quelle sono manifest, te le porti dove vuoi — è ricostruire il cluster sottostante esattamente com'era. Con questo backup di livello cluster, possiamo configurare un nuovo cluster Kubernetes da zero, applicare il bundle e in pochi minuti avere un ambiente operativo identico a quello perso. A quel punto, il restore dei namespace applicativi è solo un altro comando.

Per chiudere

Il salto da VM a Kubernetes ha cambiato molte cose nella nostra operatività quotidiana, ma il backup è quella dove la differenza si sente di più — e si sente in meglio. Quattro punti da portarsi a casa, se vi interessa imitare l'approccio:

Nei prossimi articoli torneremo sui temi che abbiamo accennato qui: cosa significa progettare un software perché un DevOps non impazzisca con i backup, e — insieme ai colleghi di sicurezza e compliance — dove vanno effettivamente conservati questi backup, secondo quali criteri e con quali vincoli normativi.

Luca Vitali