A Point-in-Time Recovery (PITR) beállítása PostgreSQL-ben

A digitális korban az adatok jelentik a vállalatok és magánszemélyek egyik legértékesebb vagyonát. Egy adatbázis kiesése, korruptálódása vagy véletlen törlése azonnali katasztrófát jelenthet. Míg a rendszeres biztonsági mentések elengedhetetlenek, a puszta biztonsági mentés nem mindig elegendő, ha egy konkrét pillanatra van szükségünk a visszaállításhoz. Itt jön képbe a Point-in-Time Recovery (PITR), amely a PostgreSQL egyik legerősebb funkciója az adatok helyreállítására. Ez a cikk részletesen bemutatja, hogyan állítható be a PITR a PostgreSQL-ben, hogy adatvesztés esetén pontosan ahhoz a pillanathoz térhessünk vissza, amikor minden még rendben volt.

Miért kritikus a Point-in-Time Recovery?

Képzeljük el a következő forgatókönyveket: egy fejlesztő véletlenül töröl egy kritikus táblát éles környezetben; egy rendszerhiba miatt az adatbázis sérül; egy rosszindulatú támadás során adatok módosulnak. Ezekben az esetekben nem elég egy tegnapi mentést visszaállítani, ami adatvesztést jelentene az utolsó mentés óta. A PITR lehetővé teszi, hogy az adatbázist bármelyik tranzakció előtti állapotba, vagy egy pontos időpillanatra állítsuk vissza, minimális adatvesztéssel – akár csak másodpercekkel a probléma bekövetkezte előttre. Ez a rugalmasság felbecsülhetetlen értékű a katasztrófa-helyreállítási (Disaster Recovery – DR) stratégiákban.

Mi az a Point-in-Time Recovery (PITR)?

A Point-in-Time Recovery, vagy rövidítve PITR, egy olyan adatbázis-helyreállítási technika, amely lehetővé teszi az adatbázis visszaállítását egy tetszőleges, korábbi időpontra. Ez nem egy egyszerű „utolsó mentés visszaállítása” művelet. A PITR alapja két kulcsfontosságú elem:

Alap biztonsági mentés (Base Backup): Ez az adatbázis teljes másolata egy adott időpontban. Gyakorlatilag egy pillanatfelvétel az adatbázisról, amely önmagában visszaállítható, de csak a mentés pillanatára.
WAL (Write-Ahead Log) archiválás: A PostgreSQL minden adatváltoztatást először egy tranzakciós naplóba, a Write-Ahead Logba (WAL) ír, mielőtt azt az adatfájlokba alkalmazná. A WAL-ok archiválása azt jelenti, hogy ezeket a naplófájlokat egy biztonságos, külön helyre másoljuk. Ezek a WAL fájlok tartalmazzák az alap biztonsági mentés elkészítése óta végrehajtott összes tranzakciót.

A PITR lényege, hogy egy alap biztonsági mentést visszaállítunk, majd az archivált WAL fájlokat „lejátsszuk” (replay) az adatbázison, egészen a kívánt visszaállítási pontig. Ez a módszer garantálja az adatok konzisztenciáját és integritását.

A PITR működési elve: Egy időutazás a múltba

Képzeljünk el egy folyamatosan frissülő könyvet (az adatbázis). Időnként készítünk egy teljes másolatot a könyvről (ez az alap biztonsági mentés). Amikor ezen másolat után új bejegyzéseket írunk a könyvbe, minden egyes bejegyzést (tranzakciót) külön feljegyzünk egy naplóba (ez a WAL). Ezt a naplót folyamatosan archiváljuk. Ha később szeretnénk visszatérni egy korábbi állapotba – mondjuk az „előző kedd délelőtt 10 órához” –, akkor fogjuk a legutóbbi teljes könyvmásolatunkat (ami esetleg a hétfő reggeli állapotot tükrözi), majd szépen sorban „lejátsszuk” rá az összes naplóbejegyzést a hétfő reggel és a kedd délelőtt 10 óra közötti időszakból. Ekkor pontosan a kívánt állapotba kerül a könyvünk.

