Si të bëni kopje rezervë të bazës së të dhënave të aplikacionit (dhe ta rikthyeni me të vërtetë)

Për të bërë një kopje rezervë të bazës së të dhënave të aplikacionit, eksportojeni në një skedar sipas një orari (për Postgres, mjeti standard është pg_dump), ruani kopjet diku ndryshe nga baza e të dhënave, dhe rikthejeni rregullisht një kopje në një bazë të dhënash bosh për të provuar që funksionon. Bëni një kopje shtesë menjëherë përpara çdo ndryshimi të rrezikshëm. Kopja e kodit tuaj, qoftë kjo një depo GitHub apo një eksport, nuk përfshin të dhënat tuaja.

Ky udhëzues është për njerëzit që drejtojnë një aplikacion të vogël dhe duan të pushojnë së shqetësuari për humbjen e tij. Përdor Postgres për shembujt, sepse shumica e aplikacioneve të ndërtuara me AI përdorin Postgres, por parimet zbatohen për çdo bazë të dhënash.

Çfarë duhet të mbulojë një kopje rezervë

Një aplikacion është më shumë se baza e tij e të dhënave. Dijeni cilën pjesë mbron secila kopje rezervë.

Të dhënat janë pjesa që nuk mund ta rikrijoni. Kodi mund të rishkruhet dhe cilësimet mund të rishtypen; porositë e klientëve tuaj nuk mund.

Hapi 1: Vendosni sa mund të humbni

Dy pyetje përcaktojnë planin tuaj të kopjeve rezervë:

• Sa të dhëna të fundit mund të humbisni pa problem? Nëse bëni kopje rezervë një herë në ditë dhe baza e të dhënave dështon në mbrëmje, humbni ndryshimet e asaj dite. Për një aplikacion hobi kjo është në rregull. Për një aplikacion që merr porosi, mund të mos jetë.
• Sa kohë mund të mbetet aplikacioni jashtë funksionit gjatë rikthimit? Një bazë e vogël të dhënash rikthehet në minuta. Një e madhe mund të marrë shumë më tepër kohë, dhe duhet ta dini këtë përpara se t'ju duhet.

Për shumicën e aplikacioneve të vogla, një kopje automatike çdo ditë plus një manuale përpara ndryshimeve të rrezikshme është një fillim i arsyeshëm. Aplikacionet me para ose të dhëna shëndetësore të përfshira meritojnë kopje më të shpeshta, ose një bazë të dhënash të menaxhuar me rikthim në një pikë kohore (aftësinë për të rikthyer në çdo moment, jo vetëm në kopjen e fundit).

Hapi 2: Kontrolloni çfarë bën tashmë ofruesi juaj

Shumë ofrues të bazave të menaxhuara të dhënash bëjnë kopje automatike. Kontrolloni:

• A janë të aktivizuara kopjet rezervë për planin tuaj, dhe sa shpesh ekzekutohen?
• Sa kohë mbahen?
• A mund të riktheheni në një pikë kohore, apo vetëm në një pamje të ditës së fundit?
• A mund të shkarkoni një kopje rezervë, apo vetëm ta riktheni brenda sistemit të tyre?

Kopjet rezervë të ofruesit janë të dobishme, por ndajnë një pikë të vetme dështimi me bazën e të dhënave tuaj: llogarinë. Nëse llogaria mbyllet, pezullohet ose projekti fshihet, kopjet mund të humbasin bashkë me të. Prandaj ju duhet edhe kopja juaj.

Hapi 3: Bëni një dump me pg_dump

pg_dump eksporton një bazë të dhënash Postgres në një skedar. Ai lexon një pamje të qëndrueshme (snapshot) të të dhënave, kështu që aplikacioni mund të vazhdojë të punojë ndërsa ai përfundon.

Një komandë tipike, duke përdorur lidhjen me bazën e të dhënave që aplikacioni juaj ka tashmë në një variabël mjedisi:

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

Çfarë bëjnë opsionet:

• --format=custom shkruan një skedar të kompresuar që pg_restore mund ta lexojë, dhe ju lejon të riktheni më vonë tabela individuale. Përdorni --format=plain nëse dëshironi një skedar .sql të lexueshëm.
• --no-owner heq komandat e pronësisë, gjë që e thjeshton rikthimin në një bazë tjetër të dhënash.
• Data në emrin e skedarit i mban kopjet rezervë të ndara.

Versioni i pg_dump duhet të jetë i njëjtë me versionin e Postgres të bazës suaj, ose më i ri. Një pg_dump më i vjetër mund të refuzojë të funksionojë.

Nëse ndërtoni me AI dhe nuk dëshironi të prekni rreshtin e komandave, mund të kërkoni:

Krijo një kopje rezervë të bazës së të dhënave të aplikacionit me pg_dump në formatin custom, me datën e sotme në emrin e skedarit. Mos shfaq lidhjen me bazën e të dhënave apo asnjë sekret. Më thuaj emrin e skedarit dhe madhësinë e tij kur të përfundojë.

Hapi 4: Automatizoni

Kopjet rezervë manuale harrohen. Automatizojini me çfarëdo që mbështet konfigurimi juaj:

• Kopjet rezervë të planifikuara të ofruesit të bazës së të dhënave, nëse ofrohen.
• Një punë e planifikuar në një server ose shërbim CI që ekzekuton pg_dump dhe ngarkon skedarin në ruajtje.
• Një shërbim i gatshëm kopjesh rezervë që lidhet me bazën tuaj të dhënash.

