Questa minor release consolida il ruolo centrale di Barman nelle installazioni di business continuity di database PostgreSQL e ora permette agli utenti di implementare i comandi per il restore remoto in parallelo su server in standby e durante la recovery.

Inoltre, attraverso il nuovo comando ‘replication-status’, Barman diventa uno strumento molto pratico per il monitoraggio della replica in streaming di ogni server che gestisce.

Sono stati implementati anche altri importanti miglioramenti e sono state effettuate alcune correzioni di bug minori. Per maggiori informazioni, leggi l’annuncio completo oltre all’articolo in inglese scritto dal nostro Gabriele ‘Waiting for Barman 1.6.1‘.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup. Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup. Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

Con la release 1.5.0, Barman è in grado di restituire, su richiesta, qualsiasi file WAL disponibile per un determinato server, consentendo, ad esempio, agli amministratori di database di integrarli nel restore_command di un qualsiasi server standby.

Questa versione introduce anche i cosiddetti “retry hook script” che consentono agli utenti di eseguire script personalizzati, prima e dopo un evento (ad esempio un backup) e assicurarsi che Barman riprovi continuamente finché la procedura non ha successo.

Un’approfondita attività di refactoring ed una maggiore attenzione ai controlli, rendono la 1.5.0 la versione più stabile e robusta di Barman.

Il nostro consiglio? Procedete con l’aggiornamento il prima possibile.

Per una lista completa delle modifiche, vi invitiamo a leggere il comunicato ufficiale in lingua inglese.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery.

Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup.

Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

Barman 1.4.0: le modifiche più importanti

L’ultima release aggiunge una nuova modalità di backup: il backup incrementale, che permette il riuso dei file non modificati fra un backup periodico e l’altro, riducendo drasticamente i tempi di esecuzione, la banda utilizzata e lo spazio occupato su disco.
Altra nuova funzionalità introdotta con la 1.4.0 è l’integrazione di Barman con la vista pg_stat_archiver, disponibile dalla versione 9.4 di PostgreSQL. Questa vista permette di raccogliere informazioni sulle performance del processo di archiviazione dei WAL e di monitorarne lo stato.
La gestione dei WAL file è migliorata. Il calcolo delle statistiche di archiviazione è stato snellito e ottimizzato. È stata potenziata la logica relativa alla rimozione dei WAL obsoleti, andando a effettuare azioni diverse nel caso di backup esclusivi o concorrenti.
I messaggi prodotti in caso di errore sono stati migliorati, rendendoli, dove possibile, più chiari e leggibili.
Abbiamo inoltre investito nella robustezza del codice: con Barman 1.4.0 disponiamo di circa 200 test di unità che vengono eseguiti ad ogni patch.

Backup Incrementale

Approfondiamo adesso la principale novità di questa release: il backup incrementale.

Definizione e teoria alla base

Per comprendere la logica su cui si basa il backup incrementale, prendiamo in considerazione due backup completi e consecutivi. Nell’intervallo di tempo che intercorre fra il completamento del primo backup e il completamento del backup successivo, non tutti i file contenuti all’interno della directory PGDATA vengono modificati. Alcuni file del backup più vecchio e del più recente, sono identici e perciò risultano ridondanti, richiedendo tempo e banda per essere trasferiti via rete e occupando spazio sul disco una volta terminata la copia. Se compariamo i file che compongono il backup più vecchio con i file che stiamo per andare a copiare dal server remoto, è possibile distinguere l’insieme di file che ha subito modifiche da quello che invece è rimasto invariato.
Con il backup incrementale diventa quindi possibile eliminarne la ridondanza, andando a copiare solamente i file modificati.

Implementazione e vantaggi tangibili

Abbiamo sviluppato questa funzionalità ponendoci tre obiettivi:

• riduzione del tempo di esecuzione di un backup;
• riduzione dell’utilizzo di banda;
• riduzione dello spazio occupato eliminando le ridondanze (deduplicazione).

Per ottenerli abbiamo sfruttato la capacità di Rsync di comparare una lista di file ricevuta da un server remoto, con il contenuto di una directory locale, identificando quali siano stati modificati o meno. Abbiamo aggiunto quindi una nuova opzione di configurazione per server/globale chiamata reuse_backup. Questa opzione identifica il tipo di backup che verrà effettuato.
Vediamo i tre possibili valori di reuse_backup e i loro effetti:

