Useimmat SQL-sovellukset tukevat Point-in-Time Recoveryä joka tarkoittaa käytännössä yksinkertaisesti sitä että tietokanta tuottaa transaktio-logeja joiden avulla voidaan halutessaan palata hyvinkin tarkasti tiettyyn ajankohtaan. Myös avoimen lähdekoodin PostgreSQL tukee tätä ominaisuutta (Kirjoitushetkellä ainakaan MySQL ei tätä vielä tue) ja tämä mahdollistaa useita mielenkiintoisia käyttötapoja, mm. mahdollistamalla tarkan varmuuskopion tietokannasta jolla voidaan palata aina tiettyyn ajankohtaan helposti.

Virtualisointi on kuitenkin mahdollistanut uusien koneiden tuotttamisen helposti, nopeasti ja kustannustehokkaasti. Kun koneita voidaan tuottaa aika tehokkaasti on katastrofivarmentaminenkin helpottunut huomattavasti. Toisessa konesalissa voidaan ajaa erillistä tuotantoa ja varalta muutamaa konetta joihin katastrofitilanteissa voidaan käynnistää toisen konesalin palveluita, esim. juuri PostgreSQL:n tietokannat. PostgreSQL:n tarjoama point-in-time recovery mahdollistaa standby-koneen käytön erittäin helposti. Käytännössä tuotantokantaan asetetaan transaktiolgoit päälle jonka jälkeen tietokanta tallentaa wal-tiedostoja arkistohakemistoon josta ne voidaan siirtää helposti toiseen lokaatioon ja siellä ajaa katastrofivarmennus-käytössä olevaan standby-koneeseen, tämä on myös erittäin helppoa koska standby-tietokanta voidaan määrittää tilaan jossa se automaattisesti hakee tietystä hakemistosta transaktiologit ja ajaa niiden mukaiset muutokset tietokantaansa. Alla oleva kaaviokuva kertoo tarkemmin mistä on kyse:

Kuvattu ominaisuus on todella helppoa ottaa käyttöön jonka lisäksi se on myös erittäin tehokas ja nopea. Käytännössä toisen konesalin kopio on perässä 1-2 transaktiologin verran mikäli konesalien välissä on normaali yhteys joka ei ole täysin kuormitettu. Pahimmassakin tilanteessa siis menetetään vain pienen hetken tiedot, joka tarjoaa erittäin hyvän kustannustehokkuuden ratkaisulle. Ominaisuuden käyttöönotto aloitetaan muokkaamalla tuotantopuolelle tietokantaan logit käyttöön muokkaamalla postgresql.conf-tiedostoa:

archive_mode = on
archive_command = 'cp -v %p /var/lib/pgsql/data/pgsql/archives/%f'
archive_timeout = 300

Seuraava toimenpide on siirtää itse logit standby-koneelle. Tämä onnistuu helpoiten lisäämällä standby-koneen croniin rsync-työ, alla olevassa esimerkissä logeja haetaan viiden minuutin välein, mutta voit säätää sen omaan ympäristöösi parhaiten sopivaksi. Käytännössä siis tämä määrittelee maksimaalisen datan menetyksen katastrofitilanteessa, eli jos kantaan tulee paljon muutoksia tätä on syytä kiristää hiukan.

/5 * * * * rsync -avz --remove-sent-files prod-sql:/var/lib/pgsql/data/pgsql/archives/ /var/lib/pgsql/data/pgsql/archives/ > /dev/null

Esimerkki olettaa että olet tehnyt SSH-avaimet koneiden välille, jolloin siirto onnistuu automaattisesti. Viimeinen työvaihe käyttöönotossa on määritellä standby-tietokanta hakemaan archive-hakemistosta transaktiologeja ja ajamaan niiden mukaiset muutokset tietokantaan. Tässä hyödynnetään pg_standby-komentoa jonka käyttöönotto tapahtuu muokkaamalla standby-koneen recovery.conf-tiedostoa.

restore_command = '/usr/bin/pg_standby -l -d -s 2 -t /tmp/pgsql.trigger /var/lib/pgsql/data/pgsql/archives %f %p %r 2>>standby.log'

PostgreSQL:n dokumentaatiossa on erittäin hyvin kuvattu tämä warm standby-toiminto joten kannattaa tutustua näihin mikäli aihe kiinnostaa tarkemmin. Tässä taas hyvä esimerkki siitä miten avoimen lähdekoodin tietokanta kykenee tarjoamaan ominaisuuksia jotka useimmin löytyvät vain kalliista enterprise-tietokannoista. PostgreSQL:stä on saatavilla lisäksi tuettu PostgreSQL Plus-versio joka tarjoaa paljon muitakin lisäominaisuuksia ja mm. erittäin hyvän Oracle-yhteensopivuuden jonka avulla olemassa olevia Oracle-tietokantoja voidaan helposti migroida kustannuksiltaan paljon edullisempaan Postgres-tietokantaan.