SafeGrd ripristina e verifica ogni backup PostgreSQL prima che serva

SafeGrd ripristina ogni backup di PostgreSQL su una pianificazione e conta le righe, così scopri un backup rotto prima di averne bisogno¹. Funziona con PostgreSQL 13 e successivi¹.

Il servizio prende un backup, lo ripristina più tardi in memoria o su un database usa e getta e conta ciò che torna indietro¹. L’obiettivo è verificare il contenuto del backup con un ripristino reale, non con un controllo astratto. La verifica si basa sul conteggio delle righe restituite dopo il ripristino, per confermare che il materiale salvato corrisponda a quanto atteso¹.

Il demone di SafeGrd gira su un host vicino al database e si connette con un ruolo di sola lettura¹. Su PostgreSQL 14 e successivi quel ruolo richiede solo il privilegio pg_read_all_data¹. Su PostgreSQL 13 bisogna concedere i permessi su ogni schema¹. Lo schema arriva da pg_dump¹. Le righe passano con COPY in formato binario¹. Tutto avviene in un’unica transazione¹. Questa impostazione punta a isolare ogni esecuzione, a ridurre le dipendenze esterne e a mantenere coerenza tra ciò che viene letto e ciò che viene contato.

Dopo la prima esecuzione, ogni backup carica solo ciò che è cambiato¹. Non ricarica tutto da zero a ogni ciclo. Questo riduce il lavoro necessario per mantenere la frequenza dei controlli, perché evita di trasferire dati invariati quando non serve.

La cifratura avviene prima che i dati escano dall’host¹. SafeGrd usa age per cifrare i backup in locale¹. Poi scrive i file su un bucket S3 con Object Lock attivo¹. Il bucket può essere tuo, oppure puoi usare lo storage ospitato da SafeGrd¹. I dati di backup non attraversano i server di SafeGrd¹. Il percorso del backup resta quindi tra l’host che esegue il demone e il bucket, con cifratura applicata in partenza.

Le chiavi di cifratura si possono gestire in due modi¹. Con una chiave gestita dal cliente, solo il cliente può decriptare i backup¹. Con una chiave gestita da SafeGrd, la chiave resta sigillata e viene rilasciata solo agli host iscritti, così si può ripristinare anche dopo la perdita di un host¹. La scelta del modello di gestione della chiave determina chi può accedere al contenuto cifrato e in quali condizioni operative.

L’integrazione avviene con una stringa di connessione¹. Supabase, Neon e Amazon RDS funzionano con questo metodo¹. Per Supabase c’è una nota in più: i backup vengono ripristinati su Supabase¹. Questo consente di eseguire il controllo sul ripristino anche in quel contesto, con lo stesso meccanismo basato sul conteggio delle righe.

La combinazione tra ripristino programmato, conteggio delle righe e backup cifrato prima dell’uscita dall’host mira a rendere il controllo parte del normale ciclo di salvataggio, non un passaggio separato. L’esecuzione vicino al database, l’uso di un ruolo di sola lettura e il trasferimento tramite COPY binario in una sola transazione definiscono un percorso operativo preciso, che si ripete a ogni programma scelto dall’utente¹.