• off: valore di default, backup classico;
• copy: identifica sul server remoto l’insieme di file modificati, utilizzando l’ultimo backup eseguito come base. Solamente i file che risultano modificati vengono trasferiti via rete, diminuendo i tempi di esecuzione di un backup e risparmiando banda. Al termine del trasferimento dal backup usato come base, vengono copiati i file non modificati, ottenendo così un backup completo;
• link: identifica i file modificati e ne esegue la copia, esattamente come l’opzione copy. Al termine del trasferimento, il riuso dei file identificati come non modificati non viene ottenuto copiandoli, ma utilizzando degli hard link. In questo modo viene ottimizzato lo spazio sul disco occupato dal backup ed effettivamente si eliminano le ridondanze (deduplicazione).

È inoltre possibile utilizzare la seguente opzione --reuse-backup [{copy, link, off}] da linea di comando per modificare il comportamento di default per un singolo backup.
Per esempio:

$> barman backup --reuse-backup link main

forzerà il riuso del backup utilizzando gli hard link indipendentemente dal valore impostato all’interno del file di configurazione.
Utilizzerò adesso come “caso di studio” Navionics, uno dei nostri clienti e sponsor di questa release che, come vedremo, trae grossi vantaggi dall’utilizzo del backup incrementale. Navionics possiede database di notevoli dimensioni (uno dei più grandi arriva a circa 13 Terabyte). Prima dell’introduzione del backup incrementale, tenendo conto delle caratteristiche del server e della rete:

• sarebbero state necessarie circa 52 ore per completare un backup;
• sarebbero stati effettivamente copiati 13 TiB di dati tramite la rete;
• sarebbero stati occupati effettivamente 13 TiB sul disco.

Con Barman 1.4.0, utilizzando reuse_backup=link e facendo barman show-backup di un backup appena terminato, Navionics ottiene:

Base backup information:
  Disk usage           : 13.2 TiB (13.2 TiB with WALs)
  Incremental size     : 5.0 TiB (-62.01%)

Il tempo di esecuzione del backup è sceso drasticamente da 52 ore a 17 ore circa. I vantaggi sono quindi evidenti:

• il tempo di esecuzione diminuisce del 68% circa;
• sono stati copiati via rete solo 5.0 TiB di dati al posto di 13 TiB (-62%);
  
• lo spazio occupato sul disco è 5.0 TiB al posto di 13 TiB (-62%).

pg_stat_archiver: integrazione in Barman 1.4.0

Fra le novità introdotte da PostgreSQL 9.4 abbiamo la vista pg_stat_archiver che fornisce dati utili riguardanti lo stato di funzionamento del processo di archiviazione dei WAL. Grazie a queste statistiche è possibile inoltre fare previsioni sullo spazio che un nuovo backup andrà a occupare. Gli utenti di Barman 1.4.0 e PostgreSQL 9.4 potranno notare la comparsa di alcuni nuovi campi all’interno dell’output dei seguenti comandi:

• barman check:
  • il campo booleano is_archiving che indica lo stato del processo di archiviazione.
• barman status:
  • last_archived_time riporta l’ora di archiviazione dell’ultimo WAL file;
  • failed_count il numero di tentativi di archiviazione di WAL falliti;
  • server_archived_wals_per_hour il tasso di archiviazione di WAL/ora;
• barman show-server aggiunge all’insieme delle statistiche del server tutti i campi che compongono la vista pg_stat_archiver.

Conclusioni

Il backup incrementale, funzionalità principale di questa release, è sicuramente uno strumento di grande utilità per tutti, permettendo di salvare tempo e spazio anche su database di dimensioni modeste. Diventa invece quasi indispensabile per tutti coloro che devono amministrare database di grosse dimensioni (VLDB) o che contengono un grosso numero di tabelle in sola lettura, fornendo un notevole incremento di prestazioni in termini di spazio occupato, tempo e banda.
Aggiungendo l’integrazione con pg_stat_archiver su PostgreSQL 9.4 migliora la capacità di monitorare lo stato dei server e quindi la salute e la robustezza di tutte quelle infrastrutture che scelgono Barman come soluzione di disaster recovery di database PostgreSQL.

La novità principale di Barman 1.4.0 è il backup incrementale a livello di file, cioè un backup periodico completo che salva solo le modifiche dei dati effettuate dall’ultimo backup.

Il “data deduplication ratio” potrà facilmente raggiungere il 50-70% per ogni backup completo, portando riduzioni significative sia sui tempi di backup che sull’utilizzo dello spazio su disco.

