Per tredici anni, pgBackRest è stato lo standard de facto per il backup e il ripristino di PostgreSQL. Robusto, ricco di funzionalità e capace di scalare fino ai database di dimensioni enterprise, è diventato uno degli strumenti più diffusi nell’ecosistema PostgreSQL.
Tuttavia, il suo creatore e principale manutentore, David Steele, ha pubblicato un annuncio sul sito ufficiale del progetto: pgBackRest non sarà più mantenuto. La notizia ha colto di sorpresa molti anche perché il progetto, nella sua versione stabile 2.58.0, era tecnicamente ancora solido e attivo.
Steele ha spiegato le ragioni della decisione. La vendita di Crunchy Data al colosso del cloud Snowflake ha interrotto il flusso di finanziamenti che sostenevano il lavoro. Nei mesi successivi all’acquisizione, ha cercato sia una nuova collocazione lavorativa che sponsorizzazioni alternative, senza successo.
Inoltre Steele, ha indicato che eventuali fork dovranno necessariamente adottare un nome diverso e costruire la propria reputazione. Una storia che dimostra quanto l’open source, quando dipende da un singolo manutentore, resta esposto a fragilità strutturali.
pgBackRest: un’architettura pensata per non perdere nemmeno un byte
Per capire il peso della notizia, è utile sapere cosa pgBackRest ha offerto agli amministratori di database nel corso degli anni. A differenza di soluzioni più elementari, implementa backup paralleli e ripristino parallelo. Sfruttando algoritmi di compressione efficienti come lz4 e zstd, evita uno dei colli di bottiglia più comuni, ovvero la fase di compressione stessa.
Il sistema supporta backup completi, differenziali e incrementali, inclusi quelli a livello di blocco che consentono di copiare solo le porzioni modificate dei file, riducendo drasticamente lo spazio occupato nel repository. Ogni backup include il calcolo e la verifica dei checksum su ogni file. Le pagine del database vengono validate durante il processo. I problemi di corruzione emergono quindi prima che le copie valide scadano dalla retention.
Un backup interrotto può essere ripreso dal punto esatto in cui si è fermato. La gestione del WAL (Write-Ahead Log) avviene in modalità asincrona e parallela, ottimizzando sia il push verso l’archivio sia il get durante il ripristino. Questo è un dettaglio tutt’altro che secondario per database ad alto volume di scrittura.
Il tutto può essere eseguito localmente o in remoto tramite TLS o SSH, con supporto nativo a repository multipli e integrazione con storage object come S3, Azure Blob e Google Cloud Storage.
Il modello di finanziamento che non ha retto all’acquisizione
La storia di pgBackRest è anche una storia di dipendenza finanziaria da un singolo sponsor aziendale. Crunchy Data, specialista PostgreSQL di lungo corso, aveva supportato il lavoro di Steele per la maggior parte del ciclo di vita del progetto.
Questo modello, un maintainer dedicato stipendiato da un’azienda che trae vantaggio dall’ecosistema, funziona finché l’azienda esiste e mantiene le stesse priorità. Quando Snowflake ha acquisito Crunchy Data, il nuovo proprietario ha semplicemente deciso di non continuare quel finanziamento. È una decisione di portafoglio perché Snowflake ha le proprie soluzioni di data warehousing. Inoltre, non è interessato a sovvenzionare uno strumento a favore dei competitor di PostgreSQL standalone.
Steele ha tentato di trovare sponsor alternativi e una nuova posizione lavorativa che gli permettesse di dedicare tempo al progetto. Purtroppo, i ruoli specifici legati a pgBackRest si sono rivelati troppo di nicchia. Supabase, attualmente l’unico sponsor rimanente, non è sufficiente a coprire i costi. Il progetto richiede manutenzione continua, revisione delle pull request, gestione delle issue e sviluppo di nuove funzionalità.
Cosa succede adesso al backup di PostgreSQL
Con pgBackRest fuori dai giochi, chi deve scegliere uno strumento di backup per PostgreSQL deve trovare altre soluzioni. Barman, sviluppato da EnterpriseDB, è da anni una valida alternativa. Offre un set di funzionalità maturo e un team dedicato. pg_basebackup rimane l’opzione integrata per backup di base, anche se con capacità nettamente inferiori.
Steele ha lasciato aperta la porta al forking, è probabile che nel tempo emerga una versione comunitaria di pgBackRest. Tuttavia, lui stesso ha sottolineato che un fork è un progetto nuovo, con nuovi manutentori e una fiducia tutta da costruire.
La vicenda solleva la domanda: quanto è sostenibile un ecosistema open source che dipende da singoli manutentori non compensati o da sponsor aziendali che possono cambiare strategia da un giorno all’altro?
Nel frattempo, pgBackRest versione 2.58.0 continua a funzionare. Ma senza aggiornamenti di sicurezza né nuove funzionalità, il conto alla rovescia è già iniziato.
