PgBarman

Před časem jsem se věnoval metodám zálohování databáze PostgreSQL. Chtěl jsem rozpoutat diskusi na téma různých způsobů zálohování, bohužel toto téma si asi správci nechávají pro sebe (pokud vůbec zálohují). Přišla jediná reakce a to zálohování pomocí PgBarman.

PgBarman je sada skriptů v Pythonu okolo online backup. Jsem většinou velmi skeptický k nástrojům, které mají ulehčovat něco, co samo o sobě vyžaduje změnu 5 řádků v konfigu a asi tak dva příkazy. V konečném důsledku tedy práci někde přidají (krom konfigurace samotného zálohování je nutné také nakonfigurovat ten daný nástroj) a někde ulehčí. Přesto jsem dal Barmanovi šanci.

Instalace

Instalace a nastavení je dobře popsáno v dokumentaci. Pokud nepotřebujeme specialitky dostupné v novějších verzích, postačí nám verze PgBarmana z repositárů naší distribuce. Pokud chceme verzi novější, můžeme použít repositář vývojářů (APT, YUM).

apt-get install barman

SSH spojení

Dále je třeba nastavit oboustranné ssh (pomocí klíčů, bez hesla) spojení mezi zálohovacím serverem (dále jen backup) a databázovým serverem (dále jen pg). Pochopitelně, zálohovací i databázový server může být tentýž stroj (potom ale musíme zajistit odlévání těchto dat na nějaké externí medium, jinak o záloze nelze vůbec hovořit).

Zálohovací skript na stroji backup běží pod uživatelem barman. Databáze na stroji pg běží většinou pod uživatelem postgres. Potřebujeme tedy, aby příkazy:

barman@backup$ ssh postgres@pg

postgres@pg$ ssh barman@backup

Prošly bez nutnosti zadávat heslo.

PSQL spojení

Dále je nutné mít spojení ze stroje backup do databáze na stroji pg:

psql -c 'SELECT version()' -U postgres -h pg

Tady je typicky nutné upravit soubor pg_hba.conf na stroji pg.

Zálohovací adresář

By default je to ve /var/lib/barman a doporučuju to tak nechat a tento adresář nalinkovat někam, kam chceme zálohy ukládat. Případně do tohoto adresáře namountovat dostatečně velký oddíl. Adresář musí mít vlastníka a skupinu barman.barman.

Nastavení zálohování

Teď je nutné nastavit zálohování serveru pg. V konfiguračním souboru je připravená sekce [main]:

;; ; 'main' PostgreSQL Server configuration
;; [main]
;; ; Human readable description
;; description =  "Main PostgreSQL Database"
;;
;; ; SSH options
;; ssh_command = ssh postgres@pg
;;
;; ; PostgreSQL connection string
;; conninfo = host=pg user=postgres
;;
;; ; Minimum number of required backups (redundancy)
;; ; minimum_redundancy = 1
;;
;; ; Examples of retention policies
;;
;; ; Retention policy (disabled)
;; ; retention_policy =
;; ; Retention policy (based on redundancy)
;; ; retention_policy = REDUNDANCY 2
;; ; Retention policy (based on recovery window)
;; ; retention_policy = RECOVERY WINDOW OF 4 WEEKS

Kde musíme nastavit zejména:

• Jméno, pod kterým budeme server volat [jméno]
• Popis serveru (description).
• ssh příkaz (viz výše) pro spojení ze serveru backup na server pg.
• psql connection string, formát viz dokumentaci.

Teď je třeba spustit:

barman@backup$ barman show-server main
barman@backup$ barman check main

A zaznamenat si: incoming_wals_directory.

Nastavení WAL

Už jsme skoro u konce. Teď je třeba nastavit postgresql.conf na stroji pg:

wal_level = 'archive'
archive_mode = on
archive_command = 'rsync -a %p barman@backup:INCOMING_WALS_DIRECTORY/%f'

Kde místo INCOMING_WALS_DIRECTORY zapíšeme konkrétní umístění z výpisu příkazu barman show-server main.

Kontrola

Pokud je vše ok, proběhne kontrola příkazem barman check main takto:

Server main:
 ssh: OK
 PostgreSQL: OK
 archive_mode: OK
 archive_command: OK
 directories: OK
 retention policy settings: OK
 backup maximum age: OK (no last_backup_maximum_age provided)
 compression settings: OK
 minimum redundancy requirements: OK (have 0 backups, expected at least 0)