Ez a folyamat a PostgreSQL esetében is így működik. A WAL-ok az adatbázis-tranzakciók szekvenciális sorozatát tartalmazzák, amelyek kritikus fontosságúak az adatbázis konzisztenciájának fenntartásához és a helyreállításhoz. A PITR beállításához tehát a PostgreSQL-t úgy kell konfigurálnunk, hogy rendszeresen archiválja ezeket a WAL fájlokat.

A PITR beállításának lépésről lépésre útmutatója PostgreSQL-ben

A PITR beállítása néhány kulcsfontosságú konfigurációs lépésből és rendszeres feladatból áll.

1. A WAL archiválás konfigurálása

Ez a legfontosabb lépés. A PostgreSQL szervernek tudnia kell, hogy archiválnia kell a WAL fájlokat, és hogyan tegye azt meg.

Módosítsa a postgresql.conf fájlt:
Keresse meg, és szükség esetén módosítsa a következő paramétereket a PostgreSQL konfigurációs fájljában (általában /etc/postgresql/<verzió>/main/postgresql.conf):
```
wal_level = replica          # Korábban 'hot_standby' vagy 'archive', most már 'replica' elegendő.
archive_mode = on            # Engedélyezi a WAL archiválást.
archive_command = 'cp %p /path/to/wal_archive/%f'  # Ezt a parancsot kell testreszabni!
```
- wal_level = replica: Biztosítja, hogy a szükséges információk bekerüljenek a WAL-okba a visszaállításhoz és a replikációhoz.
- archive_mode = on: Bekapcsolja az archiválási mechanizmust.
- archive_command = 'cp %p /path/to/wal_archive/%f': Ez a parancs határozza meg, hogyan történjen a WAL fájlok másolása.
  - %p: A WAL fájl teljes elérési útja.
  - %f: A WAL fájl neve.
  - Fontos: Az /path/to/wal_archive/ elérési utat cserélje ki egy valós, biztonságos, lehetőleg távoli tárolóra (pl. hálózati meghajtó, S3 bucket, Rsync szerver). A parancsnak vissza kell térnie 0-s kilépési kóddal (siker), különben a PostgreSQL megpróbálja újra az archiválást. Olyan parancsot használjon, amely robusztus és kezeli az esetleges hibákat (pl. rsync -a %p /path/to/wal_archive/%f vagy egy komplexebb szkript, amely naplózza a hibákat).
Hozza létre az archívum könyvtárat:
Győződjön meg róla, hogy az archive_command-ban megadott célkönyvtár létezik, és a PostgreSQL felhasználónak (általában postgres) van írási joga hozzá.
```
sudo mkdir -p /path/to/wal_archive
sudo chown postgres:postgres /path/to/wal_archive
```
Indítsa újra a PostgreSQL szervert:
A postgresql.conf módosításai csak a szerver újraindítása után lépnek érvénybe.
```
sudo systemctl restart postgresql
```
Ellenőrizze a naplókat (pg_log vagy journalctl -u postgresql), hogy nincsenek-e hibák az archiválással kapcsolatban.

2. Az alap biztonsági mentés elkészítése

A WAL-ok önmagukban nem elegendőek. Szükség van egy alap biztonsági mentésre, amelyről el lehet kezdeni a WAL-ok visszajátszását.

Használja a pg_basebackup eszközt:
A PostgreSQL beépített pg_basebackup segédprogramja a legjobb módja egy online, konzisztens alap biztonsági mentés elkészítésének. Ezt rendszeres időközönként (pl. naponta, hetente) kell futtatni.
```
pg_basebackup -h localhost -U postgres -D /path/to/base_backups/$(date +%Y%m%d_%H%M%S) -F tar -P -v -X stream -c fast
```
- -h localhost -U postgres: Csatlakozási adatok az adatbázishoz.
- -D /path/to/base_backups/...: A célkönyvtár, ahová a mentés kerül. Ajánlott időbélyegzővel ellátott könyvtárakat használni.
- -F tar: A mentés egy tar archívumként készül el.
- -P: Folyamatjelzőt mutat.
- -v: Részletesebb kimenet.
- -X stream: Streameli a WAL-fájlokat a mentéssel együtt, ami segít a gyorsabb archiválásban és a kezdeti WAL-hiány elkerülésében.
- -c fast: Gyors ellenőrzőpontot készít, minimalizálva az adatbázis terhelését.
Ismételje meg ezt a lépést rendszeresen, és tárolja az alap mentéseket is biztonságos, távoli helyen.