Kudo që zgjidhni, bëjeni të ju njoftojë kur një kopje rezervë dështon. Një punë kopjesh rezervë që ka dështuar në heshtje për tre muaj është historia klasike e tmerrit.

Hapi 5: Ruani kopje diku tjetër

Rregulli i gishtit shpesh quhet 3-2-1: tre kopje të të dhënave, në dy lloje ruajtjeje të ndryshme, me një kopje jashtë vendit. Për një aplikacion të vogël, një version praktik është:

• Baza aktive e të dhënave
• Kopjet automatike të vetë ofruesit
• Dump-et tuaja në një ruajtje të veçantë, si një bucket ruajtjeje objektesh në një llogari tjetër

Gjithashtu:

• Kufizoni qasjen. Një kopje rezervë mban të dhënat e çdo përdoruesi. Trajtojeni si bazën aktive të të dhënave.
• Mbani një politikë mbajtjeje. Për shembull, kopje ditore për dy javë dhe kopje mujore për një vit. Fshini kopjet e vjetra me qëllim, dhe mbani mend se ligjet e privatësisë mund t'ju kërkojnë të fshini të dhëna personale me kërkesë.
• Mos i commit-o kurrë kopjet rezervë në Git. Një dump në një depo është një rrjedhje të dhënash që pret të ndodhë.

Hapi 6: Testoni një rikthim

Një kopje rezervë është aq e mirë sa rikthimi juaj i fundit i suksesshëm. Të paktën çdo disa muaj, dhe pas çdo ndryshimi në procesin e kopjeve rezervë:

1. Krijoni një bazë të re, bosh të dhënash. Mos rikthe kurrë mbi atë aktive për ta testuar.
2. Riktheni kopjen më të fundit në të:

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

Për një skedar .sql të thjeshtë, përdorni psql "$TEST_DATABASE_URL" -f backup.sql në vend të kësaj.

1. Kontrolloni që çdo tabelë ekziston, krahasoni numrat e rreshtave me bazën aktive të të dhënave, dhe shikoni disa regjistrime të fundit.
2. Lidhni një kopje të aplikacionit me të dhe hyni, nëse mundeni.
3. Shënoni sa zgjati rikthimi. Kjo është koha juaj e vërtetë e rikuperimit.

Hapi 7: Bëni kopje rezervë përpara ndryshimeve të rrezikshme

Bëni një kopje të re menjëherë përpara:

• Ekzekutimit të një migrimi të bazës së të dhënave që fshin ose riemërton kolona
• Importit masiv të të dhënave
• Lejimit të një agjenti AI të bëjë ndryshime të mëdha në modelin e të dhënave
• Fshirjes së regjistrimeve të vjetra

Në një aplikacion të ndërtuar me AI, agjenti mund ta ndryshojë strukturën e tabelave si pjesë e një veçorie. Pikat e kontrollit dhe kontrolli i versioneve kthejnë kodin mbrapsht, por nuk i ringjallin rreshtat e fshirë. Një kopje rezervë prej tridhjetë sekondash përpara një ndryshimi të madh është një sigurim i lirë.

Gabimet më të zakonshme

• Supozimi se Git ose një eksport kodi është kopje rezervë. Ai ka kodin, jo të dhënat.
• Mos testimi kurrë i një rikthimi. Shumë kopje rezervë rezultojnë bosh, të pjesshme ose të palexueshme vetëm kur na duhen.
• Mbajtja e kopjeve rezervë në të njëjtën llogari me bazën e të dhënave. Një llogari e komprometuar ose e mbyllur humb të dyjat.
• Harrimi i skedarëve të ngarkuar. Baza e të dhënave ruan rrugën e skedarit; vetë imazhi ndodhet në ruajtje.
• Lënia e sekreteve në skriptet e kopjeve rezervë. Lexojeni lidhjen me bazën e të dhënave nga një variabël mjedisi, kurrë nga teksti i skriptit. Shihni si t'i mbani të sigurta çelësat API.

Kopjet rezervë dhe Mythex

Projektet Mythex mund të kenë një bazë të dhënash Postgres të dedikuar, dhe detajet e lidhjes injektohen në hapësirën e punës dhe në aplikacionin e publikuar. Dokumentacioni i Mythex nuk përshkruan një veçori kopjeje rezervë ose rikthimi të bazës së të dhënave, kështu që planifikojeni vetë: kërkojini agjentit të bëjë një dump, shkarkojeni dhe mbajeni diku të sigurt, sidomos përpara ndryshimeve të mëdha. Një eksport projekti (Pro) përmban kodin tuaj, me sekretet dhe node_modules të lëna jashtë; nuk përmban rreshta të bazës së të dhënave. Shihni Database dhe Data ownership në dokumentacion. Për më shumë rreth vetë bazës së të dhënave, lexoni çfarë është Postgres.

Lista e kontrollit për kopjet rezervë

• Vendosur sa të dhëna mund të humbni pa problem dhe sa kohë mund të jeni jashtë funksionit
• Kontrolluar çfarë kopjesh automatike ofron ofruesi i bazës së të dhënave
• Dump-i juaj ekzekutohet sipas orarit, dhe dështimet ju njoftojnë
• Kopjet e ruajtura veçmas nga baza e të dhënave, me qasje të kufizuar
• Politika e mbajtjes e shkruar
• Skedarët e ngarkuar të kopjuar po ashtu, jo vetëm baza e të dhënave
• Rikthimi i testuar në një bazë të dhënash bosh, me numrat e rreshtave të kontrolluar
• Kopja rezervë e bërë përpara çdo ndryshimi të rrezikshëm

Pyetje