pgBackRest
Backup e Ripristino Affidabile per PostgreSQL

Introduzione

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

pgBackRest v2.59.1 è la versione stabile attuale. Le note di rilascio sono disponibili nella pagina Rilasci.

Se ti piace pgBackRest, lascia una stella su GitHub!

Novità

17 agosto 2026 - pgBackRest 2.59.1 Rilasciato

20 luglio 2026 - Nuovo Tarball di Distribuzione

20 luglio 2026 - pgBackRest 2.59.0 Rilasciato

Caratteristiche

Backup e Ripristino in Parallelo

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

Operazione 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. Un'interfaccia per interrogare PostgreSQL è inoltre fornita tramite il livello di protocollo, così che l'accesso remoto a PostgreSQL non sia mai necessario, aumentando la sicurezza.

Repository Multipli

Più repository consentono, ad esempio, un repository locale con una conservazione minima per ripristini rapidi e un repository remoto con una conservazione più lunga per la ridondanza e l'accesso a livello aziendale.

Backup Completi, Differenziali e Incrementali (a Livello di File o di Blocco)

Sono supportati i backup completi, differenziali e incrementali. pgBackRest non è soggetto ai problemi di risoluzione temporale di rsync, rendendo sicuri i backup differenziali e incrementali 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

Le policy di conservazione possono essere impostate per i backup completi e differenziali per garantire una copertura per qualsiasi periodo di tempo. L'archivio WAL può essere mantenuto per tutti i backup o solo per i backup più recenti. In quest'ultimo caso, il WAL necessario per rendere coerenti i backup più vecchi sarà mantenuto nell'archivio.

Integrità del Backup

I checksum vengono calcolati per ogni file del backup e ricontrollati durante un ripristino o una verifica. Dopo che un backup ha terminato di copiare i file, attende che ogni segmento WAL necessario a rendere coerente il backup raggiunga il repository.

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

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

Checksum di Pagina

Se i checksum di pagina sono abilitati, pgBackRest valida i checksum per ogni file copiato durante un backup. Tutti i checksum di pagina vengono validati durante un backup completo e i checksum nei file modificati vengono validati durante i backup differenziali e incrementali.

Gli errori di validazione non interrompono il processo di backup, ma vengono emessi avvisi con i dettagli esatti delle pagine che non hanno superato la validazione, sia sulla console che nel log di file.

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

Ripresa del Backup

Un backup interrotto può essere ripreso dal punto in cui era 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 dei checksum è più veloce della compressione e della ritrasmissione dei dati.

Compressione e Checksum in Streaming

I calcoli di compressione e checksum vengono eseguiti in streaming mentre i file vengono copiati nel repository, sia che il repository si trovi in locale che in remoto.

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

Ripristino Delta

Il manifest contiene i checksum per ogni file del backup, così durante un ripristino è possibile utilizzare questi checksum per accelerare enormemente l'elaborazione. In un ripristino delta, tutti i file non presenti nel backup vengono rimossi e successivamente vengono generati i checksum per i file rimanenti. I file che corrispondono al backup vengono lasciati al loro posto e i restanti file vengono ripristinati come di consueto. L'elaborazione in parallelo può ridurre drasticamente i tempi di ripristino.

Push e Get WAL Paralleli e Asincroni

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

Il push WAL rileva automaticamente i segmenti WAL inviati più volte e li de-duplica quando il segmento è identico; in caso contrario viene generato un errore. Il push WAL asincrono consente di delegare il trasferimento a un altro processo che comprime i segmenti WAL in parallelo per garantire il massimo throughput. 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. Questo riduce il tempo necessario per fornire il WAL a PostgreSQL, massimizzando la velocità di replay. Le connessioni e gli storage a latenza più elevata (come S3) ne traggono i maggiori benefici.

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

Supporto per Tablespace e Link

Le tablespace sono completamente supportate e durante il ripristino possono essere rimappate in qualunque posizione. È anche possibile rimappare tutte le tablespace in un'unica posizione con un singolo comando, utile per i ripristini di sviluppo.

I link a file e directory sono supportati per qualsiasi file o directory del cluster PostgreSQL. Durante il 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 per S3, Azure e GCS

I repository pgBackRest possono essere collocati in store di oggetti compatibili con S3, Azure e GCS, per consentire capacità e conservazione virtualmente illimitate.

Crittografia

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

Protezione da Ransomware e Malware

Quando il repository è memorizzato in uno storage di oggetti versionato, pgBackRest può leggere il repository come era in un determinato momento (point-in-time). Se i backup vengono eliminati o corrotti per errore, da malware o da ransomware, è possibile utilizzare un'ora di destinazione per recuperare i dati da prima che il danno si verificasse.

Il versioning è supportato dagli store di oggetti compatibili con S3, Azure e GCS. Il blocco degli oggetti (object locking) per S3 e l'eliminazione soft (soft delete) per GCS o Azure possono fornire una protezione aggiuntiva contro le manomissioni.

Compatibilità con Dieci Versioni di PostgreSQL

pgBackRest include il supporto per dieci versioni di PostgreSQL: le cinque versioni supportate e le ultime cinque versioni EOL. Questo lascia tutto il tempo necessario per passare a una versione supportata.

Per Iniziare

pgBackRest si impegna a essere semplice da configurare e utilizzare:

• Guide utente per vari sistemi operativi e versioni di PostgreSQL.
• Riferimento dei comandi per le operazioni da riga di comando.
• Riferimento alla configurazione per creare configurazioni pgBackRest.

Sponsor

pgBackRest non esisterebbe senza sponsorizzazioni: nuove funzionalità, correzione di bug, revisione dei contributi, supporto alla community e manutenzione richiedono tutte tempo considerevole. Ti invitiamo a prendere in considerazione una sponsorizzazione se utilizzi pgBackRest nella tua azienda.

I nostri sponsor: AWS, Supabase, pgEdge, Tiger Data, Percona, Eon, Xata, Dalibo, Data Egret.

Siamo grati ai nostri sponsor per aver investito in infrastrutture open-source che avvantaggiano l'intera community di PostgreSQL.

Sponsor passati: Crunchy Data, Resonate.

Contributi

I contributi a pgBackRest sono sempre benvenuti! Consulta le nostre Linee guida per i contributi per i dettagli su come contribuire con funzionalità, miglioramenti o segnalazioni di problemi.

Supporto

pgBackRest è completamente gratuito e open source sotto licenza MIT. Puoi utilizzarlo per scopi personali o commerciali senza alcuna restrizione. Le segnalazioni di bug vengono prese molto sul serio e saranno gestite nel più breve tempo possibile. Segnala i bug qui.

Creare una solida policy di disaster recovery con adeguate strategie di replica e backup può essere un compito molto complesso e impegnativo. Potresti aver bisogno di assistenza durante la fase di architettura e di supporto continuo per garantire che la tua azienda continui a funzionare senza intoppi.

I nostri sponsor offrono prodotti e servizi che includono il supporto per pgBackRest e possono aiutarti nelle tue esigenze di disaster recovery.