Point-in-Time Recovery vs Snapshotit: mitä menetät

Joku suorittaa DELETE-komennon ilman WHERE-ehtoa kello 16.15. Viimeisin varmuuskopiosi on ajalta 03.00. Kaikki näiden ajankohtien välillä tapahtunut on menetetty, eikä mikään palautus tuo sitä takaisin.

Tällä aukolla on nimi — recovery point objective eli RPO — ja point-in-time recovery vs snapshotit -valinta koskee kokonaan sitä, kuinka suureksi aukoksi olet valmis sen hyväksymään.

Kaksi mallia

Snapshotit tallentavat datasi tilan tiettynä hetkenä. Ne suoritetaan aikataulun mukaan, yleensä öisin. Snapshotin palauttaminen vie sinut täsmälleen siihen tilaan, jossa olit sen ottamishetkellä, ja kaikki sen jälkeinen menetetään.

Point-in-time recovery yhdistää base backupin ja jatkuvan streamin tietokannan write-ahead logista. Koska jokainen muutos tallennetaan järjestyksessä, voit toistaa tapahtumat mihin tahansa säilytetyn login kattamaan ajankohtaan asti — myös kello 16.14:ään, minuutti ennen poistoa.

Ero ei ole asteittainen. Ero on siinä, menetämmekö päivän vai minuutin.

Ratkaiseva luku

Kysy itseltäsi rehellisesti yksi kysymys: mitä tapahtuu, jos menetät kaiken viimeisen kahdentoista tunnin aikana kirjoitetun datan?

Henkilökohtaisessa projektissa, dokumentaatiosivustossa tai sisäisessä työkalussa, jonka data voidaan luoda uudelleen, seuraukset eivät välttämättä ole suuret. Päivittäiset snapshotit ovat aidosti oikea ratkaisu, ja jatkuvasta arkistoinnista maksaminen olisi hukkaan heitettyä rahaa.

Kaikessa, mihin asiakkaat kirjoittavat tietoja, vastaus on yleensä jonkinlainen versio lauseesta ”joutuisimme lähettämään ihmisille sähköpostia ja selittämään tilanteen”. Kadonneita tilauksia. Hävinneitä latauksia. Lähetettyjä viestejä, joita ei enää ole. Pelkät tukikustannukset ylittävät yleensä infrastruktuurikulujen eron vuoden ajalta.

Virhe ei ole snapshotien valitseminen. Virhe on niiden valitseminen oletuksena kysymättä koskaan, mitä kahdentoista tunnin aukko maksaisi.

Mihin snapshotit todella sopivat

Snapshotit eivät ole huonompi tuote. Ne kattavat vikatilanteita, joita PITR ei kata:

• Koko levyn menetys. Erillisellä tallennustilalla oleva snapshot palauttaa kaiken, myös tiedostot, joita tietokanta ei omista.
• Nopea, karkean tason rollback. Epäonnistuneen migration palauttaminen staging-ympäristössä on snapshotista nopeampaa kuin login toistaminen.
• Hinta. Yhden kopion tallentaminen päivässä on halvempaa kuin jokaisen kirjoituksen tallentaminen.
• Yksinkertaisuus. Komponenttien vähäisempi määrä on todellinen operatiivinen etu, etenkin pienelle tiimille.

Ongelma syntyy, kun niitä pidetään riittävinä tietokannalle, johon kirjoitetaan jatkuvasti.

Mitä PITR maksaa

Se ei ole ilmaista, ja kustannukset on syytä nimetä:

• Tallennustila. Säilytät base backupin sekä kaikki säilytysajan aikana syntyneet kirjoitukset.
• Monimutkaisuus. Arkistoinnin on toimittava jatkuvasti. Viikon ajan huomaamatta epäonnistunut archiver tarkoittaa, että palautettavissa oleva aikaikkunasi päättyy viikko sitten — siksi archiven monitorointi on yhtä tärkeää kuin sen konfigurointi.
• Palautusaika. Login toistaminen kestää kauemmin kuin snapshotin palauttaminen. RPO paranee, mutta RTO yleensä heikkenee.

Juuri tämä vaihtokauppa yllättää monet. PITR tarkoittaa, että menetät vähemmän dataa, ei sitä, että palvelu olisi nopeammin taas käytettävissä.

Kerroksittainen ratkaisu, jota useimmat tiimit oikeasti tarvitsevat

Käytännössä kyse ei ole valinnasta kahden vaihtoehdon välillä. Tuotantotietokannat tarvitsevat yleensä kolme kerrosta, koska ne vikaantuvat kolmella eri tavalla:

