PostgreSQL: `pg_dump` o `pg_basebackup` per ripristino rapido?

Quando si parla di backup e ripristino in PostgreSQL, la scelta non è quasi mai tra “un comando giusto” e “un comando sbagliato”. La vera domanda è: ti serve un ripristino selettivo e portabile, oppure un ritorno rapido e completo dell’istanza? In molti casi il confronto utile è tra `pg_dump` e `pg_basebackup`. Sono due approcci diversi, con vantaggi molto concreti, e sceglierne uno al posto dell’altro cambia tempi di restore, flessibilità, spazio occupato e capacità di recuperare da incidenti reali.

Se gestisci un sito, un e-commerce o un’app con database PostgreSQL, questa distinzione fa la differenza quando devi ripristinare un singolo schema dopo un errore umano, oppure riportare online un intero server dopo un guasto del disco. In breve: `pg_dump` è più flessibile, mentre `pg_basebackup` è più vicino a una fotografia completa del cluster. Ma la scelta giusta dipende dal contesto, non dal gusto personale.

Sintesi breve

`pg_dump` conviene quando vuoi un backup logico, portabile, leggibile e adatto a ripristini parziali. `pg_basebackup` conviene quando vuoi clonare o ricostruire rapidamente un’intera istanza PostgreSQL, soprattutto per replica, disaster recovery o failover. Se devi recuperare pochi dati o migrare tra versioni e ambienti diversi, il dump logico è spesso la scelta migliore. Se devi ripartire in fretta da un guasto grave, la copia fisica è spesso più efficace.

Cosa cambia davvero tra i due approcci

`pg_dump`: backup logico

`pg_dump` esporta database, tabelle, viste, dati e definizioni in un formato logico. Puoi ottenere un file SQL oppure un archivio personalizzato. Il vantaggio principale è la portabilità: il dump è utile per migrazioni, restore selettivi e controlli granulari. Puoi ripristinare un singolo database, una tabella, un solo schema o persino filtrare oggetti specifici a seconda del formato usato.

Questo approccio è molto comodo quando il problema è circoscritto: ad esempio una tabella corrotta, un contenuto cancellato per errore, un indice da ricreare, o la necessità di portare un database da un server vecchio a uno nuovo. In scenari così, il dump logico è più leggibile e più facile da verificare rispetto a una copia binaria dell’intero cluster.

`pg_basebackup`: backup fisico

`pg_basebackup` crea una copia fisica del cluster PostgreSQL, cioè dei file dati così come sono sul disco. È uno strumento pensato soprattutto per il backup continuo, la replica e il disaster recovery. Il vantaggio più evidente è la velocità di ripristino dell’istanza completa: se il server muore, puoi ricostruire il cluster con meno passaggi rispetto a un restore logico di grandi dimensioni.

La controparte è la minore flessibilità. Un backup fisico non è pensato per recuperare comodamente un singolo oggetto. Se devi estrarre solo una tabella, di solito ti serve un restore completo in un ambiente temporaneo, oppure devi affiancarlo a un dump logico. In più, il backup fisico richiede compatibilità più stretta tra versione, architettura e configurazione del cluster.

Quando scegliere `pg_dump`

1. Ripristino selettivo o migrazione

Scegli `pg_dump` quando il tuo obiettivo è uno di questi:

• ripristinare un solo database o uno schema;
• migrare verso un server nuovo con controllo preciso degli oggetti;
• escludere dati temporanei, tabelle di log o oggetti non necessari;
• fare un backup facile da trasportare tra ambienti diversi;
• ridurre il rischio di portarti dietro un problema strutturale del cluster originale.

È il caso tipico di hosting, ambienti condivisi, sviluppo e staging. Se devi clonare un database di un CMS o di un’app custom, il dump logico è spesso il compromesso più sicuro.

2. Verifica e audit più semplici

Un dump SQL o un archivio logico è più facile da ispezionare. Puoi verificare la presenza di schemi, statement, dati e metadati senza dover avviare subito un intero server di recupero. Questo aiuta quando vuoi controllare che il backup sia stato effettivamente generato, o quando hai bisogno di dimostrare che un oggetto esisteva in una certa forma al momento del salvataggio.

3. Database non enormi o restore non urgentissimo

Con database piccoli o medi, `pg_dump` è spesso più che sufficiente. Se il tempo di restore accettabile è di minuti o ore e non di secondi, la flessibilità del dump pesa più della rapidità del ripristino fisico.

Quando scegliere `pg_basebackup`

1. Disaster recovery e ripartenza completa

