Tuskin tässä tulee suoranaista ratkaisua, mutta osaratkaisuja ... mahdollisesti, ja taustatietoa:
1.
Tietokannan replikointi
Sekä MS SQL:ssä että Oraclessa on replikointimahdollisuudet. Ne ovat mukana täysiverisinä erittäin kalliissa Enterprise versioissa. Niiden käyttäminen - missään käytössä - edellyttää jonkinlaista ammattilaisuutta. Ne eivät ole yksinkertaisia eivätkä huolettomia - tosin toimivat sitten erittäin hyvin.
Molemmista ohjelmista on olemassa ilmaisversioita, mutta ei niissä mitään replikointia ole.
2.
Datan replikointi, määräajoin
Jos on mahdollista määritellä datalle yksi (tai useampiakin) päähakemistoja, joihin inkrementaalinen kopiointi tai peilaus kohdistuu, niin tämän voi tehdä helposti, esim. "rsync" -komennolla. Komento toimii erittäin nopeasti normaalissa käyttötilanteessa, koska muuttuneita tiedostoja on vähän ja kopiointi on siis inkrementaalista.
Tämä ei sovellu sellaiseen hakemistopolkuun, jonka alla on tiedostoja joita ei voi kopioida, syystä tai toisesta - ellei niitä saa "exclude" -lauseeseen järkevästi. Tarkoitan sitä, että 100 000 erillistä tiedostoa joilla on vaihtelevat nimet ei saa, mutta esim. yhden hakemiston "/data/log" saa hyvin helposti otettua pois kopioitavien listalta.
Koska kyseessä on komentorivikomento, niin sen saa scriptiin ja scriptin ajon voi ajastaa.
Tässä on yksi periaatteellinen ongelma. Jos tiedostoja kopioidaan reaaliaikaisesti jollakin tietyllä hetkellä, niin yksittäiset tiedostot tulevat kopioitua kuitenkin osittain eri hetkellä. Lisäksi sinulla on tietokanta ja sen sisällöllä on mahdollisesti riippuvuuksia näihin tiedostoihin.
Toisin sanoen backupin pystyy tekemään, mutta jos sen joskus palauttaa, niin onko järjestelmä ehjä? Jos järjestelmä on iso, on järjestelmän toimivuuden tarkistaminen kaikilta osin käytännössä mahdotonta tehdä. Tällöin voi todeta, että backup on hyödytön, koska sitä ei voi luotettavasti palauttaa.
Oikeasti tuollaisesta järjestelmästä ei voi ottaa backuppeja muulloin kuin silloin kun käyttäjiä ei ole. Mainitsen tämän koska jotkut niistä kuitenkin ottavat backuppeja muulloinkin.
3.
Levyn peilaus
Kuten edellä huomautettiin, RAID 1 peilaus, on vakiotekniikkaa ja sillä saa levyn peilattua. Jos haluat varmistaa myös itse konetta, niin hanki rinnalle toinen samanlainen kone johon levyn voi ongelmatilanteessa heittää.
4.
Virtuaalikoneella
Tuollainen sovellus olisi helpoiten ylläpidettävissä virtuaalikoneessa, jolloin sitä voi ajaa millä hyvänsä raudalla koska hyvänsä. Rautojen ei siis tarvitse olla mitenkään samanlaisia, vaan riittää että niissä toimii virtualisointiohjelmisto - esim. Linux-Windows vaihtokelpoisuus on 100% normaalien OS-versioiden puitteissa (noin lyhyesti sanottuna). Tämä tekisi fyysisen koneen varmistamisen triviaaliseksi.
Virtuaalikoneesta saa helposti 100% kopion, riippuen järjestelmän nopeudesta ja koneen koosta, esim. 5-15 minuutissa. Tätä kopiota voi edelleen käyttää periaatteessa miten hyvänsä - tosin koska siinä on sama hostname ja mahdollisesti sama tcp/ip, niin ei samassa tietoverkossa - yleiset tietoverkkoasiat pätevät tähän kopioon.
Virtuaalikoneesta ei kuitenkaan saa reaaliajassa mitään kopiota, vaan sen pitää olla ajettuna alas. Virtuaalikonetta voi käsitellä kaikilla e.m. tavoilla (replikointi, datojen kopiointi) tai paremminkin sen sisällä voi tehdä kaikkea mitä koneella yleensäkin voi tehdä, mutta rautaan perustuva peilaus tapahtuu vain fyysisellä koneella.
Jos mennään ammattimaisiin, virtuaaliservereihin, kuten VMware ESX, niin siellä reaaliaikaiset kopioinnit ja monet muut asiat, ovat mahdollisia. Tästä maailmasta on myös ilmaisversio ESXi - valitettavasti en tiedä mitä se tekee - kannattanee tarkistaa, jos haluat tuon oikeasti toteuttaa.
Virtuaalikoneen käytöstä on sinänsä melko kattavat vasta-alkajan ohjeet tämän Foorumin "Ohjeiden kehittämisen alla". Kerro jos et löydä. Ohje ei puutu ESX:ään, mutta samat perusperiaatteet ovat voimassa ja VMware Playerillä pääsee hyvin alkuun. Käsittääkseni sillä tehtyä konetta voi ajaa ESX:n alla.
Aihe: Koneen replikointi varakoneelle (Luettu 2999 kertaa)