Snapshotit päivittäin, säilytetään viikon tai kahden ajan. Edullinen suoja koneen menettämistä vastaan. Tämä kattaa myös samalla volumella olevat tietokannan ulkopuoliset tiedostot.

Loogiset dumpit päivittäin, säilytetään hostin ulkopuolella. pg_dump on siirrettävä ja luonnostaan eheä. Sen voi palauttaa eri major-versioon, eri palveluntarjoajalle tai kannettavalle tietokoneelle — juuri sitä tarvitset, kun ongelma on alustassa eikä datassa.

Jatkuva arkistointi, kun datassa on asiakkaiden tietoja. Tämä kerros muuttaa tilanteen ”menetimme tämän päivän” tilanteeksi ”menetimme minuutin”.

Jokainen kerros kattaa sen, mihin muut eivät pysty. Snapshot ei auta palveluntarjoajan vaihtamisessa. Looginen dump ei auta palauttamaan tiedostoa, jota ei ollut tietokannassa. Kumpikaan ei auta kumoamaan neljä tuntia sitten tehtyä poistoa.

Dockupin rooli

Dockup tarjoaa kaksi kerrosta, jotka kattavat yleisimmät vikatilanteet, ja on hyödyllistä täsmentää, mitkä ne ovat.

Volume-snapshotit tarpeen mukaan tai aikataulutettuina, säilytettävien snapshotien määrän perusteella:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Loogiset tietokantavarmuuskopiot, jotka streamataan suoraan object storageen ja salataan siirron aikana:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Palautuksen kannalta jälkimmäisessä on kaksi tärkeää ominaisuutta. Varmuuskopio ei koskaan päädy tietokantahostille — se streamataan tallennustilaan sitä mukaa kuin pg_dump tuottaa sitä, joten se ei ole riippuvainen samasta levystä kuin lähdedata. Lisäksi varmuuskopio, jonka suoritus päättyy virhekoodiin tai joka tuottaa nolla tavua, poistetaan ja merkitään epäonnistuneeksi sen sijaan, että se jäisi listaan varmuuskopiolta näyttävänä merkintänä.

Dockup ei tällä hetkellä suorita jatkuvaa arkistointia puolestasi. Jos RPO-tavoitteesi on aidosti minuutteja, tämä kannattaa tietää ennen valintaa. On täysin järkevää ajaa jatkuvaa arkistointia itse managed-tietokantaa vasten ja käyttää alustaa kaikkeen muuhun.

Tällä viikolla tehtävä harjoitus

Kirjoita tuotantotietokannastasi ylös kaksi lukua:

1. RPO — kuinka paljon dataa voit menettää. Mitataan aikana.
2. RTO — kuinka kauan voit olla poissa käytöstä. Mitataan niin ikään aikana.

Tarkista sitten, mitä nykyinen asetuksesi todella tarjoaa, palauttamalla jotain. Jos kirjaamasi luvut ja asetuksesi tuottamat luvut poikkeavat toisistaan, olet löytänyt päätöksen, joka on tehtävä silloin, kun mikään ei ole vielä tulessa — ja se on ainoa hyvä hetki tehdä päätös.

Usein kysytyt kysymykset

Mitä eroa on RPO:lla ja RTO:lla? RPO kertoo, kuinka paljon dataa menetät — eli aikavälin viimeisimmän palautettavissa olevan hetken ja vikatilanteen välillä. RTO kertoo, kuinka kauan palautuminen kestää. Snapshotit tarjoavat suuren RPO:n ja lyhyen RTO:n; PITR kääntää tilanteen päinvastaiseksi.

Voinko palauttaa tunti sitten poistetut rivit öisestä snapshotista? Et. Snapshot palauttaa tilan sellaisena kuin se oli sen ottamishetkellä. Sen jälkeen kirjoitettu data ei sisälly tiedostoon. Satunnaisen ajankohdan palauttaminen edellyttää jatkuvaa arkistointia.

Onko volume-snapshot sama asia kuin tietokannan varmuuskopio? Ei. Snapshot tallentaa levyn, myös sen tilan, jossa tietokanta oli kesken kirjoituksen. Looginen dump on sisäisesti eheä ja siirrettävissä muihin versioihin ja muille palveluntarjoajille. Useimmat tuotantoympäristöt tarvitsevat molemmat.

Kuinka pitkään varmuuskopioita pitäisi säilyttää? Riittävän pitkään, jotta ehdit huomata ongelman. Korruptio tai virheellinen migration huomataan usein vasta päivien kuluttua, joten yhden päivän säilytysaika tarkoittaa usein sitä, että ainoat käytettävissä olevat varmuuskopiot sisältävät jo vaurion.