Näin varmuuskopioit sovelluksesi tietokannan (ja palautat sen oikeasti)

Tietokannan varmuuskopio tehdään viemällä tietokanta tiedostoon aikataulun mukaan (Postgresissa vakiotyökalu on pg_dump), tallentamalla kopiot erilleen tietokannasta ja palauttamalla niistä säännöllisesti yksi tyhjään tietokantaan, jotta nähdään, että se toimii. Ota ylimääräinen varmuuskopio aina juuri ennen riskialtista muutosta. Koodin varmuuskopio, eli GitHub-repositorio tai vienti, ei sisällä dataasi.

Tämä opas on tarkoitettu ihmisille, jotka pyörittävät pientä sovellusta ja haluavat lakata huolehtimasta datan menettämisestä. Esimerkeissä käytetään Postgresia, koska useimmat tekoälyllä rakennetut sovellukset käyttävät sitä, mutta periaatteet pätevät mihin tahansa tietokantaan.

Mitä varmuuskopion pitää kattaa

Sovellus on enemmän kuin tietokanta. Tiedä, mitä osaa kukin varmuuskopio suojaa.

Datan menettäminen on se osa, jota ei voi luoda uudelleen. Koodin voi kirjoittaa uudelleen ja asetukset syöttää uudelleen, mutta asiakkaidesi tilauksia ei.

Vaihe 1: Päätä, kuinka paljon voit menettää

Kaksi kysymystä määrittää varmuuskopiosuunnitelmasi:

• Kuinka paljon tuoretta dataa voit menettää? Jos varmuuskopioit kerran päivässä ja tietokanta hajoaa illalla, menetät sinä päivänä tehdyt muutokset. Harrastesovellukselle se riittää. Sovellukselle, joka vastaanottaa tilauksia, ei välttämättä riitä.
• Kuinka kauan sovellus voi olla pois käytöstä palautuksen ajan? Pieni tietokanta palautuu minuuteissa. Suuri voi kestää paljon kauemmin, ja sen haluat tietää ennen kuin tarvitset sitä.

Pienelle sovellukselle hyvä lähtökohta on päivittäinen automaattinen varmuuskopio ja käsin otettu varmuuskopio ennen riskialtista muutosta. Sovelluksiin, joissa on rahaa tai terveystietoja, tarvitaan tiheämpiä varmuuskopioita tai hallittu tietokanta, jossa on pistemäinen palautus (mahdollisuus palauttaa mihin tahansa hetkeen, ei vain viimeisimpään varmuuskopioon).

Vaihe 2: Tarkista, mitä hostisi jo tekee

Monet hallitut tietokantapalveluntarjoajat tekevät automaattisia varmuuskopioita. Selvitä:

• Ovatko varmuuskopiot käytössä tilauksessasi ja kuinka usein ne ajetaan?
• Kuinka kauan ne säilytetään?
• Voitko palauttaa pistemäisesti vai vain päivittäisen tilannekuvan?
• Voitko ladata varmuuskopion, vai voiko sen palauttaa vain heidän järjestelmässään?

Palveluntarjoajan varmuuskopiot ovat hyödyllisiä, mutta ne jakavat yhden heikon kohdan tietokannasi kanssa: tilin. Jos tili suljetaan, tilaus keskeytetään tai projekti poistetaan, varmuuskopiot voivat lähteä mukana. Siksi tarvitset myös oman kopion.

Vaihe 3: Tee vienti pg_dumpilla

pg_dump vie Postgres-tietokannan tiedostoon. Se lukee yhtenäisen tilannekuvan, joten sovellus voi jatkaa toimintaansa sen aikana.

Tyypillinen komento, joka käyttää sovelluksesi jo käyttämää yhteysmerkkijonoa ympäristömuuttujasta:

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

Vaihtoehtojen merkitys:

• --format=custom kirjoittaa pakatun tiedoston, jonka pg_restore osaa lukea, ja jonka avulla yksittäiset taulut voi palauttaa myöhemmin. Käytä --format=plain-muotoa, jos haluat luettavan .sql-tiedoston.
• --no-owner jättää pois omistajuuteen liittyvät komennot, mikä helpottaa palauttamista toiseen tietokantaan.
• Päivämäärä tiedoston nimessä pitää varmuuskopiot erillään toisistaan.

Pg_dumpin version pitää olla sama tai uudempi kuin tietokantasi Postgres-versio. Vanhempi pg_dump saattaa kieltäytyä toimimasta.

Jos rakennat tekoälyllä eikä komentorivi kiinnosta, voit pyytää:

Luo sovelluksen tietokannasta varmuuskopio pg_dumpilla mukautetussa muodossa, ja tiedoston nimessä on tämän päivän päivämäärä. Älä tulosta yhteysmerkkijonoa tai mitään salaisuutta. Kerro tiedoston nimi ja koko, kun se on valmis.

Vaihe 4: Automatisoi

Käsin tehdyt varmuuskopiot unohtuvat. Automatisoi ne sen mukaan, mitä asennuksesi tukee:

• Tietokantapalveluntarjoajan ajastetut varmuuskopiot, jos se tarjoaa niitä.
• Ajastettu tehtävä palvelimella tai CI-palvelussa, joka ajaa pg_dump-komennon ja lataa tiedoston tallennustilaan.
• Hostattu varmuuskopiopalvelu, joka yhdistyy tietokantaasi.