Scegli `pg_basebackup` quando vuoi tornare online il più velocemente possibile dopo un guasto serio: disco rotto, corruzione dell’istanza, server non avviabile, manutenzione aggressiva fallita. In questi casi la priorità non è estrarre un oggetto specifico, ma riportare il cluster a uno stato coerente.

È anche la scelta naturale se stai progettando una strategia di replica fisica: il backup base è la base operativa per reinizializzare un replica server o creare un nuovo nodo standby.

2. Database grandi o finestre di manutenzione strette

Su cluster molto grandi, un restore logico completo può richiedere troppo tempo, soprattutto se ci sono molte tabelle, indici e vincoli da ricreare. La copia fisica, se ben gestita, può semplificare la ricostruzione dell’istanza e ridurre il tempo totale di rientro in servizio.

3. Replica e continuità operativa

Se la tua architettura prevede replica streaming o failover, il backup fisico è molto più vicino al flusso operativo del sistema. Non sostituisce la replica, ma si integra bene con essa. In molti ambienti, il backup logico resta utile come secondo livello per esportazioni, migrazioni e recuperi selettivi, mentre `pg_basebackup` copre il piano di continuità operativa.

Confronto pratico: pro e contro

`pg_dump`

• Pro: portabile, selettivo, leggibile, adatto a migrazioni e restore parziali.
• Pro: puoi ripristinare in un database vuoto o in un ambiente diverso.
• Contro: restore più lento su database grandi.
• Contro: non è la soluzione ideale per clonare rapidamente un intero cluster in caso di guasto.

`pg_basebackup`

• Pro: adatto a ripartenza completa, replica e disaster recovery.
• Pro: riduce la complessità del restore dell’istanza.
• Contro: poca flessibilità sul recupero selettivo.
• Contro: più dipendente dalla compatibilità dell’ambiente di origine e destinazione.

Scenario 1: sito e-commerce con cancellazione accidentale

Immagina un e-commerce con PostgreSQL che perde per errore il contenuto di una tabella ordini o di una tabella clienti. Qui il vantaggio di `pg_dump` è evidente: puoi ripristinare solo il database interessato, o anche solo una parte di dati se il processo di esportazione è stato organizzato bene. La strategia è più semplice, meno invasiva e meno rischiosa per il resto dell’applicazione.

In questo caso, una copia fisica con `pg_basebackup` non è la prima scelta, perché costringerebbe a ripristinare tutto il cluster o a lavorare in un ambiente temporaneo per estrarre i dati necessari. Se il guasto è circoscritto, il backup logico è il più efficiente.

Scenario 2: server non si avvia dopo un guasto al disco

Qui il contesto cambia. Se il server PostgreSQL non parte più, il problema non è recuperare una tabella ma ricostruire il servizio. Un backup fisico con `pg_basebackup` è molto più adatto, soprattutto se hai anche WAL archiving o una replica pronta a subentrare. In questo scenario il restore deve essere rapido e coerente, non elegante.

Se il database è molto grande, reimportare tutto con `pg_dump` può diventare troppo lento. È una soluzione valida, ma solo se il tempo di ripristino è accettabile e se il dataset non è enorme. In un incidente serio di produzione, la priorità è tornare operativi.

Permessi e prerequisiti: dove si sbaglia spesso

Molti problemi di backup non dipendono dallo strumento, ma dai permessi. Con PostgreSQL bisogna distinguere bene tra accesso al database, accesso al filesystem e ruolo usato per il backup. Un errore comune è credere che avere accesso come superuser basti sempre e comunque. In realtà bisogna verificare anche configurazione, path, spazio libero e autenticazione verso il server.

Con `pg_dump`, controlla che l’utente abbia i privilegi necessari per leggere gli oggetti. Con `pg_basebackup`, verifica che il ruolo usato abbia i permessi richiesti per la copia fisica e che il server consenta la connessione di replica o backup secondo la configurazione in `pg_hba.conf`. Se questi dettagli mancano, il backup fallisce o produce un risultato incompleto.

Verifiche immediate

1. Controlla il tipo di recupero che ti serve: singolo oggetto o intero cluster. Se devi ripristinare una sola tabella, il restore fisico è quasi sempre eccessivo.
2. Verifica lo spazio disco disponibile nel target del backup e del restore: il backup fisico può richiedere molto più spazio di quanto sembri, soprattutto se non è compresso.
3. Fai un test di restore in staging: il backup non è davvero utile finché non hai provato a ripristinarlo con successo almeno una volta.
4. Controlla i log PostgreSQL e l’output del comando scelto: il successo deve essere esplicito, senza warning critici o file mancanti.

