Lo stato attuale della gestione del backup open source per PostgreSQL

Esistono molti modi per affrontare l'esecuzione di backup di un cluster PostgreSQL. Ci sono diversi articoli e blog che presentano le varie tecnologie con cui possiamo salvare i nostri preziosi dati in PostgreSQL. Esistono soluzioni di backup logico, backup fisico a livello di sistema operativo, a livello di filesystem e così via. Qui in questo blog non tratteremo la parte teorica che è adeguatamente trattata da vari blog e articoli, nonché dalla documentazione ufficiale.

Questo blog si concentra sullo stato dei vari strumenti e soluzioni disponibili e si sforza di presentare un confronto approfondito basato su esperienze di vita reale. Questo articolo non cerca in alcun modo di promuovere un prodotto specifico, mi piacciono molto tutti gli strumenti, le soluzioni e le tecnologie descritte in questo blog. L'obiettivo qui è annotare i loro punti di forza, i loro punti deboli e guidare l'utente finale su quale strumento si adatta meglio al suo ambiente, infrastruttura e requisiti specifici. Ecco un bell'articolo che descrive gli strumenti di backup per PostgreSQL a vari livelli.

Non descriverò come utilizzare i vari strumenti in questo blog, poiché queste informazioni sono documentate nel blog sopra e anche nei documenti ufficiali e in altre risorse in rete. Ma descriverò i pro e i contro come li ho sperimentati nella pratica. In questo blog, ci occupiamo esclusivamente dei classici backup PostgreSQL fisici basati su PITR che dipendono da:

• pg_basebackup o pg_start_backup()/pg_stop_backup
• copia fisica
• archiviazione di WAL o replica in streaming

Esistono diversi prodotti e soluzioni eccellenti, alcuni sono open source e gratuiti da usare mentre altri sono commerciali. Per quanto ne so, quelli sono:

• pgbarman di 2ndquadrant (gratuito)
• pgbackrest (gratuito)
• pg_probackup di Postgres Professional (gratuito)
• BART di EDB (commerciale)

Non ho avuto la possibilità di provare BART poiché funziona su versioni di Linux che non uso. In questo blog, includerò i miei pensieri e le mie impressioni mentre interagisco con i rispettivi autori/comunità/mantenitori di ciascuna soluzione poiché questo è un aspetto molto importante che di solito viene sottovalutato all'inizio. Un po' di terminologia per comprendere meglio i vari termini in ciascuno degli strumenti:

pgbarman

Pgbarman o semplicemente barman è il più antico di quegli strumenti. L'ultima versione è la 2.6 (rilasciata mentre avevo questo blog in lavorazione! che è un'ottima notizia).

Pgbarman supporta il backup di base tramite due metodi:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

e trasferimento WAL tramite:

• Archiviazione WAL
  • tramite rsync
  • via barman-wal-archive / put-wal
• WAL tramite replica in streaming con slot di replica
  • Asincrono
  • Sincrono

Questo ci dà 8 combinazioni predefinite con le quali possiamo usare barman. Ognuno ha i suoi pro e contro.

Backup di base tramite pg_basebackup (backup_method =postgres)

Pro:

• il modo più nuovo/moderno
• si basa sulla collaudata tecnologia PostgreSQL di base
• consigliato dai documenti ufficiali

Contro:

• nessun backup incrementale
• nessun backup parallelo
• nessuna compressione di rete
• nessuna deduplicazione dei dati
• nessun limite di larghezza di banda di rete

Backup di base tramite rsync (backup_method =rsync)

Pro:

• vecchi e collaudati
• Backup incrementale
• Deduplicazione dei dati
• compressione di rete
• backup parallelo
• limite della larghezza di banda della rete

Contro:

• modo non consigliato (dagli autori)

Trasferimento WAL tramite archiviazione WAL (tramite rsync)

Pro:

• più semplice da configurare

Contro:

• Nessun RPO=0 (zero perdita di dati)
• nessun modo per recuperare da guasti di rete lunghi e persistenti

Trasferimento WAL tramite archiviazione WAL (tramite barman-wal-archive / put-wal)

Pro:

• il modo più recente e consigliato (introdotto in 2.6)
• più affidabile/sicuro di rsync

Contro:

