Kuidas varundada rakenduse andmebaasi (ja tegelikult taastada)

Rakenduse andmebaasi varundamiseks ekspordi see plaaniliselt faili (Postgresi puhul on standardtööriist pg_dump), hoia koopiad andmebaasist eraldi ja taasta neist regulaarselt üks tühja andmebaasi, et tõestada, et see töötab. Tee enne iga riskantset muudatust lisaks veel üks varukoopia. Sinu koodi varukoopia, olgu see GitHubi repositoorium või eksport, ei sisalda sinu andmeid.

See juhend on mõeldud väikese rakenduse haldajatele, kes tahavad lakata muretsemast selle kaotamise pärast. Näidetes kasutatakse Postgresit, sest enamik AI-ga ehitatud rakendusi kasutab seda, kuid põhimõtted kehtivad iga andmebaasi kohta.

Mida varukoopia peab katma

Rakendus on rohkem kui ainult andmebaas. Tea, milline osa iga varukoopia kaitseb.

Andmed on see osa, mida ei saa taastada. Koodi saab uuesti kirjutada ja seadeid uuesti sisestada; sinu klientide tellimusi aga mitte.

Samm 1: otsusta, kui palju võid kaotada

Kaks küsimust määravad sinu varundusplaani:

• Kui palju värskeid andmeid võid kaotada? Kui varundad kord päevas ja andmebaas ebaõnnestub õhtul, kaotad selle päeva muudatused. Hobirakenduse jaoks on see okei. Rakenduse jaoks, mis võtab tellimusi, ei pruugi see olla.
• Kui kaua võib rakendus taastamise ajal seisata? Väike andmebaas taastub minutitega. Suur võib võtta palju kauem, ja seda pead teadma enne, kui seda vaja läheb.

Enamiku väikeste rakenduste jaoks on hea algus igapäevane automaatne varukoopia ja käsitsi varukoopia enne riskantseid muudatusi. Rakendused, milles on rahalisi või terviseandmeid, vajavad sagedasemaid varukoopiaid või hallatud andmebaasi, millel on punktist-punkti taastamine (võimalus taastada mis tahes hetkeni, mitte ainult viimasesse igapäevasesse koopiasse).

Samm 2: vaata, mida sinu hosting juba teeb

Paljud hallatud andmebaasi teenusepakkujad teevad automaatseid varukoopiaid. Uuri välja:

• Kas varukoopiad on sinu paketis sisse lülitatud ja kui tihti need käivad?
• Kui kaua neid hoitakse?
• Kas saab taastada punktist-punkti või ainult igapäevase tõmmise?
• Kas varukoopia saab alla laadida, või saab seda taastada ainult nende süsteemis?

Teenusepakkuja varukoopiad on kasulikud, kuid need jagavad ühte nõrka kohta oma andmebaasiga: kontot. Kui konto suletakse, peatatakse või projekt kustutatakse, võivad varukoopiad kaduda koos sellega. Seetõttu vajad ka oma koopiat.

Samm 3: tee tõmmis pg_dump abil

pg_dump ekspordib Postgresi andmebaasi faili. See loeb järjepidevat hetktõmmist, nii et rakendus saab selle ajal edasi töötada.

Tüüpiline käsk, mis kasutab ühendusstringi, mis su rakenduses juba keskkonnamuutujas on:

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

Valikute tähendus:

• --format=custom kirjutab tihendatud faili, mida pg_restore oskab lugeda, ja lubab hiljem taastada üksikuid tabeleid. Kasuta --format=plain, kui soovid selle asemel loetavat .sql faili.
• --no-owner jätab välja omanikukäsud, mis muudab taastamise teise andmebaasi lihtsamaks.
• Kuupäev failinimes hoiab varukoopiad lahus.

pg_dump versioon peaks olema sama või uuem kui sinu andmebaasi Postgresi versioon. Vanem pg_dump võib käivitamisest keelduda.

Kui ehitad AI-ga ega taha käsurealt midagi teha, võid paluda:

Loo rakenduse andmebaasist varukoopia pg_dumpi abil custom-vormingus, failinimes tänane kuupäev. Ära prindi ühendusstringi ega ühtegi saladust. Kui oled valmis, ütle mulle faili nimi ja suurus.

Samm 4: automatiseeri see

Käsitsi varukoopiad unustatakse. Automatiseeri need selle abil, mida sinu süsteem toetab:

• Sinu andmebaasi teenusepakkuja plaanilised varukoopiad, kui neid pakutakse.
• Plaaniline töö serveris või CI-teenuses, mis käivitab pg_dump ja laadib faili salvestusse.
• Hallatud varundusteenus, mis ühendub sinu andmebaasiga.

