= Резервни копии и реставрација во 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` - Повторно стартување на серверот