• Nessun RPO=0 (zero perdita di dati)
• Non c'è ancora modo di riprendersi da guasti di rete lunghi e persistenti

Trasferimento WAL tramite streaming WAL con slot di replica (tramite pg_receivewal)

Pro:

• più moderno (e consigliato)
• RPO=0 (perdita di dati zero) in modalità sincrona

Contro:

• sempre associato allo slot di replica. Potrebbe crescere in caso di guasti alla rete

Quindi, mentre pg_basebackup (metodo postgres) sembra il futuro per pgbarman, in realtà, tutte le funzionalità fantasiose vengono fornite con il metodo rsync. Elenchiamo quindi tutte le caratteristiche di Barman in modo più dettagliato:

• Operazione remota (backup/ripristino)
• Backup incrementali. Una delle grandi caratteristiche di barman, i backup incrementali si basano sul confronto a livello di file dei file del database con quelli dell'ultimo backup nel catalogo. In barman il termine "differenziale" si riferisce a un concetto diverso:secondo la terminologia del barman, un backup differenziale è l'ultimo backup + le singole modifiche rispetto all'ultimo backup. I documenti di Barman affermano che forniscono backup differenziali tramite WAL. I backup incrementali di Barman funzionano a livello di file, il che significa che se un file viene modificato l'intero file viene trasferito. È come pgbackrest ea differenza di altre offerte come pg_probackup o BART che supportano backup differenziali/incrementali a livello di blocco. I backup incrementali di Barman sono specificati tramite:reuse_backup =link o copia. Definendo "copia" otteniamo tempi ridotti del backup poiché solo i file modificati vengono trasferiti e sottoposti a backup, ma nessuna riduzione di spazio poiché i file non modificati vengono copiati dal backup precedente. Definendo "link" i file non modificati vengono hard linkati (non copiati) dall'ultimo backup. In questo modo otteniamo sia la riduzione del tempo che la riduzione dello spazio. Non voglio in alcun modo creare più confusione in questo, ma in realtà i backup incrementali di barman sono direttamente paragonabili ai backup incrementali di pgbackrest, poiché barman tratta (tramite link o copia) un backup incrementale effettivamente come un backup completo. Quindi, in entrambi i sistemi, un backup incrementale si occupa dei file che sono stati modificati dall'ultimo backup. Tuttavia, per quanto riguarda i backup differenziali, significa una cosa diversa in ciascuno dei suddetti sistemi, come vedremo di seguito.
• Backup dalla modalità standby. Barman offre la possibilità di eseguire la maggior parte delle operazioni di backup di base da uno standby, liberando così il primario dal carico di I/O aggiunto. Tuttavia, si noti che ancora i WAL devono provenire dal primario. Non importa se utilizzi lo streaming archive_command o WAL tramite slot di replica, non puoi ancora (al momento della stesura di questo articolo con barman nella versione 2.6) scaricare questa attività in standby.
• Lavori paralleli per il backup e il ripristino
• Un set completo e completo di impostazioni di conservazione basate su:
  • Ridondanza (numero di backup da conservare)
  • Finestra di ripristino (come in passato dovrebbero essere conservati i backup)
  Secondo me dal punto di vista dell'utente, quanto sopra è fantastico. L'utente può definire reuse_backup =link e una finestra di ripristino e lasciare che barman (il suo lavoro cron) si occupi del resto. Nessun backup diff/incr/completo ecc. di cui preoccuparsi o pianificare o gestire. Il sistema (barman) fa la cosa giusta in modo trasparente.
• Programmazione di script hook pre/post evento.
• Rimappatura tablespace

Questi sono i migliori punti di forza del barman. E davvero questo è quasi più di quanto il DBA medio chiederebbe a uno strumento di backup e ripristino. Tuttavia, ci sono alcuni punti che potrebbero essere migliori:

• La mailing list non è così attiva ei manutentori scrivono o rispondono raramente alle domande
• Nessuna funzione per riprendere un backup non riuscito/interrotto
• Gli slot di replica o l'uso di rsync/barman-wal-archive per l'archiviazione non perdonano in caso di guasto della rete o altri guasti del sito di backup. In entrambi i casi, se l'interruzione della rete è abbastanza lunga e le modifiche nel DB valgono molti file WAL, il primario soffrirà di "nessuno spazio rimasto sul dispositivo" e alla fine andrà in crash. (non è una buona cosa). Ciò che è promettente qui è che barman ora fornisce un modo alternativo (a rsync) per trasferire i WAL in modo che una protezione aggiuntiva contro ad es. pg_wal l'esaurimento dello spazio potrebbe essere implementato in futuro, il che, insieme al curriculum di backup, renderebbe davvero il barman perfetto, almeno per me.