Gli utenti di PostgreSQL 9.4 potranno inoltre beneficiare dell’integrazione di Barman con la vista pg_stat_archiver: qualsiasi problema di archiviazione continua sarà individuato immediatamente da Barman.

La gestione dei file WAL è stata migliorata ottimizzando il calcolo delle statistiche WAL, inoltre sono stati corretti alcuni bug minori.

Backup incrementale

Con backup incrementale si intende un backup periodico completo che salva solo le modifiche dei dati effettuate dall’ultimo backup.

I principali obiettivi del backup incrementale in Barman sono:

• ridurre il tempo necessario per il processo di backup;
• ridurre lo spazio su disco occupato dai diversi backup periodici (deduplicazione dei dati).

Questa caratteristica si basa molto su rysnc e hard link che devono essere pertanto supportati sia dal sistema operativo che dai file system in cui risiedono i dati di backup. Due backup periodici di base condivideranno i file che non sono stati modificati, con un risparmio rilevante dell’utilizzo del disco.

Per una lista completa delle modifiche, si consiglia la lettura del comunicato ufficiale in lingua inglese.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup.

Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

Grazie al linguaggio SQL è possibile, in ogni istante, controllare lo stato di funzionamento del processo di archiviazione dei log transazionali (WAL), componente cruciale di un sistema di disaster recovery con PostgreSQL.

Introduzione e motivazioni

Questa vista nasce dall’esigenza, emersa in questi anni, di utilizzare Barman come soluzione di disaster recovery di database PostgreSQL in ambienti in continuità operativa.

In particolare, alcune delle necessità e delle domande ricorrenti che DBA, sistemisti, CTO e CIO legittimamente ci chiedono, sono:

• Di quanto spazio disco avrò bisogno?
• Come posso tenere sotto controllo il processo di backup e di archiviazione continua?

Il punto di partenza, come è naturale che sia, è un requisito di business, che si traduce nel concetto di retention policy. Solitamente, un’azienda definisce un piano di disaster recovery all’interno di un piano di continuità operativa, dove è stabilito chiaramente il periodo di conservazione dei dati di backup. Negli stessi documenti troviamo sia il recovery point objective (RPO) che il recovery time objective (RTO), le due metriche fondamentali che misurano la quantità di dati che un’azienda può tollerare di perdere e il tempo massimo di ripristino in seguito a un disastro.
Il monitoraggio e lo studio del comportamento passato di un database sono elementi fondamentali per dimensionare, a livello di storage, una soluzione di backup.

Ad esempio, un’azienda può decidere di conservare i dati di un database PostgreSQL per un mese, in modo da ricostruire la situazione del database in maniera consistente in qualsiasi istante a partire dal primo backup a disposizione, fino all’ultimo file WAL correttamente archiviato (tramite il robustissimo meccanismo di Point-In-Time-Recovery di PostgreSQL).

La dimensione necessaria è data non solo dal numero di backup completi periodici (ad esempio uno a settimana), ma anche dal numero di file WAL archiviati, ognuno contenente le transazioni correttamente eseguite sul database in modo differenziale.

Una delle metriche necessarie è pertanto il numero di file WAL archiviati al secondo, tramite le quali è possibile stimare il numero di WAL prodotti in una settimana ed essere in grado di fare previsioni di utilizzo del disco.

A meno di non usare strumenti di campionamento e di trending (e.g. Munin), di esaminare i timestamp dei file WAL sfruttando un wal_keep_segments alto, oppure delegare questa informazione allo script personalizzato di archiviazione invocato da archive_command, fino alla versione 9.4, PostgreSQL non era in grado di fornire statistiche sul numero di file WAL archiviati, l’orario di archiviazione, l’ultimo WAL archiviato e così via. Tantomeno poteva riportare informazioni in merito al numero di file WAL per i quali l’archiviazione era fallita e l’orario di ultimo fallimento.

Sono questi i motivi per cui un anno fa ho deciso di scrivere una piccola patch per Postgres, patch che è stata poi inserita nel core all’interno della versione 9.4.

Questa patch aggiunge una statistica real-time al catalogo di PostgreSQL chiamata pg_stat_archiver.

Overview della statistica

La vista pg_stat_archiver di PostgreSQL 9.4 rende disponibile a tutti coloro che utilizzano Barman o il backup continuo classico tramite WAL file shipping, i seguenti campi:

