Hogyan készíts biztonsági mentést az app adatbázisáról (és hogyan állítsd vissza)

Az app adatbázisának mentéséhez ütemezetten exportáld egy fájlba (Postgres esetén a szabványos eszköz a pg_dump), tárold a másolatokat az adatbázistól külön helyen, és rendszeresen állíts vissza egyet üres adatbázisba, hogy bizonyítsd, működik. Kockázatos változtatás előtt készíts egy extra mentést. A kódmentésed, legyen az GitHub-tárolló vagy export, nem tartalmazza az adataidat.

Ez az útmutató kisebb appokat üzemeltetőknek készült, akik nem akarnak aggódni az adatvesztés miatt. A példákhoz Postgres-t használ, mert a legtöbb AI-val épített app ezt használja, de az elvek bármilyen adatbázisra vonatkoznak.

Mit kell egy mentésnek lefednie

Egy app több az adatbázisnál. Tudd, melyik rész melyik mentéssel védett.

Az adat az a rész, amit nem lehet újrateremteni. A kód újraírható, a beállítások újra megadhatók; a vásárlóid rendelései nem.

1. lépés: Döntsd el, mennyi adatot veszíthetsz el

Két kérdés határozza meg a mentési tervet:

• Mennyi friss adatot veszíthetsz el nyugodtan? Ha naponta egyszer mentesz, és az adatbázis este meghibásodik, a nap változásai elvesznek. Egy hobbiappnál ez rendben van. Egy rendeléseket fogadó appnál lehet, hogy nem.
• Mennyi ideig lehet leállva az app a visszaállítás alatt? Egy kisebb adatbázis percek alatt visszaáll. Egy nagy akár sokkal tovább tarthat, és ezt jobb előre tudni, mint akkor, amikor már szükséged lenne rá.

Kisebb appoknál a napi automatikus mentés plusz egy kézi mentés a kockázatos változtatások előtt ésszerű kiindulópont. Pénzzel vagy egészségügyi adatokkal dolgozó appoknál gyakoribb mentés kell, vagy felügyelt adatbázis pont-idejű visszaállítással (vagyis bármely pillanatra vissza tudsz állni, nem csak az utolsó mentésre).

2. lépés: Nézd meg, mit csinál már a szolgáltatód

Sok felügyelt adatbázis-szolgáltató készít automatikus mentést. Derítsd ki:

• Be van-e kapcsolva a mentés a csomagodban, és milyen gyakran fut?
• Meddig tárolják?
• Visszaállítható-e egy adott időpontra, vagy csak napi pillanatképre?
• Letölthető-e a mentés, vagy csak a rendszerükön belül állítható vissza?

A szolgáltatói mentések hasznosak, de egy közös hibapontjuk van az adatbázissal: a fiókot. Ha a fiókot lezárják, felfüggesztik vagy a projektet törlik, a mentések is elveszhetnek. Ezért kell neked is saját másolat.

3. lépés: Készíts mentést a pg_dumppal

A pg_dump egy Postgres-adatbázist exportál fájlba. Konzisztens pillanatképet olvas, így az app közben tovább futhat.

Tipikus parancs, amely az appban már meglévő kapcsolati karakterláncot használja egy környezeti változóból:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

A kapcsolók jelentése:

• --format=custom tömörített fájlt ír, amelyet a pg_restore olvas, és később egyes táblákat is vissza lehet állítani belőle. Ha olvasható .sql fájlt szeretnél, használd a --format=plain kapcsolót.
• --no-owner kihagyja a tulajdonjogi parancsokat, így egyszerűbb más adatbázisba visszaállítani.
• A fájlnévben lévő dátum elkülöníti a mentéseket.

A pg_dump verziójának egyezőnek vagy újabbnak kell lennie, mint az adatbázisod Postgres-verziója. Egy régebbi pg_dump nem hajlandó lefutni.

Ha AI-val építesz, és nem akarsz parancssorral dolgozni, ezt kérheted:

Készíts biztonsági mentést az app adatbázisáról pg_dump eszközzel, egyedi formátumban, a mai dátummal a fájlnévben. Ne írd ki a kapcsolati karakterláncot vagy bármilyen titkot. A végén mondd meg a fájl nevét és méretét.

4. lépés: Automatizáld

A kézi mentésekről könnyű megfeledkezni. Automatizáld azzal, amit a beállításod támogat:

• Az adatbázis-szolgáltatód ütemezett mentései, ha van ilyen.
• Ütemezett feladat egy szerveren vagy CI-szolgáltatásnál, amely lefuttatja a pg_dump-ot, és feltölti a fájlt tárolóba.
• Felügyelt mentési szolgáltatás, amely csatlakozik az adatbázisodhoz.

Bármelyiket választod, állítsd be, hogy jelezzen, ha a mentés hibázik. Az a mentési feladat, amely három hónapig csendben hibázott, a klasszikus horrortörténet.