Tady pozor, moje verze z Debianu Jessie neupozorňuje na nepřítomnost programu rsync na straně zálohovaného serveru. Je tedy dobré zkontrolovat, zda je tento program nainstalován.

Nastavení je tedy je docela děsné (oproti samotnému nastavení online backup), kde je to jen o nastavení wal level a archive. Na druhou stranu, barman poskytuje hromadu kontrol, které vás upozorní na chybu v nastavení či spojení na db server, počet záloh apod.

Osvojte si tedy příkazy jako check, show-server, status. Existují i checky do Nagiosu. (K čemu jsou zálohovací systémy, které nikdo nekontroluje a neupozorní na chybu v zálohování? Na prd jsou…)

Zálohování

Tak, konečně máme barman nainstalován, nastaven a checky jsou bez chyb. Můžeme se tedy pustit do zálohování:

barman backup main

Takto bychom provedli zálohování konkrétního serveru main, pokud chceme provést zálohu všech serverů, můžeme použít slovíčko all (barman backup all).

Starting backup for server main in /var/lib/barman/main/base/20150709T123130
Backup start at xlog location: 0/4000020 (000000010000000000000004, 00000020)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 0/40000A8 (000000010000000000000004, 000000A8)
Backup completed

Co se vlastně provedlo?

Online backup je založen na odkládání WAL logů databázového serveru. Většina moderních db serverů funguje tak, že si do binárního logu zapisuje všechny provedené operace (změnové) a až potom (checkpoint) tato data zapíše do trvalých souborů.

Binární logy jsou tedy ideální prostředek pro „inkrementální“ zálohu databáze, jelikož se do nich v reálném čase zapisují všechny změny, které se s db dělají.

Pokud máme zařízeno uchovávání wal logů nastavením archive_command, pro zálohu nám tedy stačí jednou za čas odkopírovat soubory databáze (base backup). A tuto base zálohu právě provede příkaz barman backup.

Je otázkou, jak často základní zálohu provádět. Z principu fungování odlévání wal logů bohatě postačí si pořídit base zálohu někdy na počátku hned po instalaci a od té doby uchovávat jen wal logy. Jenže v praxi velikost logů roste podle aktivity práce s db, takže velmi rychle mohou inkrementální logy přerůst velikost db samotné.

Dále při obnově se obnoví základní záloha a potom postupně všechny wal logy. Poškozený log nelze přeskočit. Pokud bychom tedy měli base zálohu z ledna a někdy v květnu by se nám poškodil log, byli bychom schopni db server obnovit pouze k datu před poškozeným wal logem. Což už v červenci může být k ničemu.

Seznam záloh

Seznam záloh (které potom budeme chtít obnovit, nebo smazat) získáme příkazem: barman list-backup all Pokud si náhodou pamatujeme přímo název serveru, můžeme místo all použít konkrétní název.

xxx 20150709T123130 - Thu Jul 9 10:31:33 2015 - Size: 27.8 MiB - WAL Size: 0 B
yyy 20150630T141546 - Tue Jun 30 14:33:50 2015 - Size: 58.3 GiB - WAL Size: 5.6 GiB
yyy 20150616T160513 - Tue Jun 16 16:19:15 2015 - Size: 49.7 GiB - WAL Size: 31.6 GiB

Co to znamená

V předchozím příkladu vidíme tři zálohy pro dva servery (xxx a yyy). Server xxx jsem nastavil během psaní tohoto článku, server yyy pomocí barmana zálohuji již půl roku. Každá záloha je v barmanovi identifikována jménem serveru (tak jak je definován v nastavení) a časovou značkou pořízení zálohy.

Vidíme, že zálohy serveru yyy byly provedeny ve dnech 16.6.2015 a 30.6.2015, vidíme velikost base zálohy a také velikost příslušných wal logů. Libovolnou z těchto záloh můžeme smazat. Pokud smažeme zálohu z 30.6.2015, stále budeme schopni obnovit data až do současnosti, protože postačí base záloha z 16.6.2015. Wal logy máme. Pokud ale smažeme zálohu z 16.6.2015, budeme schopni db obnovit pouze ke stavu po 16.6.2015.

Tak, snad jsem v tom udělal dostatečný zmatek, jdeme to obnovit. :-)

Obnova