3. A helyreállítás tesztelése (kulcsfontosságú!)

Soha ne bízza a véletlenre! Egy biztonsági mentés csak akkor ér valamit, ha vissza is tudjuk állítani. Rendszeresen tesztelje a teljes helyreállítási folyamatot egy különálló gépen vagy virtuális környezetben.

Készítsen egy teszt adatbázist adatokkal a fő szerveren.
Készítsen egy alap mentést.
Hajtson végre néhány tranzakciót.
Szimulálja az adatvesztést (pl. töröljön egy táblát). Jegyezze fel a pontos időpontot.
Próbálja meg visszaállítani az adatbázist a törlés előtti pillanatra a következő szakaszban leírtak szerint.

Helyreállítás PITR segítségével: A gyakorlatban

Amikor bekövetkezik a baj, és vissza kell állítanunk az adatbázist egy adott időpontra, a következő lépéseket kell követni:

Állítsa le a PostgreSQL szervert:
```
sudo systemctl stop postgresql
```
Törölje vagy helyezze át a régi adatkönyvtárat:
Ha az eredeti helyre állít vissza, törölje vagy nevezze át a sérült adatkönyvtárat.
```
sudo mv /var/lib/postgresql/<verzió>/main /var/lib/postgresql/<verzió>/main_bak
```

Visszaállítja az alap biztonsági mentést:

Másolja vissza a legfrissebb alap biztonsági mentést az eredeti adatkönyvtár helyére.

sudo tar -xf /path/to/base_backups/YYYYMMDD_HHMMSS.tar -C /var/lib/postgresql/<verzió>/main
sudo chown -R postgres:postgres /var/lib/postgresql/<verzió>/main

Hozza létre a recovery.signal fájlt és a helyreállítási paramétereket:
A PostgreSQL 12-től kezdve a visszaállítási konfigurációt a recovery.signal fájl létrehozásával és a paraméterek postgresql.conf fájlban (vagy egy különálló, ideiglenes konfigurációs fájlban) történő megadásával végezzük. Korábbi verziókban egy recovery.conf fájlt használtunk az adatkönyvtárban.

Hozza létre a recovery.signal fájlt az új adatkönyvtár gyökérkönyvtárában:
```
sudo touch /var/lib/postgresql/<verzió>/main/recovery.signal
```
Ezután módosítsa (ideiglenesen) a postgresql.conf fájlt a visszaállítási paraméterekkel:
```
restore_command = 'cp /path/to/wal_archive/%f %p' # Ezt is testre kell szabni!
recovery_target_time = '2023-10-26 14:30:00 CEST'  # A kívánt visszaállítási időpont
# VAGY
# recovery_target_xid = '12345'                  # Tranzakció ID
# recovery_target_lsn = '0/16B033F0'             # LSN (Log Sequence Number)
# recovery_target_name = 'my_recovery_point'     # Elnevezett visszaállítási pont
recovery_target_inclusive = off # ha az adott időpont ELŐTTI állapotot akarjuk
```
- restore_command: Ez a parancs felelős a WAL fájlok visszahozásáért az archívumból a PostgreSQL ideiglenes pg_wal könyvtárába, amikor arra szükség van a lejátszáshoz. Ugyanúgy testre kell szabni, mint az archive_command-ot, de ez fordított irányban működik (forrás a /path/to/wal_archive, cél a %p).
- recovery_target_time: Ez a leggyakrabban használt opció. Adjon meg egy pontos dátumot és időpontot, ameddig vissza szeretné állítani az adatbázist. Ügyeljen az időzónákra!
- A recovery_target_xid, recovery_target_lsn, recovery_target_name fejlettebb opciók, melyek tranzakcióazonosítóra, log szekvencia számra vagy előre definiált recovery point-ra (pg_create_restore_point()) tudnak visszaállítani.
- recovery_target_inclusive = off: Ha ezt beállítja, a visszaállítás a megadott időpont/tranzakció/LSN *előtt* áll le. Ha on (ez az alapértelmezett), akkor *beleértve* azt.
Indítsa el a PostgreSQL szervert:
A PostgreSQL fel fogja ismerni a recovery.signal fájlt, és helyreállítási módba lép.
```
sudo systemctl start postgresql
```
Figyelje a szerver naplóit. Látnia kell, hogy a WAL archívumból fájlokat másol át, és lejátsza azokat. Amikor eléri a recovery_target_time-ot, a szerver leáll a visszaállítással, és alapértelmezett módban elindul (vagy megvárja, hogy Ön kézzel promotálja, ha ezt is konfigurálta).
Ellenőrizze az adatokat és távolítsa el a recovery.signal fájlt:
Miután a szerver elindult, azonnal ellenőrizze, hogy az adatok a várt állapotban vannak-e. Ha igen, akkor a PITR sikeres volt! Ne feledje törölni vagy átnevezni a recovery.signal fájlt (és az ideiglenes postgresql.conf módosításokat visszavonni), hogy a szerver normálisan induljon újra a jövőben, és ne próbáljon ismét helyreállítást végezni.
```
sudo rm /var/lib/postgresql/<verzió>/main/recovery.signal
```
A visszaállítás után ajánlott egy új alap biztonsági mentést készíteni.

