pgBackRest
Backup e Ripristino Affidabile per PostgreSQL

Introduzione

pgBackRest è una soluzione affidabile di backup e ripristino per PostgreSQL che si adatta senza problemi ai database e ai carichi di lavoro più grandi.

pgBackRest v2.59.2 è l'attuale versione stabile. Le note di rilascio sono disponibili nella pagina Releases.

Se ti piace pgBackRest, lasciaci una stella su GitHub!

Novità

27 settembre 2026 - Rilasciato pgBackRest 2.59.2

17 agosto 2026 - Rilasciato pgBackRest 2.59.1

20 luglio 2026 - Nuovo tarball di distribuzione

Funzionalità

Backup e ripristino paralleli

La compressione è solitamente il collo di bottiglia durante le operazioni di backup, quindi pgBackRest risolve questo problema con l'elaborazione parallela e algoritmi di compressione più efficienti come lz4 e zstd.

Operatività locale o remota

Un protocollo personalizzato consente a pgBackRest di eseguire backup, ripristino e archiviazione in locale o in remoto tramite TLS/SSH con una configurazione minima. Viene inoltre fornita un'interfaccia per interrogare PostgreSQL tramite il livello di protocollo, in modo che l'accesso remoto a PostgreSQL non sia mai necessario, il che migliora la sicurezza.

Repository multipli

I repository multipli consentono, ad esempio, un repository locale con ritenzione minima per ripristini rapidi e un repository remoto con una ritenzione più lunga per ridondanza e accesso in tutta l'azienda.

Backup completi, differenziali e incrementali (a livello di file o di blocco)

Sono supportati backup completi, differenziali e incrementali. pgBackRest non è soggetto ai problemi di risoluzione temporale di rsync, rendendo i backup differenziali e incrementali sicuri senza la necessità di calcolare il checksum di ogni file. I backup a livello di blocco risparmiano spazio copiando solo le parti dei file che sono cambiate.

Rotazione dei backup e scadenza dell'archivio

È possibile impostare politiche di ritenzione per i backup completi e differenziali per creare copertura per qualsiasi intervallo di tempo. L'archivio WAL può essere mantenuto per tutti i backup o rigorosamente per i backup più recenti. In quest'ultimo caso, i WAL necessari per rendere coerenti i backup più vecchi verranno mantenuti nell'archivio.

Integrità dei backup

I checksum vengono calcolati per ogni file nel backup e ricontrollati durante un ripristino o una verifica. Dopo che un backup ha terminato la copia dei file, attende che ogni segmento WAL necessario per rendere il backup coerente raggiunga il repository.

I backup nel repository possono essere memorizzati nello stesso formato di un cluster PostgreSQL standard (inclusi i tablespace). Se la compressione è disabilitata e i collegamenti fisici sono abilitati, è possibile creare uno snapshot di un backup nel repository e avviare un cluster PostgreSQL direttamente sullo snapshot. Questo è vantaggioso per database su scala terabyte che richiedono molto tempo per essere ripristinati nel modo tradizionale.

Tutte le operazioni utilizzano fsync a livello di file e directory per garantire la durabilità.

Checksum delle pagine

Se i checksum delle pagine sono abilitati, pgBackRest convaliderà i checksum per ogni file copiato durante un backup. Tutti i checksum delle pagine vengono convalidati durante un backup completo e i checksum nei file che sono cambiati vengono convalidati durante i backup differenziali e incrementali.

Gli errori di convalida non interrompono il processo di backup, ma gli avvisi con i dettagli di quali pagine esattamente hanno fallito la convalida vengono inviati alla console e al log su file.

Questa funzionalità consente di rilevare precocemente la corruzione a livello di pagina, prima che scadano i backup che contengono copie valide dei dati.

Ripresa del backup

Un backup interrotto può essere ripreso dal punto in cui è stato fermato. I file già copiati vengono confrontati con i checksum nel manifest per garantirne l'integrità. Poiché questa operazione può avvenire interamente sull'host del repository, riduce il carico sull'host PostgreSQL e fa risparmiare tempo, dato che il calcolo del checksum è più veloce della compressione e della ritrasmissione dei dati.

Compressione e checksum in streaming

La compressione e il calcolo dei checksum vengono eseguiti in streaming mentre i file vengono copiati nel repository, indipendentemente dal fatto che il repository sia locale o remoto.

Se il repository si trova su un host repository, la compressione viene eseguita sull'host PostgreSQL e i file vengono trasmessi in formato compresso e semplicemente memorizzati sull'host repository. Quando la compressione è disabilitata, viene utilizzato un livello di compressione inferiore per fare un uso efficiente della larghezza di banda disponibile mantenendo il costo della CPU al minimo.

Ripristino delta

Il manifest contiene i checksum per ogni file nel backup, in modo che durante un ripristino sia possibile utilizzare questi checksum per velocizzare enormemente l'elaborazione. In un ripristino delta, qualsiasi file non presente nel backup viene prima rimosso e poi vengono generati i checksum per i file rimanenti. I file che corrispondono al backup vengono lasciati in posizione e il resto dei file viene ripristinato come al solito. L'elaborazione parallela può portare a una drastica riduzione dei tempi di ripristino.

Push e get WAL paralleli e asincroni

Sono inclusi comandi dedicati per inviare i WAL all'archivio e recuperare i WAL dall'archivio. Entrambi i comandi supportano il parallelismo per accelerare l'elaborazione e vengono eseguiti in modo asincrono per fornire il tempo di risposta più rapido possibile a PostgreSQL.

Il push WAL rileva automaticamente i segmenti WAL inviati più volte e li deduplica quando il segmento è identico, altrimenti viene generato un errore. Il push WAL asincrono consente di scaricare il trasferimento su un altro processo che comprime i segmenti WAL in parallelo per la massima velocità effettiva. Questa può essere una funzionalità critica per database con un volume di scrittura estremamente elevato.

Il get WAL asincrono mantiene una coda locale di segmenti WAL decompressi e pronti per il replay. Ciò riduce il tempo necessario per fornire i WAL a PostgreSQL, massimizzando la velocità di replay. Le connessioni e lo storage a latenza più elevata (come S3) ne traggono il maggior beneficio.

I comandi push e get garantiscono entrambi che il database e il repository corrispondano confrontando le versioni di PostgreSQL e gli identificatori di sistema. Questo elimina virtualmente la possibilità di configurare erroneamente la posizione dell'archivio WAL.

Supporto per tablespace e link

I tablespace sono completamente supportati e al momento del ripristino possono essere rimappati in qualsiasi posizione. È anche possibile rimappare tutti i tablespace in un'unica posizione con un singolo comando, il che è utile per i ripristini di sviluppo.

I link a file e directory sono supportati per qualsiasi file o directory nel cluster PostgreSQL. Al momento del ripristino è possibile ripristinare tutti i link nelle loro posizioni originali, rimappare alcuni o tutti i link, oppure ripristinare alcuni o tutti i link come normali file o directory all'interno della directory del cluster.

Supporto S3, Azure e GCS

I repository pgBackRest possono essere posizionati in object store compatibili con S3, Azure e GCS per consentire capacità e ritenzione virtualmente illimitate.

Crittografia

pgBackRest può crittografare il repository per proteggere i backup ovunque siano memorizzati.