Valitsitpa minkä tahansa, varmista, että se ilmoittaa, kun varmuuskopio epäonnistuu. Varmuuskopiotyö, joka on epäonnistunut hiljaa kolme kuukautta, on klassinen kauhutarina.

Vaihe 5: Tallenna kopiot muualle

Peukalosääntö tunnetaan usein nimellä 3-2-1: kolme kopiota datastasi, kahdella eri tallennustyypillä ja yksi kopio paikasta poissa. Pienelle sovellukselle käytännöllinen versio on:

• Tuotantotietokanta
• Palveluntarjoajan omat automaattiset varmuuskopiot
• Omat vientisi erillisessä tallennustilassa, kuten objektitallennussäilössä toisella tilillä

Lisäksi:

• Rajoita pääsyä. Varmuuskopio sisältää kaikkien käyttäjien tiedot. Kohtele sitä kuin tuotantotietokantaa.
• Pidä säilytyskäytäntö. Esimerkiksi päivittäiset varmuuskopiot kahden viikon ajan ja kuukausittaiset vuoden ajan. Poista vanhat varmuuskopiot tarkoituksella, ja muista, että tietosuojalait voivat edellyttää henkilötietojen poistamista pyynnöstä.
• Älä koskaan commitoi varmuuskopioita Gitiin. Repositoriossa oleva vienti on tietovuoto, joka odottaa tapahtumistaan.

Vaihe 6: Testaa palautus

Varmuuskopio on vain niin hyvä kuin viimeisin onnistunut palautus. Tee palautustesti vähintään muutaman kuukauden välein ja aina, kun varmuuskopiointiprosessiin tehdään muutos:

1. Luo uusi, tyhjä tietokanta. Älä koskaan testaa palauttamalla päälle tuotantotietokantaan.
2. Palauta uusin varmuuskopio siihen:

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

Jos kyseessä on tavallinen .sql-tiedosto, käytä sen sijaan komentoa psql "$TEST_DATABASE_URL" -f backup.sql.

1. Tarkista, että kaikki taulut ovat olemassa, vertaa rivimääriä tuotantotietokantaan ja katso muutamaa viimeisintä tietuetta.
2. Yhdistä sovelluksen kopio siihen ja kirjaudu sisään, jos mahdollista.
3. Kirjaa ylös, kuinka kauan palautus kesti. Se on todellinen palautusaikasi.

Vaihe 7: Varmuuskopioi ennen riskialtista muutosta

Ota tuore varmuuskopio juuri ennen seuraavia:

• Tietokantamigraation ajaminen, joka poistaa tai nimeää uudelleen sarakkeita
• Datan massatuonti
• Tekoälyagentin tekemä suuri muutos datamalliin
• Vanhojen tietueiden poistaminen

Tekoälyllä rakennetussa sovelluksessa agentti voi muuttaa taulurakennetta osana ominaisuutta. Tarkistuspisteet ja versionhallinta palauttavat koodin, mutta eivät palauta poistettuja rivejä. Kolmenkymmenen sekunnin varmuuskopio ennen suurta muutosta on halpa vakuutus.

Yleisimmät virheet

• Oletus, että Git tai koodin vienti on varmuuskopio. Se sisältää koodin, ei dataa.
• Palautuksen testaamatta jättäminen. Monet varmuuskopiot osoittautuvat tyhjiksi, osittaisiksi tai luettavissa kelvottomiksi vasta, kun niitä tarvitaan.
• Varmuuskopioiden pitäminen samalla tilillä kuin tietokanta. Yksi vaarantunut tai suljettu tili vie molemmat.
• Ladattujen tiedostojen unohtaminen. Tietokanta tallentaa tiedoston polun, mutta itse kuva on tallennustilassa.
• Salaisuuksien jättäminen varmuuskopiokomentoihin. Lue yhteysmerkkijono ympäristömuuttujasta, älä skriptin tekstistä. Katso näin pidät API-avaimet turvassa.

Varmuuskopiot ja Mythex

Mythex-projekteissa voi olla oma Postgres-tietokanta, ja sen yhteystiedot injektoidaan työtilaan ja julkaistuun sovellukseen. Mythexin dokumentaatiossa ei kuvata tietokannan varmuuskopiointi- tai palautusominaisuutta, joten suunnittele oma: pyydä agenttia tekemään vienti, lataa se ja säilytä turvallisessa paikassa, erityisesti ennen suuria muutoksia. Projektin vienti (Pro) sisältää koodisi, jossa salaisuudet ja node_modules on jätetty pois; se ei sisällä tietokantarivejä. Katso Database ja Data ownership dokumentaatiossa. Lisätietoja itse tietokannasta löydät oppaasta mikä on Postgres.

Varmuuskopioinnin tarkistuslista

• Päätetty, kuinka paljon dataa voit menettää ja kuinka kauan voit olla pois käytöstä
• Tarkistettu, mitä automaattisia varmuuskopioita tietokantahostisi tarjoaa
• Oma vienti ajetaan aikataulun mukaan, ja epäonnistumiset hälyttävät
• Kopiot tallennettu erilleen tietokannasta, pääsy rajattu
• Säilytyskäytäntö kirjoitettu ylös
• Ladatut tiedostot varmuuskopioitu tietokannan lisäksi
• Palautus testattu tyhjään tietokantaan ja rivimäärät tarkistettu
• Varmuuskopio otettu ennen jokaista riskialtista muutosta

Kysymykset