• archived_count: numero di file WAL archiviati con successo
• last_archived_wal: nome dell’ultimo file WAL archiviato con successo
• last_archived_time: orario dell’ultima archiviazione di WAL eseguita con successo
• failed_count: numero di tentativi falliti di archiviazione di WAL
• last_failed_wal: nome dell’ultimo file WAL con tentativo di archiviazione fallito
• last_failed_time: orario dell’ultima archiviazione di WAL fallita
• stats_reset: orario di reset delle statistiche

Ecco un esempio ricavato da un database server locale, poco utilizzato:

postgres=# SELECT * FROM pg_stat_archiver;
-[ RECORD 1 ]------+-----------------------------------------
archived_count     | 17
last_archived_wal  | 00000001000000000000000B.00000028.backup
last_archived_time | 2014-12-23 08:40:17.858291+01
failed_count       | 13
last_failed_wal    | 000000010000000000000001
last_failed_time   | 2014-12-04 13:09:07.348307+01
stats_reset        | 2014-12-03 16:52:21.755025+01

Essenzialmente, una volta attivata l’archiviazione continua con archive_mode, PostgreSQL si fa responsabile che, per ogni file WAL prodotto, il comando archive_command venga eseguito con successo, riprovando all’infinito (spazio su disco permettendo) in caso di fallimento.

A differenza delle versioni precedenti, PostgreSQL 9.4 è in grado adesso di raccogliere alcune informazioni sui due principali eventi che possono verificarsi con l’archiviazione: successo e fallimento. In particolare, per entrambe le operazioni vengono resi disponibili:

• Conteggio (a partire dall’inizializzazione del cluster oppure dall’ultimo reset delle statistiche);
• WAL di riferimento dell’ultima operazione;
• Orario dell’ultima operazione.

Tra l’altro, è possibile azzerare le statistiche di archiviazione con l’istruzione:

-- Richiede privilegi superuser
SELECT pg_stat_reset_shared('archiver');

Integrazione con Barman

A partire dalla versione 1.4, Barman sfrutterà la vista pg_stat_archiver per i database PostgreSQL 9.4 in modo automatico e trasparente, riportando le informazioni di archiviazione nei classici comandi Barman di visualizzazione di un server, come status e show-server.

Inoltre, sfruttando la potenza del linguaggio SQL, è stata migliorata l’affidabilità del comando check, adesso in grado di rilevare un problema di archiviazione direttamente dalla fonte.

Esaminiamo velocemente la query introdotta in Barman:

SELECT *,
    current_setting('archive_mode')::BOOLEAN
        AND (last_failed_wal IS NULL
            OR last_failed_wal <= last_archived_wal)
        AS is_archiving,
    CAST (archived_count AS NUMERIC)
        / EXTRACT (EPOCH FROM age(now(), stats_reset))
        AS current_archived_wals_per_second
FROM pg_stat_archiver

Oltre a recuperare tutte le colonne della vista pg_stat_archiver, la query calcola al volo due campi, direttamente dalla fonte:

• is_archiving: il processo di archiviazione dei WAL è in corso oppure no?
• current_archived_wals_per_second: frequenza di WAL archiviati per secondo

Il campo is_archiving deve essere sempre TRUE, in quanto il processo di archiviazione è necessario per Barman. Pertanto, archive_mode deve essere attivo e il valore dell’ultimo WAL deve essere non definito (NULL) oppure non successivo all’ultimo WAL correttamente archiviato. Questo controllo è adesso parte integrante del comando barman check su server Postgres 9.4 (e future versioni).

Il secondo campo invece restituisce una statistica molto interessante sul workload prodotto dai server Postgres e permette pertanto di stimare lo spazio su disco richiesto per memorizzare (anche in modo compresso) giorni, settimane e mesi di file WAL (rispondendo così a una delle importanti domande iniziali).

Come controllare lo stato di funzionamento dell’archiviazione

Grazie a pg_stat_archiver, controllare lo stato di funzionamento dell’archiviazione continua dei WAL si riduce all’esecuzione di una query SQL.

È possibile impiegare la query esposta in precedenza, già utilizzata in Barman, per verificare che l’archiviazione stia procedendo con successo, integrandola nelle sonde o plugin del sistema di alerting utilizzato in azienda.

Coloro che utilizzano Barman con server PostgreSQL 9.4 e hanno già integrato barman check all’interno Nagios o Icinga, beneficeranno in modo trasparente di questa funzionalità.

Conclusioni