pgschienale

Pgbackrest è la tendenza attuale tra gli strumenti di backup open source, principalmente per la sua efficienza nel far fronte a volumi di dati molto grandi e per l'estrema cura che i suoi creatori ripongono nella convalida dei backup tramite checksum. Al momento della stesura di questo articolo è sulla versione v2.09 e i documenti si trovano qui. La Guida per l'utente potrebbe essere leggermente obsoleta, ma il resto dei documenti è molto aggiornato e accurato. Pgbackrest si basa sull'archiviazione WAL utilizzando il proprio archive_command e il proprio meccanismo di trasferimento file che è migliore e più sicuro di rsync. Quindi pgbackrest è piuttosto avanzato poiché non offre la serie più ampia di scelte fornite dal barman. Poiché non è coinvolta la modalità sincrona, naturalmente pgbackrest non garantisce RPO=0 (zero perdita di dati). Descriviamo i concetti di pgbackrest:

• Un backup può essere:
  • Completo. Un backup completo copia l'intero cluster di database.
  • Differenziale (differenza). Un backup differenziale copia solo i file che sono stati modificati dall'ultimo backup completo. Per un ripristino riuscito, sia il backup differenziale che il backup completo precedente devono essere validi.
  • Incrementale (incr). Un backup incrementale copia solo i file che sono stati modificati dall'ultimo backup (che può essere un backup completo, differenziale o anche incrementale). Analogamente al backup differenziale, per eseguire un ripristino con successo, tutti i backup richiesti precedenti (incluso questo backup, l'ultimo diff e il precedente completo) devono essere validi.
• Una stanza è la definizione di tutti i parametri richiesti di un cluster PostgreSQL. Un server PostgreSQL normale ha la propria stanza, mentre i server di backup avranno una stanza per ogni cluster PostgreSQL di cui eseguono il backup.
• Una configurazione è dove vengono conservate le informazioni sulle stanze (di solito /etc/pgbackrest.conf)
• Un repository è il luogo in cui pgbackrest conserva WAL e backup

L'utente è incoraggiato a seguire la documentazione come suggerisce la documentazione stessa, dall'alto verso il basso. Le caratteristiche più importanti di pgbackrest sono:

• Backup e ripristino in parallelo
• Non è necessario l'accesso SQL diretto al server PostgreSQL
• Funzionamento locale/remoto
• Conservazione basata su:
  • conservazione completa dei backup (numero di backup completi da conservare)
  • conservazione dei backup delle differenze (numero di backup delle differenze da conservare)
  I backup incrementali non hanno una propria conservazione e scadono non appena scade un backup precedente. In questo modo l'utente può definire una pianificazione per l'esecuzione di backup completi e una serie di backup differenziati in sequenza.
• Backup dalla modalità standby. Alcuni file devono ancora provenire dal principale, ma la copia di massa viene eseguita in standby. Tuttavia, i WAL devono provenire dal primario.
• Integrità del backup. Le persone dietro pgbackrest sono estremamente attente quando si tratta dell'integrità dei backup. Ogni file viene sommato al momento del backup e viene anche controllato dopo il ripristino per assicurarsi che nessun errore hardware o software problematico possa causare un ripristino errato. Inoltre, se i checksum a livello di pagina sono abilitati nel cluster PostgreSQL, vengono calcolati anche per ogni file. Inoltre, vengono calcolati i checksum per ogni file WAL.
• Se la compressione è disabilitata e gli hard link sono abilitati è possibile richiamare il cluster direttamente dal catalogo. Questo è estremamente importante per database di grandi dimensioni con più TB.
• Ripresa di un back fallito/interrotto. Molto utile in caso di reti inaffidabili.
• Ripristino Delta:ripristino ultra veloce per database di grandi dimensioni, senza pulire l'intero cluster.
• Push WAL asincrono e parallelo al server di backup. Questo è uno dei punti di forza di pgbackrest. L'archiviatore PostgreSQL copia nello spool solo tramite archive-push e il lavoro pesante del trasferimento e dell'elaborazione avviene in un processo pgbackrest separato. Ciò consente massicci trasferimenti WAL garantendo al contempo bassi tempi di risposta PostgreSQL.
• Rimappatura tablespace
• Supporto per Amazon S3
• Supporto per la dimensione massima della coda WAL. Quando il sito di backup è inattivo o la rete non funziona, l'utilizzo di questa opzione deriderà come se l'archiviazione fosse andata a buon fine, consentendo a PostgreSQL di eliminare WAL impedendo il riempimento di pg_wal, e quindi salvando il server pgsql da un potenziale PANIC.