Mida iganes valid, seadista see nii, et see teavitaks sind, kui varundus ebaõnnestub. Varundustöö, mis on kolm kuud vaikselt ebaõnnestunud, on klassikaline õudusjutt.

Samm 5: hoia koopiaid mujal

Üldine reegel on sageli nimega 3-2-1: kolm andmekoopiat, kahel erineval tüüpi salvestusel, üks koopia väljaspool kohta. Väikese rakenduse praktiline versioon on:

• Elav andmebaas
• Teenusepakkuja enda automaatsed varukoopiad
• Sinu enda tõmmised eraldi salvestuses, näiteks objektisalvestuse bucketis teises kontos

Lisaks:

• Piira ligipääsu. Varukoopia sisaldab kõigi kasutajate andmeid. Kohtle seda nagu elavat andmebaasi.
• Hoidmispoliitika. Näiteks igapäevased varukoopiad kaheks nädalaks ja kuised üheks aastaks. Kustuta vanu koopiaid tahtlikult ning pea meeles, et privaatsusseadused võivad nõuda isikuandmete kustutamist, kui seda küsitakse.
• Ära kunagi commiti varukoopiaid Gitti. Tõmmis repositooriumis on andmelekke ootel.

Samm 6: testi taastamist

Varukoopia on sama hea kui sinu viimane edukas taastamine. Tee seda vähemalt iga paari kuu tagant ja pärast iga muudatust varundusprotsessis:

1. Loo uus, tühi andmebaas. Testimiseks ära kunagi taasta elava andmebaasi peale.
2. Taasta sinna viimane varukoopia:

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

Lihtsa .sql faili puhul kasuta selle asemel psql "$TEST_DATABASE_URL" -f backup.sql.

1. Kontrolli, et iga tabel on olemas, võrdle ridade arvu elava andmebaasiga ja vaata mõnda viimast kirjet.
2. Suuna rakenduse koopia sinna ja logi sisse, kui saad.
3. Kirjuta üles, kui kaua taastamine võttis. See on sinu tegelik taastumisaeg.

Samm 7: tee varukoopia enne riskantseid muudatusi

Tee värske varukoopia vahetult enne:

• andmebaasi migratsiooni, mis kustutab või nimetab ümber veerge
• andmete massimpordi
• AI-agendi lubamist teha suuri muudatusi andmemudelis
• vanade kirjete kustutamist

AI-ehitatud rakenduses võib agent muuta tabelistruktuuri funktsiooni osana. Kontrollpunktid ja versioonihaldus taastavad sinu koodi, kuid ei too kustutatud ridu tagasi. Kolmekümne sekundi varukoopia enne suurt muudatust on odav kindlustus.

Levinud vead

• Eeldada, et Git või koodi eksport on varukoopia. Seal on kood, mitte andmed.
• Taastamist kunagi mitte testida. Paljud varukoopiad osutuvad tühjaks, osaliseks või loetamatuks alles siis, kui neid vaja on.
• Varukoopiate hoidmine samas kontos kui andmebaas. Üks kompromiteeritud või suletud konto kaotab mõlemad.
• Üleslaaditud failide unustamine. Andmebaas salvestab faili tee; pilt ise elab salvestuses.
• Saladuste panemine varundusskriptidesse. Loe ühendusstring keskkonnamuutujast, mitte skripti tekstist. Vaata kuidas hoida API-võtmeid turvaliselt.

Varundamine ja Mythex

Mythexi projektidel võib olla oma Postgresi andmebaas ja selle ühendusandmed lisatakse töökeskkonda ja avaldatud rakendusse. Mythexi dokumentatsioon ei kirjelda andmebaasi varundamise ega taastamise funktsiooni, seega planeeri oma: palu agendil teha tõmmis, laadi see alla ja hoia turvaliselt, eriti enne suuri muudatusi. Projekti eksport (Pro) sisaldab sinu koodi, kus saladused ja node_modules on välja jäetud; see ei sisalda andmebaasi ridu. Vaata dokumentatsioonist Andmebaas ja Andmete omand. Andmebaasi kohta üldiselt loe mis on Postgres.

Varundamise kontrollnimekiri

• Otsustatud, kui palju andmeid võid kaotada ja kui kaua võid olla seisakus
• Kontrollitud, milliseid automaatseid varukoopiaid andmebaasi hosting pakub
• Sinu oma tõmmis käib plaaniliselt ja tõrked saadavad teate
• Koopiad on andmebaasist eraldi, piiratud ligipääsuga
• Hoidmispoliitika on kirjas
• Üleslaaditud failid on varundatud koos andmebaasiga
• Taastamine on testitud tühja andmebaasi peal ja ridade arv kontrollitud
• Varukoopia tehtud enne iga riskantset muudatust

Küsimused