La vista pg_stat_archiver, nella sua semplicità, rappresenta uno strumento molto importante per coloro che considerano la disaster recovery una componente cruciale, e non periferica, di un sistema PostgreSQL in business continuity.

Anche se PostgreSQL permette di eseguire backup utilizzando la replica in streaming, l’archiviazione continua dei file WAL tramite shipping rappresenta comunque un metodo di fallback sicuro e affidabile (e comunque l’unico finora supportato da Barman). Pertanto, il corretto monitoraggio di questa componente aumenta sensibilmente la robustezza di tutta la soluzione di database Postgres.

Infine, poter disporre di statistiche circa il numero di WAL archiviati (e pertanto prodotti) da un server PostgreSQL in un periodo di riferimento, permette di conoscere con una semplice query il workload transazionale e poter fare previsioni sull’occupazione a livello di disco di una soluzione di backup.

Barman 1.3.3 è in grado di inviare alert nel caso in cui l’ultimo backup disponibile di un server sia più vecchio di un dato intervallo di tempo (ad esempio, una settimana). Inoltre, Barman può adesso riprovare automaticamente la copia dei backup in seguito a problemi temporanei come la perdita della connessione di rete. È stato poi implementato un algoritmo ottimizzato per la copia tramite rsync, al fine di migliorare le prestazioni durante le operazioni di recovery incrementale.

Le consuete attività di bug fixing e di rifattorizzazione del codice hanno fatto sì che la release 1.3.3 di Barman risulti essere la versione più stabile fra quelle disponibili e per questo vi consigliamo di effettuare l’aggiornamento delle vostre installazioni di Barman il prima possibile.

L’ultima nota di rilievo – ma non certo per importanza – è riservata agli utilizzatori che appartengono all’era giurassica di PostgreSQL 8.3 (senza offesa! ;) ): possono finalmente effettuare il backup dei loro database con Barman.

Un ringraziamento speciale per il contributo allo sviluppo di questa release va a Agile Business Group (www.agilebg.com), Jobrapido (www.jobrapido.com), Navionics (www.navionics.com) e Subito.it (www.subito.it).

Per una lista completa delle modifiche, si faccia riferimento alle note di rilascio nel comunicato ufficiale in lingua inglese. Maggiori informazioni su Barman sono disponibili sul relativo sito all’indirizzo www.pgbarman.org.

A proposito di Barman

Barman (Backup and Recovery Manager per PostgreSQL) è un software open-source scritto in Python, progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3. Consente di eseguire backup remoti su più server in ambienti business critical. Strumento di sicuro supporto ai DBA durante la fase di recupero dei dati. Tra le caratteristiche più apprezzate di Barman emergono: catalogo di backup, politiche di conservazione (retention policy), backup e recovery da remoto, archiviazione e compressione dei file WAL e dei backup.

All’interno della giornata, sarà affrontato il tema della business continuity (continuità operativa) di sistemi informativi, con particolare riferimento ad una componente fondamentale: la disaster recovery dei database. Con l’esperienza pluriennale del proprio team, 2ndQuadrant mostrerà attraverso un workshop come utilizzare Barman per questi scopi.

PostgreSQL è la soluzione di riferimento, non solo nel mondo open-source, per quanto riguarda la gestione dei dati anche in ambienti business critical.

Basti pensare che di recente il governo francese ne ha promosso l’utilizzo da parte della pubblica amministrazione e framework web come Django e Rails la adottano oramai stabilmente come soluzione di default. PostgreSQL è alla base di applicazioni Social come, ad esempio, Instagram e Runkeeper ed utilizzato da aziendi ed enti come Skype, NASA, HP, Chicago Mercantile Exchange (CME), Heroku e FAA.

PostgreSQL è distribuito in open-source con una licenza altamente permissiva che permette di abbattare i costi di proprietà totale di una soluzione per la gestione dei dati. Insomma, una scelta strategica per aziende e – soprattutto – pubblica amministrazione (specialmente in piena fase di spending review).

A tal proposito, 2ndQuadrant ha sviluppato Barman per aderire ai piani di disaster recovery definiti nel Codice dell’Amministrazione Digitale – e pertanto imposti dalla legge italiana alla pubblica amministrazione.

Per partecipare all’evento, è sufficiente registrarsi sul sito di 2ndQuadrant. Dettagli e informazioni per la registrazione sono riportate all’indirizzo: http://www.2ndquadrant.com/it/news/presentazione-barman/

La quota di partecipazione è di 99 euro + IVA, comprensiva di coffee break e pranzo.