Бекап и реставрација на базите на податоци

Бекап претставува процес на креирање резервна копија од базата на податоци со цел податоците да можат да се вратат во случај на грешка, оштетување, случајно бришење, неуспешна миграција или пад на системот. Реставрација претставува обратен процес, односно враќање на базата од претходно направена резервна копија. Во системите за управување со бази на податоци, бекапот е една од најважните административни операции бидејќи обезбедува трајност и достапност на податоците. PostgreSQL поддржува повеќе начини за бекап.

Логички бекап со pg_dump

PostgreSQL овозможува логички бекап со алатката pg_dump . Не ги копира физичките датотеки на PostgreSQL, туку ја зачувува структурата и податоците така што подоцна можат повторно да се креираат. Предност на овој пристап е тоа што бекапот може да се врати и на понова верзија на PostgreSQL или на друг сервер.

pg_dump -U admin -d film_rental -f /tmp/film_rental.sql

Ова креира обична .sql датотека која содржи SQL наредби за повторно креирање на структурата и податоците. Овој формат е читлив за човек и може да се отвори како текстуална SQL скрипта.

pg_dump -U admin -d film_rental -Fc -f /tmp/film_rental.dump

Опцијата -Fc креира custom-format archive. Овој формат не се реставрира со psql, туку со pg_restore. Предноста е што овозможува пофлексибилна реставрација, селектирање на објекти и компресија.

pg_dump -U admin -d film_rental -s -f /tmp/film_rental_schema.sql

Опцијата -s или --schema-only креира dump само од структурата на базата. Во него се зачувуваат табелите, индексите, constraints, views и други дефиниции, но не и редовите со податоци. Ова е корисно кога сакаме да ја пренесеме само шемата на базата, без тест или продукциски податоци.

pg_dump -U admin -d film_rental -a -f /tmp/film_rental_data.sql

Опцијата -a или --data-only креира dump само од податоците, без дефинициите на табелите. Ова е корисно кога структурата веќе постои, а сакаме да ги внесеме само редовите.

pg_dump -U admin -d film_rental -t rental -f /tmp/rental_table.sql

Опцијата -t овозможува бекап само на одредена табела. Во овој пример се прави dump само на табелата rental. Ова е корисно ако сакаме да зачуваме критична табела пред да правиме промени врз неа, на пример пред тестирање на партиционирање или масовно бришење.

pg_dump -U admin -d film_rental -t rental -t payment -f /tmp/rental_payment.sql

Со повеќе -t параметри може да се зачуваат повеќе табели. Во системот Film Rental, табелите rental и payment се логички поврзани, бидејќи плаќањето се однесува на конкретно изнајмување. Затоа има смисла тие да се бекапираат заедно. pg_dump -U admin -d film_rental -T payment -f /tmp/film_rental_without_payment.sql

Опцијата -T или --exclude-table се користи за да се исклучи одредена табела од dump-от. Во примерот, се прави dump на базата без табелата payment. pg_dump -U admin -d film_rental --clean --if-exists -f /tmp/film_rental_clean.sql

Опцијата --clean додава DROP наредби пред CREATE наредбите. Тоа значи дека при реставрација прво ќе се избришат постоечките табели, индекси, constraints и други елементи од структурата на базата, па потоа повторно ќе се креираат според dump-от. Опцијата --if-exists спречува непотребни грешки ако некој објект не постои. Ова е корисно кога dump-от се враќа во база која веќе содржи објекти со истите имиња.

pg_dump -U admin -d film_rental --create -f /tmp/film_rental_with_create.sql

Опцијата --create додава команда за креирање на самата база. Ова е корисно кога dump-от треба да се врати на нов сервер каде што базата сè уште не постои. pg_dump -U admin -d film_rental -Fd -j 4 -f /tmp/film_rental_dir

Опцијата -Fd креира directory-format archive, а -j 4 користи 4 паралелни jobs. Овој формат е единствениот pg_dump формат што поддржува паралелен dump. Тоа може да го намали времето за бекап кај поголеми бази, но истовремено ја зголемува активноста врз серверот.

pg_dump -U admin -d film_rental --column-inserts -f /tmp/film_rental_inserts.sql

Со --column-inserts, податоците се зачувуваат како INSERT INTO ... наредби со наведени имиња на колони. Овој формат е поспор за реставрација, но е почитлив и може да биде корисен ако dump-от треба да се прилагодува рачно или да се користи надвор од PostgreSQL.

Реставрација на базата

Реставрација претставува процес на враќање на база на податоци од претходно креиран бекап. Начинот на реставрација зависи од форматот во кој е направен dump-от. Доколку бекапот е направен како plain SQL датотека, реставрацијата се прави со psql. Доколку бекапот е направен во custom или directory формат, реставрацијата се прави со pg_restore.

psql -U admin -d film_rental_restore < /tmp/film_rental.sql Со оваа команда SQL наредбите од dump датотеката се извршуваат во базата film_rental_restore. Plain SQL dump-от претставува обична текстуална SQL скрипта и може да содржи CREATE TABLE, INSERT, CREATE INDEX, ALTER TABLE и други наредби потребни за повторно креирање на структурата и податоците.

pg_restore -U admin -d film_rental_restore /tmp/film_rental.dump