Un controllo pratico utile è confrontare dimensione, durata e tempo di restore del dump logico e della copia fisica su un ambiente non produttivo. Questo ti dà numeri reali per scegliere con criterio, non per abitudine.

Soluzione consigliata passo-passo

Approccio A: `pg_dump` per backup logico

1. Esegui il dump del database in un formato adatto al tuo restore. Se vuoi flessibilità, preferisci un formato che consenta restore parziale e compressione.
2. Salva il file in una posizione separata dall’istanza PostgreSQL, con permessi restrittivi e rotazione dei backup.
3. Prova il ripristino in un database di test o in uno schema temporaneo. L’esito atteso è la ricreazione corretta di tabelle, vincoli e dati.
4. Se il restore fallisce per oggetti già esistenti, riparti da un ambiente vuoto o usa una procedura di pulizia controllata prima di importare il dump.

Questo approccio è il più sicuro quando la priorità è la precisione del ripristino e la portabilità del file.

Approccio B: `pg_basebackup` per copia fisica

1. Prepara un’area di destinazione con spazio adeguato e controlla che il nodo sia compatibile con la versione del cluster sorgente.
2. Avvia la copia fisica e conserva anche i WAL necessari, se il tuo piano di recupero li prevede.
3. Verifica che il nuovo cluster si avvii correttamente e che i controlli di integrità basilari risultino coerenti.
4. Se il backup serve per replica o failover, prova anche il percorso di promozione o di switch del nodo secondario in un ambiente controllato.

Questo approccio è preferibile quando contano velocità di ripristino e semplicità della ricostruzione dell’istanza.

Indici, query lente e perché il backup non basta

Un errore frequente è considerare il backup come soluzione a problemi di performance. Non lo è. Se hai query lente, indici mancanti o piani di esecuzione peggiori dopo un restore, devi trattare il problema separatamente. Il ripristino logico ricrea oggetti e dati, ma non corregge automaticamente un modello dati inefficiente. La copia fisica, allo stesso modo, replica anche eventuali problemi già presenti.

Se dopo il restore noti rallentamenti, verifica statistiche, indici, vacuum, analisi e piano di esecuzione delle query più costose. In molti casi il problema non è il backup, ma il fatto che il database era già in sofferenza prima dell’incidente. Questo vale sia su PostgreSQL sia su MySQL/MariaDB, ma con PostgreSQL il controllo degli indici e delle statistiche dopo un restore è particolarmente importante.

Permessi: approccio prudente tra ruoli e accessi

Per gli ambienti di produzione, conviene applicare il principio del minor privilegio. Il ruolo usato per il backup deve avere solo i permessi necessari. In pratica, se usi un dump logico, concedi ciò che serve per leggere gli oggetti da esportare. Se usi un backup fisico, limita l’accesso alla macchina e al canale di replica a chi deve davvero operare sul cluster.

Questa distinzione è utile anche per la sicurezza operativa: un dump logico conservato male può esporre dati sensibili, mentre una copia fisica può includere tutto il cluster, compresi eventuali dati che non volevi duplicare in un ambiente secondario. Qui la scelta dello strumento influisce direttamente sulla superficie di rischio.

Come scegliere in pratica

1. Se devi migrare o recuperare selettivamente: scegli `pg_dump`.
2. Se devi ricostruire rapidamente un’istanza intera: scegli `pg_basebackup`.
3. Se hai bisogno di entrambe le cose: usa una strategia ibrida, con copia fisica per il recovery e dump logico per export e recuperi puntuali.
4. Se il database è molto grande: testa tempi di restore reali prima di decidere, perché il tempo operativo conta più della teoria.

Controlli finali / rollback

Prima di considerare concluso il piano di backup, verifica sempre questi punti: il file di backup esiste, il restore prova funziona, i log non mostrano errori e il tempo di ripristino rientra nel tuo obiettivo operativo. Se il test fallisce, il rollback più sicuro è tornare all’approccio precedente e correggere prima l’ambiente di test, non forzare il ripristino in produzione.

Se vuoi una regola semplice: `pg_dump` per flessibilità, `pg_basebackup` per ripartenza rapida. La soluzione migliore, negli ambienti seri, è spesso usarli insieme con ruoli diversi. Il primo protegge la possibilità di recuperare dati specifici; il secondo riduce il tempo di fermo quando l’istanza va ricostruita da zero.

In pratica, non scegliere lo strumento “più potente”: scegli quello che riduce davvero il tuo rischio operativo nel tipo di incidente che temi di più.

Assunzione: l’ambiente è PostgreSQL in produzione o staging con necessità di backup e restore realistici, non un laboratorio locale.