Gyakorlati tippek és bevált gyakorlatok

Automatizálás: A WAL archiválást és az alap biztonsági mentések készítését automatizálni kell (pl. cron jobokkal), soha ne bízza kézi feladatokra.
Távoli tárolás: Mind az alap mentéseket, mind a WAL archívumokat külön, lehetőleg távoli, redundáns tárolóra kell menteni. Egy Disaster Recovery tervben elengedhetetlen, hogy az adatmentések földrajzilag elkülönüljenek az elsődleges szervertől.
Monitorozás: Folyamatosan figyelje a WAL archiválási folyamatot. Győződjön meg róla, hogy az archive_command sikeresen fut, és hogy a WAL fájlok ténylegesen eljutnak a célba. Figyelmeztetést kell kapnia, ha az archiválás bármilyen okból leáll.
Rendszeres tesztelés: Ahogy már említettük, a biztonsági mentési stratégia csak akkor ér valamit, ha rendszeresen tesztelik. A helyreállítási folyamat gyakorlása segít felderíteni a problémákat, mielőtt éles helyzetben kellene alkalmazni.
Megfelelő erőforrások: A WAL archiválás és a pg_basebackup némi I/O terhelést ró az adatbázisra. Győződjön meg róla, hogy a szerver elegendő erőforrással (CPU, RAM, diszk I/O) rendelkezik ehhez.
Biztonság: Az archívumok kritikus adatokat tartalmaznak. Gondoskodjon megfelelő hozzáférés-szabályozásról és titkosításról.
Archívum méret: A WAL fájlok sok helyet foglalhatnak. Fontolja meg egy WAL menedzselési stratégia bevezetését, amely törli a régebbi, már nem szükséges WAL fájlokat az archívumból (például a pg_archivecleanup eszközzel).

Konklúzió: Ne hagyd a véletlenre!

A PostgreSQL Point-in-Time Recovery (PITR) beállítása egy alapvető lépés az adatbiztonság és a robusztus katasztrófa-helyreállítási stratégia megvalósításában. Bár a kezdeti beállítás és a folyamatos karbantartás némi erőfeszítést igényel, az általa nyújtott nyugalom és az adatvesztés elleni védelem felbecsülhetetlen. Egy jól konfigurált és rendszeresen tesztelt PITR rendszerrel magabiztosan nézhet szembe az esetleges adatbázis-problémákkal, tudva, hogy adatai biztonságban vannak, és bármikor visszaállíthatóak a kívánt pillanatra. Ne halogassa, implementálja a PITR-t még ma!