Quindi pgbackrest dal punto di vista delle funzionalità pone molta enfasi quando si tratta di convalida e prestazioni dei dati, non sorprende che sia utilizzato dalle installazioni PostgreSQL più grandi e trafficate. Tuttavia, c'è una cosa che potrebbe essere migliorata:

• Sarebbe davvero utile avere un'opzione più "liberale" per quanto riguarda la conservazione, ovvero fornire un modo per specificare in modo dichiarativo un periodo di conservazione e quindi lasciare che pgbackrest gestisca i backup completi/diff/incr secondo necessità.

pg_probackup

Pg_proback è un altro strumento promettente per i backup. È originariamente basato su pg_arman. La sua enfasi è sulle prestazioni del backup. Si basa su cataloghi e istanze, molto simili al resto degli strumenti, quindi abbiamo. Le sue caratteristiche principali includono:

• Supporto avanzato a livello di backup che va da:
  • Backup completi
  • Incrementale di tre tipi:
    • Backup della PAGINA. Cambiamenti di livello rilevati tramite la scansione WAL. Richiede l'accesso completo alla sequenza WAL ininterrotta dal backup precedente.
    • Backup DELTA. Solo le pagine modificate vengono copiate nel backup. Indipendente dall'archiviazione WAL, carica un certo carico sul server.
    • Backup PTRACK. Richiede una speciale patch per il core pgsql. Funziona mantenendo una bitmap al volo non appena le pagine vengono modificate. Backup davvero veloce con carico minimo sul server.
• I backup possono anche essere suddivisi in:
  • Backup autonomi. Quelli non hanno requisiti su WAL al di fuori del backup. Nessun PITR.
  • Backup dell'archivio. Quelli si basano sull'archiviazione continua e supportano PITR.
• Modello multithread (in contrasto con barman, pgbackrest e ovviamente PostgreSQL stesso che seguono un modello multiprocesso)
• Coerenza dei dati e convalida su richiesta senza ripristino
• Backup da uno standby senza accesso al primario.
• Una specifica della politica di conservazione espressiva in cui la ridondanza può essere utilizzata in modo AND insieme alla finestra. L'unione dei backup (tramite unione) è supportata convertendo i backup incrementali precedenti in full come un modo per liberare spazio e per fornire un metodo per una rotazione fluida dei backup.

Quindi, pg_probackup fornisce una serie di fantastiche funzionalità con enfasi sulle prestazioni, qualcosa che andrebbe a vantaggio di installazioni di grandi dimensioni. Tuttavia, mancano ancora alcune cose, vale a dire:

• Nessuna versione ufficiale supporta i backup remoti. Ciò significa che pg_probackup deve essere eseguito sullo stesso host del cluster pgsql. (Esiste un ramo di sviluppo che si occupa del backup da un sito remoto e dell'archiviazione su un server di backup remoto)
• Nessun supporto per un ripristino del backup non riuscito.

Possiamo riassumere i paragrafi precedenti con una matrice di funzionalità come la seguente.

Controllo cluster

ClusterControl fornisce la funzionalità per generare un backup immediato o per pianificarne uno e automatizzare l'attività in modo semplice e veloce.

Possiamo scegliere tra due metodi di backup, pgdump (logico) e pg_basebackup (binario). Possiamo anche specificare dove archiviare i backup (sul server database, sul server ClusterControl o nel cloud), il livello di compressione e la crittografia.

Inoltre, con ClusterControl possiamo utilizzare la funzionalità Point-in-Time Recovery e la verifica del backup per convalidare il backup generato.