5. lépés: Tárold a másolatokat máshol

A hüvelykujjszabályt gyakran 3-2-1 szabálynak hívják: három másolat az adatodból, két különböző típusú tárolón, egy másolat telephelyen kívül. Egy kisebb app gyakorlati változata:

• Az élő adatbázis
• A szolgáltató saját automatikus mentései
• Saját dumpok külön tárolóban, például egy másik fiókban lévő objektumtároló-vödörben

Ezen kívül:

• Korlátozd a hozzáférést. Egy mentés minden felhasználó adatát tartalmazza. Ugyanúgy kezeld, mint az élő adatbázist.
• Tarts megőrzési szabályzatot. Például a napi mentéseket két hétig, a havi mentéseket egy évig. A régi mentéseket szándékosan töröld, és ne feledd, hogy az adatvédelmi szabályok kérésre törlést írhatnak elő a személyes adatokhoz.
• Soha ne commitold a mentéseket a Gitbe. Egy dump egy tárolóban adatszivárgás, ami csak arra vár, hogy megtörténjen.

6. lépés: Teszteld a visszaállítást

A mentés csak annyit ér, mint az utolsó sikeres visszaállítás. Legalább néhány havonta, és minden változtatás után a mentési folyamatban:

1. Hozz létre egy új, üres adatbázist. Tesztelésre soha ne az élő adatbázisra állíts vissza.
2. Állítsd vissza ebbe a legutóbbi mentést:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Sima .sql fájl esetén használd helyette a psql "$TEST_DATABASE_URL" -f backup.sql parancsot.

1. Ellenőrizd, hogy minden tábla létezik, hasonlítsd össze a sorszámokat az élő adatbázissal, és nézz meg néhány friss rekordot.
2. Ha lehet, indíts egy példányt az appból erre az adatbázisra, és jelentkezz be.
3. Jegyezd fel, mennyi ideig tartott a visszaállítás. Ez az igazi helyreállítási idő.

7. lépés: Készíts mentést a kockázatos változtatások előtt

Friss mentést készíts közvetlenül ezek előtt:

• Olyan adatbázis-migráció futtatása, amely oszlopokat töröl vagy átnevez
• Tömeges adatimport
• AI-ügynök által végzett nagy változtatás az adatmodellen
• Régi rekordok törlése

Az AI-val épített appban az ügynök a táblaszerkezetet is módosíthatja egy funkció részeként. A checkpointok és a verziókezelés visszagörgetik a kódot, de a törölt sorokat nem állítják vissza. Egy harminc másodperces mentés egy nagy változtatás előtt olcsó biztosítás.

Gyakori hibák

• Feltételezni, hogy a Git vagy a kódexport mentés. Ezekben a kód van, nem az adat.
• Soha nem tesztelni a visszaállítást. Sok mentés csak akkor derül ki üresnek, részlegesnek vagy olvashatatlannak, amikor szükség lenne rá.
• A mentéseket ugyanabban a fiókban tartani, mint az adatbázist. Egy feltört vagy lezárt fiók mindkettőt elveszíti.
• Elfelejteni a feltöltött fájlokat. Az adatbázis a fájl elérési útját tárolja; maga a kép a tárolóban van.
• Titkokat hagyni a mentési szkriptekben. A kapcsolati karakterláncot környezeti változóból olvasd, soha ne a szkript szövegéből. Lásd: hogyan őrizd az API-kulcsokat biztonságban.

Mentések és a Mythex

A Mythex-projekteknek lehet saját Postgres-adatbázisuk, és a kapcsolati adataik bekerülnek a munkaterületbe és a publikált appba. A Mythex dokumentációja nem ír le adatbázis-mentési vagy visszaállítási funkciót, ezért a mentést magadnak kell megtervezned: kérd meg az ügynököt, hogy készítsen dumpot, töltsd le, és őrizd biztonságos helyen, különösen nagy változtatások előtt. A projektexport (Pro) a kódodat tartalmazza, a titkokat és a node_modules mappát kihagyva; az adatbázis-sorokat nem. Lásd: Adatbázis és Adatok tulajdonjoga a dokumentációban. Az adatbázisról magáról többet a mi a Postgres útmutatóban olvashatsz.

Mentési ellenőrzőlista

• Eldöntötted, mennyi adatot engedhetsz meg magadnak elveszíteni, és mennyi ideig lehetsz leállva
• Ellenőrizd, milyen automatikus mentéseket nyújt az adatbázis-szolgáltatód
• A saját dumpod ütemezetten fut, és a hibák riasztanak
• A másolatok az adatbázistól külön, korlátozott hozzáféréssel vannak tárolva
• A megőrzési szabályzat le van írva
• A feltöltött fájlok is mentve vannak, nem csak az adatbázis
• A visszaállítás tesztelve egy üres adatbázisba, a sorszámokat ellenőrizve
• Minden kockázatos változtatás előtt készül mentés

Kérdések