Стратегии за резервни копии (Backup Strategies)

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

Full backup претставува целосна копија на целата база на податоци во одреден момент.

Карактеристики:

• ги содржи сите табели, индекси, податоци и метаподатоци
• најлесен за restore
• зафаќа најмногу простор и време

Предности:

• едноставно опоравување
• низок ризик од неконзистентност

Недостатоци:

• голем storage простор
• подолго време за извршување кај големи бази

createdb transfermarkt_restore 

pg_restore -U postgres -d transfermarkt_restore 

transfermarkt_full_2026_02_04.dump 

Incremental backup ги зачувува само промените направени од последниот backup (full или incremental).

Карактеристики:

• многу помал простор
• брзо извршување

Недостатоци:

• за restore потребни се сите претходни backup-и
• поголем ризик ако недостасува еден backup

Logical vs Physical Backup во PostgreSQL

Logical Backup – pg_dump

Logical backup работи на логичко ниво и ги извлекува податоците како SQL инструкции.

Карактеристики:

• Backup во .sql или .dump формат
• може да се restore-не на различна верзија на PostgreSQL
• не го блокира нормалното работење на базата

Предности:

• флексибилен
• погоден за миграции

Недостатоци:

• побавен кај големи бази
• не содржи low-level storage информации

pg_dump -U postgres -F c -f transfermarkt_logical.dump transfermarkt 

createdb transfermarkt_new 

pg_restore -U postgres -d transfermarkt_new transfermarkt_logical.dump 

Physical Backup – pg_basebackup

Physical backup прави копија од целата data directory структура.

Карактеристики:

• многу помал простор
• брзо извршување

Недостатоци:

• за restore потребни се сите претходни backup-и
• поголем ризик ако недостасува еден backup

Point In Time Recovery (PITR)

Во реални информациски системи, најчестата причина за губење на податоци не е хардверски дефект, туку човечка грешка, како што се погрешни UPDATE, DELETE или DROP TABLE операции. Point-In-Time Recovery (PITR) претставува напреден механизам за опоравување кој овозможува базата на податоци да се врати во точно дефиниран момент во времето, непосредно пред да се случи грешката. Овој пристап е карактеристичен за enterprise системи и е широко користен во production околини.

Write-Ahead Logging (WAL)

PostgreSQL користи Write-Ahead Logging (WAL) како механизам за обезбедување на конзистентност и опоравување. Основното правило е дека секоја промена прво се запишува во WAL лог, а дури потоа се применува во самите data фајлови.

Зошто WAL е критичен за PITR?

• овозможува репродукција на сите промени
• гарантира дека ниту една трансакција нема да биде „изгубена“
• служи како основа за репликација и recovery

Со помош на WAL, PostgreSQL може точно да знае што се случило и по кој редослед во базата.

Процес на Point-In-Time Recovery

1. се прави base backup (physical)
2. се овозможува WAL archiving
3. во случај на грешка базата се враќа од последниот backup
4. се запира recovery процесот во точно дефинирано време

Предности на PITR:

• прецизно опоравување
• минимална загуба на податоци

Недостатоци:

• потребен дополнителен storage
• комплексна конфигурација

Point-In-Time Recovery претставува еден од најмоќните механизми за заштита на податоци во PostgreSQL. Комбинирањето на physical backup со continuous WAL archiving овозможува системот да се врати во стабилна состојба по било каква логичка грешка.

Примери

1. Partial Transaction Corruption во Transfermarkt систем

Во рамки на Transfermarkt базата, постојат повеќе меѓусебно поврзани табели кои ја моделираат логиката на трансфер на играчи: players, clubs и transfers на пример. Процесот на трансфер на играч вклучува повеќе чекори кои треба да се извршат како една атомска операција:

-Се ажурира club_id во табелата players -Се намалува budget кај новиот клуб -Се додава запис во табелата transfers

Овие операции логички претставуваат една трансакција.

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

-Најпрво, преку логови, ќе го утврдиме точниот момент кога се случил проблемот. -Потоа ќе креираме нова база (recovery):

createdb transfermarkt_debug

-PITR: конфигурираме враќање на состојбата непосредно пред грешката:

recovery_target_time = '2026-04-29 16:22:09'

Со ова PostgreSQL ќе ги репродуцира WAL записите се до моментот пред неуспешната трансакција. -Потоа ги споредуваме податоците и ја бараме разликата:

-- Неконзистентна состојба (production)
SELECT * FROM players WHERE id = 101;

-- Конзистентна состојба (recovery)
SELECT * FROM players WHERE id = 101;

-Преку рачна поправка, наместо целосно враќање на базата, ја враќаме во првобитната состојба со едно query:

UPDATE players
SET club_id = <старa вредност>
WHERE id = 101;

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

2. Silent Data Corruption (Trigger Bug)

Во оваа база се користат тригери кои вршат автоматизација на одредени полиња по извршување на трансфери. Еден ваков пример е тригер кој треба да ја зголеми вредноста на играчот за 10% (x1.1) по секој трансфер:

CREATE TRIGGER update_value
AFTER UPDATE ON transfers

Сепак, се случила грешка и системот наместо *1,1 го множи со *2. Овој bug не се приметува одма, но грешките кои произлегуваат од него се штетни на долгорочен период. За да ја решиме оваа грешка, најпрво ќе се вратиме пред започнување на trigger bug.

-Кога ќе го откриеме моментот кога triggerот почнал да работи погрешно, креираме recovery база:

createdb transfermarkt_recovery

recovery_target_time = '2026-04-29 09:00:00'

-Дури тогаш почнува recovery процесот. По овој процес market_value е вратен во реални вредности и нема последователни cascade грешки. Ова е пример за една од најопасните категории на грешки во базите на податоци - Silent data corruption, поради тоа што немаат crash, немаат error message и системот си работи нормално. Во системот на Transfermarkt една ваква грешка може да доведе до уништување на статистиката за цела сезона.

3. Huge Data Growth

Transfermarkt системот претставува голема и брзорастечка база на податоци која содржи players, matches, transfers - табели кои од ден во ден се повеќе и повеќе растат.

Ако користиме класичен full logical backup:

pg_dump transfermarkt > full.sql

се појавуваат следниве проблеми: -backup трае 4 часа -се користи голем storage простор -процесот не е скалабилен за дневно извршување

Затоа ќе користиме комбинирана backup стратегија од full physical backup + incremental backup (WAL)

-Weekly Full Backup: Се прави целосна копија од базата еднаш неделно:

pg_basebackup -U replication_user \
-D /backup/base_weekly \
-Fp -Xs -P

Овој backup претставува starting point за recovery.

-WAL Archiving (Incremental backup): Се активира continuous logging на сите промени во базата:

archive_mode = on
archive_command = 'cp %p /wal_archive/%f'

Ова овозможува секоја промена во базата да биде зачувана во WAL логови.

Сега да видиме едно recovery сценарио ако во четврток се случи crash на системот. Процесот на recovery е: -Се враќа последниот full backup (неделниот snapshot) -Се replay-ираат WAL логовите од понеделник до четврток -Базата се враќа во последната конзистентна состојба

Овој пример покажува дека Full backup сам по себе не е доволен за големи системи, Incremental (WAL-based) backup е неопходен за production средини и дека комбинацијата од двата пристапи овозможува баланс помеѓу перформанси и сигурност.