Со оваа команда се реставрира custom-format dump во базата film_rental_restore. Овој тип на dump не се реставрира со psql, туку со pg_restore, бидејќи не е обична SQL датотека. Custom форматот е погоден затоа што овозможува поголема контрола при реставрација. На пример, може да се реставрира само структурата, само податоците или само одредени табели од dump-от.

pg_restore -U admin -d film_rental_restore --schema-only /tmp/film_rental.dump Со оваа команда се враќа само структурата на базата, односно табелите, индексите, constraints и другите дефиниции, без податоците.

pg_restore -U admin -d film_rental_restore --data-only /tmp/film_rental.dump

Со оваа команда се враќаат само податоците, без повторно креирање на структурата. Ова е корисно кога табелите веќе постојат, а потребно е да се внесат само редовите. Во некои ситуации не е потребно да се врати целата база, туку само една табела. На пример, ако проблемот се случил само со табелата payment, може да се реставрира само таа табела.

pg_restore -U admin -d film_rental_restore -t payment /tmp/film_rental.dump

Оваа команда ја враќа само табелата payment од dump-от. Ако во базата веќе постојат табели или други објекти со истите имиња, при реставрација може да настанат грешки. Во таков случај може да се користи опцијата --clean, која прво ги брише постоечките објекти, па потоа ги креира повторно од dump-от.

pg_restore -U admin -d film_rental_restore --clean --if-exists /tmp/film_rental.dump

Опцијата --if-exists се користи за да не се појавуваат грешки ако некој објект што треба да се избрише не постои.

pg_restore -U admin -d film_rental_restore_dir -j 4 /tmp/film_rental_dir

Со оваа команда се реставрира directory-format dump во базата film_rental_restore_dir. Опцијата -j 4 значи дека реставрацијата ќе се извршува со 4 паралелни jobs, што може да ја забрза реставрацијата кај поголеми бази.

Физички бекап

Покрај логичкиот бекап со pg_dump, PostgreSQL овозможува и физички бекап. Кај физичкиот бекап не се извезуваат SQL наредби, туку се копираат реалните датотеки што PostgreSQL ги користи за складирање на податоците. Овој тип на бекап се однесува на целиот PostgreSQL cluster, а не само на една конкретна база или табела. Во PostgreSQL ова може да се прави со pg_basebackup .

pg_basebackup -h localhost -U replicator -D /tmp/film_rental_basebackup -Fp -Xs -P

Со оваа команда се креира физички base backup од целиот PostgreSQL cluster во директориумот /tmp/film_rental_basebackup. Опцијата -Fp означува plain формат, -Xs ги вклучува потребните WAL записи преку streaming, а -P прикажува progress додека се извршува бекапот. За користење на pg_basebackup потребен е корисник со replication привилегии. Овој пристап е погоден кога е потребно целосно опоравување на PostgreSQL серверот или подготовка на standby сервер.

Реставрација на физички бекап

Реставрацијата од физички бекап се прави со враќање на зачуваниот PostgreSQL data директориум на местото на тековниот data директориум. Пред да се направи ова, PostgreSQL серверот мора да биде исклучен, бидејќи при реставрација се заменуваат физичките датотеки што ги користи целиот database cluster. По враќањето на data директориумот, серверот повторно се стартува. PostgreSQL потоа ја продолжува работата со состојбата што била зачувана во моментот кога бил направен физичкиот бекап. За разлика од логичкиот бекап, тука не се реставрира една конкретна база или табела, туку целиот PostgreSQL cluster.

Continuous Archiving и Point-in-Time Recovery

PostgreSQL ги запишува сите промени во WAL (Write-Ahead Log) датотеки. WAL претставува механизам со кој PostgreSQL обезбедува трајност и можност за опоравување на податоците. Со помош на WAL, промените што се случиле по последниот base backup можат повторно да се применат при реставрација. Continuous Archiving претставува процес во кој WAL segment датотеките што PostgreSQL веќе ги пополнил се копираат и чуваат на посебна локација. Со комбинација од физички base backup и архивирани WAL датотеки, PostgreSQL може да ја врати базата до конкретен момент во времето. Овој процес се нарекува Point-in-Time Recovery, односно PITR.

За да се овозможи WAL архивирање, во postgresql.conf се поставуваат следните параметри:

wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

Со wal_level = replica , PostgreSQL запишува доволно информации во WAL датотеките за тие да можат да се користат за архивирање, репликација и опоравување. Со archive_mode = on се овозможува архивирање на WAL датотеките, а со archive_command се дефинира командата со која секоја завршена WAL датотека се копира во архивски директориум. По овозможување на WAL архивирање, потребно е да се направи base backup:

pg_basebackup -h localhost -U replicator -D /tmp/film_rental_pitr_basebackup -Fp -Xs -P

Овој base backup претставува почетна точка за опоравување. При реставрација, PostgreSQL го враќа base backup-от, а потоа ги применува архивираните WAL записи до зададениот момент. За време на реставрација, во postgresql.conf се поставуваат:

restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
recovery_target_time = '2026-05-01 03:44:59'

Со restore_command , PostgreSQL знае од каде да ги земе архивираните WAL датотеки. Со recovery_target_time се задава моментот до кој треба да се врати базата. Дополнително, во PostgreSQL data директориумот се креира празна датотека recovery.signal. Со ова PostgreSQL знае дека при стартување треба да влезе во recovery режим.