Резервни копии и реставрација во PostgreSQL

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

Типови на резервни копии во PostgreSQL

Логичка резервна копија

Логичките резервни копии се текстуални претстава на базата на податоци што ја екстрактираат структурата и содржината во форма на SQL команди. Овој тип на резервна копија се генерира на логичко нивп, што значи дека не прави директна копија од data директориумот на базата, туку ги чита податоците преку SQL интерфејс и ги конвертира во извршни SQL команди. Овој тип на копија е практичен од аспект на тоа што излезот е во формат на SQL команди, па не е директно зависен од верзијата на кластерот од каде што се прави копијата или каде што се реставрира. Ваквиот формат, истотака го прави излезот од копијата читлив и отвора можност едноставно да се менува доколку е потребно. Дополнително, функционалностa за логички резервни копии во PostgreSQL, oвозможува селективно копирање на делови од базата, за што ќе бидат прикажани примери во продолжение.

pg_dump е најчесто користената алатка за креирање логички резервни копии во PostgreSQL

Основни примери за користење на pg_dump

• Резервна копија на целата база на податоци

pg_dump -h localhost -U postgres -d db_name > db_name.sql

• Резервна копија каде што излезот е компресирана датотека (се користи принципот на цевки во UNIX)

`pg_dump -h localhost -U postgres -d db_name | gzip > db_name.sql.gz

• Резервна копија каде што излезот е со наставка по желба на корисникот

pg_dump -h localhost -U postgres -Fc -d db_name > db_name.custom

Користење на pg_dump за селективна резервна копија

• Резервна копија само на шемата (без податоци)

pg_dump -h localhost -U postgres -s -d db_name > db_name.sql

• Резервна копија само на податоците

pg_dump -h localhost -U postgres -a -d db_name > db_name.sql

• Резервна копија само на излистаните табели (секоја табела се наведува како посебен -t параметар)

pg_dump -h localhost -U postgres -d db_name -t table1 -t table2 > db_name.sql

• Резервна копија на сите табели, со исклучок на излистаните

pg_dump -h localhost -U postgres -d db_name --exclude-table=table1 > db_name.sql

• Резервна копија само на излистана шема од базата

pg_dump -h localhost -U postgres -d db_name -n public > db_name.sql

Користење на pg_dump со дополнителни опции

• Резервна копија каде што ќе бидат додадени DROP команди пред секое креирање на објект.

Ова е практично доколку сакаме да овозможиме резервната копија да може да се аплицира врз веќе постоечка и активна (полна) база, така што наместо рачно пребришување на објектите, истото ќе се направи автоматски.

pg_dump -h localhost -U postgres -c -d db_name > db_name.sql

• Резервна копија каде што командите за креирање ќе вклучуваат IF EXISTS проверки

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

pg_dump -h localhost -U postgres --if-exists -c -d db_name > db_name.sql

Физичка резервна копија

Физичките резервни копии се директни копии на фајловите на оперативниот систем што ги користи PostgreSQL за чување на податоците. Тие работат на ниво на фајл-систем и го копираат целиот data директориум или делови од него. За разлика од логичките копии се многу побрзи и се преферираат за големи бази на податоци. Ги зачуваат сите објекти од базата, без исклучок, и не постои можност за селективна копија. Овозможуваат Point-in-Time Recovery кога се комбинираат со WAL (Write Ahead Log). Поради тоа што се зачувуваат целосни фајлови, истите се зависни од верзијата на PostgreSQL.

pg_basebackup e најчесто користената команда за креирање физички резервни копии во PostgreSQL

Основни примери за користење на pg_basebackup

• Стандардна физичка резервна копија

pg_basebackup -h localhost -U postgres -D /backup/base_backup -P -v

• Физичка резервна копија со WAL stream

pg_basebackup -h localhost -U postgres -D /backup/base_backup -X stream -P

Стандардна реставрација

Доколку излезот од логичката копија е во SQL формат истиот може едноставно да се реставрира на следниот начин, така што ќе се даде како влез на psql интерфејсот.

psql -h localhost -U postgres -d db_name < db_name.sql

Со користење на алатката pg_restore можни се дополнителни опции при реставрација на копијата

• Стандардна реставрација од формат по желба

pg_restore -h localhost -U postgres -d db_name db_name.custom

• Селективно реставрирање на табели

pg_restore -h localhost -U postgres -d company_db -t table1 -t table2 db_name.custom

• Селективно реставрирање со исклучување на одредени табели

pg_restore -h localhost -U postgres -d company_db --exclude-table=db_name db_name.custom

Point-in-Time Recovery (PITR)

Point-in-Time Recovery (PITR) е напредна техника за реставрација што овозможува враќање на базата на податоци до било кој момент во времето за кој се достапни WAL записите. Ова е многу моќна функционалност што се користи во критични ситуации каде стандардните резервни копии не се доволни. За да функционира PITR, освен физичка резервна копија, потребно е нивото на деталност на WAL логот да е зголемено и притоа да е активно архивирање. Истото се конфигурира во postgresql.conf. Во продолжение се параметрите и нивните вредности:

wal_level = replica                    
archive_mode = on                      
archive_command = 'cp %p /backup/wal_archive/%f'
max_wal_senders = 3 

Постапката за Point-in-Time Recovery (PITR) се извршува со спуштен сервер и опфаќа неколку чекори

1. Креирање на нов data дирекотриум
2. Реставрирање на физичката копија
3. Конфигурирање на recovery mode

• Поставување на следните параметри во postgresql.conf

  restore_command = 'cp /backup/wal_archive/%f %p'
  recovery_target_time = '2024-01-15 14:30:00'
  recovery_target_action = 'promote'
  

• Креирање на recovery.signal фајл за да се иницира recovery при следното стартување на серверот

touch /var/lib/postgresql/postgres_version/main/recovery.signal

• Повторно стартување на серверот