Potřebujeme znát konkrétní id zálohy, v tomto případě budeme obnovovat server xxx do adresáře pg. Tady pozor, adresář musí být vlastněný uživatelem barman a musí k němu mít přístup (tedy rychlá obnova do /root/pg neprojde, ani když se snažíte dělat chown barman pg sebevíc).

Je také dobré si uvědomit, že vždy obnovujeme celý server. Nelze (zatím), obnovit jen jednu konkrétní databázi.

barman recover xxx 20150709T123130 pg

Starting local restore for server xxx using backup 20150709T123130
 Destination directory: pg
 Copying the base backup.
 Copying required wal segments.
 The archive_command was set to 'false' to prevent data losses.

Your PostgreSQL server has been successfully prepared for recovery!

Please review network and archive related settings in the PostgreSQL
 configuration file before starting the just recovered instance.

Co se stalo

Barman vykopírovat base zálohu s id xxx 20150709T123130 a vložit do ní všechny wal logy (adresář pg/pg_xlog). Dále změnil nastavení a vypnul archive command, aby při zapnutí tohoto serveru nedošlo k nakopírování wal logů do původního zálohovacího adresáře.

Co teď

Pokud obnovujeme hlavní server na našem stroji, můžeme takto obnovený server nakopírovat do jeho umístění, zkontrolovat nastavení (například Debian má nastavení  v /etc/postgresql  a toto umístění předá serveru při startu, takže nastavení, které nám obnovil barman nechceme).

Na jiných OS (CentOS) je nastavení přímo v hlavním adresáři databáze a tam ho naopak chceme po obnově mít.

Pokud tedy máme nastavení ok, můžeme spustit server příkazem:

pg_ctl -D /path/to/recover/directory start

Případně nakopírovat obnovená data do systémového umístění a zapnout systémovou službu.

Tady se v praxi nevyplácí dělat vylomeniny. I když můžeme mít server umístěn kdekoliv a mít nastavené příslušné cesty v postgresql.conf a pro běh je to perfektně validní nastavení, tak v krizových situacích asi nechcete zjišťovat, co všechno je nastaveno nestandardně a prostě to obnovit do původního adresáře a spustit standardní službu. Havárie je i tak dost stresující, netřeba si přidávat další práci.

Je tedy mnohem lepší mít data na defaultním umístění (typicky někde ve /var/lib a jen mít nastaveny linky na disk s dostatkem místa, případně mít nastavený mountpoint).

Mazání záloh

Tady je dobré se zastavit a vrátit se k nastavení. Ve výchozím stavu je nastaveno minimum_redundancy = 0, to znamená, že není požadován žádný minimální počet base záloh. Doporučuju se zamyslet a nastavit tam rozumné minimum (u mě na soukromých projektech 2). Nestane se tak, že si omylem smažete jedinou zálohu.

Mazat můžeme buď konkrétní zálohu:

backup delete backup-id

Případně (pro volání ze skriptu):

backup delete server last

Zde je právě dobré mít nastavený nějaký minimální počet uložených záloh, barman mi nedovolí smazat (v tuto chvíli jedinou) zálohu serveru xxx.

barman delete xxx last
Skipping delete of backup 20150709T123130 for server xxx due to minimum redundancy requirements (2)

Více v manuálu.

Ještě jednou odkazuji na skvělý manuál. Barman toho umí daleko víc, obnovovat je možné ke konkrétnímu číslu transakce či času (což je vlastnost samotného PITR), automatizovat věci před a po záloze apod. Určitě stojí za to si manuál pročíst celý.

Závěrem

Barman je sada skriptů, která velmi ulehčí některé činnosti (zálohování, obnova, kontrola nastavení), ovšem za cenu složitějšího nastavení. Mimo nastavení online backup (3 položky nastavení postgresql.conf  + příkaz pg_basebackup) je nutné jestě navíc nastavit oboustrané ssh spojení + psql spojení ze serveru na zálohovaného klienta + nastavit sekci v samotném barman.conf. Je to více než trojnásobek práce.

Jenže tuto práci stačí provést jednou a potom jen volat jednoduché příkazy jako barman backup all, barman delete server last a nedejbože občas taky barman recover. A tady je to určitě jednodušší, než udržovat přehled o tom, které wal logy patří ke které záloze, jak je mazat apod.

Takže za mě se počáteční náklady vyplatí. Když jsem ho v lednu nasazoval poprvé, byl jsem mírně skeptický, dneska mám všechny své soukromé servery zálohované právě barmanem. A naposledy toto pondělí jsem byl moc rád za příkaz barman recover.