Varmuuskopiointi on käytetyin ja usein se tutuin tapa suojata yrityksen tiedot erilaisilta onnettomuuksilta ja inhimillisiltä virheiltä. Kun puhutaan liiketoimintakriittisistä järjestelmistä, on hyvä pysähtyä pohtimaan mitä yritykselle ihan konkreettisesti tapahtuu suuremman katastrofin syntyessä. Pohdinta on hyvä tehdä niin teknisellä kuin johtoryhmätasollakin. Varsinkin yrityksen tekniselle henkilöstölle on voinut tulla tutuksi vuosien saatossa käsitteet RTO ja RPO. RTO kertoo meille, miten kauan palautuminen kestää ja RPO kertoo mihin palautuspisteeseen järjestelmä pitää pystyä palauttamaan. Eli toisin sanoen tulee pohtia, kuinka paljon dataa ollaan valmiita menettämään. Keskusteluissa tulee usein vastaan se, ettei perinteinen varmuuskopiointi aina täytä näitä RTO- ja RPO-vaatimuksia, jolloin pitää turvautua disaster recovery -tuotteisiin kuten Zerto.
Zerto valikoitui tuotteeksemme sen hyvien ominaisuuksien, joustavien käyttötarkoitusten sekä kokemuksien tuoman luottamuksen perusteella. Lisäksi kustannustehokkuus oli suuressa roolissa valintaa tehdessä. Aiemmin disaster recovery on merkinnyt myös suurehkoja kustannuksia, mutta Zerton avulla päästiin kustannusrakenteeseen, jossa palvelu tuli pienempienkin yritysten ulottuville. Yrityksenä Zerto ei tee muuta kuin disaster recovery-tuotettaan, joten voimme olla varmoja siitä, että heidän tuotekehityksensä keskittyy oikeisiin asioihin.
Palvelussa suojattavat virtuaalipalvelimet valitaan tärkeysasteen ja kokonaisuuksien perusteella. Millä palvelimilla sijaitsee kaikista liiketoimintakriittisin data? Mitkä palvelimet kuuluvat samaan kokonaisuuteen? Monesti palvelin ei ole itsenäinen, vaan siihen liittyy muitakin palvelimia halutun toiminnallisuuden varmistamiseksi. Esimerkkinä tästä voisi olla web-palvelin, sen takana oleva sovelluspalvelin ja sen takana oleva tietokantapalvelin. Monesti kokonaisuuteen liittyy lisäksi autentikointikerros, jolloin suojataan esimerkiksi Active Directory –palvelin. Tärkeän datan identifioiminen ei aina ole itsestäänselvyys ja monesti järjestämme asiakkaan kanssa työpajoja, joissa tärkeä data ja kokonaisuudet identifioidaan keskustelun kautta.
Olemme tehneet historiassa kymmeniä Zerto-käyttöönottoja. Yksi tärkeä asia tuotteeseen liittyen on, ettei Zertossa asenneta mitään sovellusta suojattaville koneille, vaan se toimii kokonaan hypervisor-kerroksessa. Tämä on tärkeää, sillä emme halua samaan aikaan muokata ja suojata virtuaalipalvelimia. Zertoa varten asennetaan hallintapalvelin virtuaaliympäristöön, sekä jokaiselle alustapalvelimelle oma pieni Linux-pohjainen replikointipalvelin. Tämän jälkeen valitaan suojattavat virtuaalipalvelimet, sekä kohde jonne suojaus toteutetaan. Koska kyse on replikointituotteesta, jossa suojataan kokonaisia virtuaalipalvelimia sijainnista toiseen, voidaan tuotetta helposti myös hyödyntää palvelinmigraatioihin ja tähän hyödynnämmekin Zertoa laajasti. Palautettua ympäristöä käytetään palvelua varten venytettyä verkkoa pitkin. Palvelumallissamme data replikoidaan joko palvelutuotannostamme Espoosta, tai asiakkaan omasta laitetilasta Helsingin konesaliimme. Datan siirto ja säilytys tapahtuu kokonaan Suomessa.
Disaster recovery ei suojaa meitä pelkästään luonnonmullistuksilta, joissa palvelinsali tuhoutuu täysin. Yleisimpiä käyttötarkoituksia ovatkin inhimillinen virhe tai pieleen mennyt päivitys. Testausmahdollisuuksia ei aina ole (Zerto tosin tarjoaa sellaisenkin!), ja joskus tuotannossa menee asioita pieleen odottamattomasti. Tällöin Zertolla voidaan palautua aikaan ennen kohtalokasta virhettä helposti vain muutamalla klikkauksella. Tilanteessa, jossa DR-ratkaisua ei ole, joudutaan pahimmassa tapauksessa palaamaan edellisen illan varmuuskopioihin, jolloin palvelimelle koko päivän aikana tehdyt muutokset menetetään täysin. Jos varmuuskopioita taas ei ole säännöllisesti testattu, voi tilanne olla vieläkin synkempi. DR-tuotteella palautuminen on aina eksaktia tiedettä – tarkkuus mitataan sekunneissa tai minuuteissa.
Kun tapahtuu palautumista edellyttävä tilanne, on palautumisprosessi yksinkertainen. Ensimmäiseksi on katsottava missä tilassa itse Zerto on. Vaikka koko suojattava ympäristö (Zerto mukaan lukien!) olisi tuhoutunut, ei se ole este palautumiselle. Tässä tilanteessa palautuminen voidaan aloittaa joko meidän toimestamme, tai verkon yli itsepalveluportaalista. Seuraava kysymys on: Mitä palautetaan? Onko kyse yksittäisen palvelimen ongelmasta vai laajemmasta viasta? Viimeinen kysymys on: Mihin ajankohtaan palataan? Näillä tiedoilla varustettuna voidaan suorittaa itse palautus viidellä klikkauksella. Joskus ajankohta, johon palaudutaan, on epäselvä eikä esimerkiksi tiedetä vian tarkkaa alkamisaikaa. Tässä tilanteessa voimme hyvin aloittaa palautumisen arvioidun ajankohdan perusteella. Jos myöhemmin toteamme, että ajankohta oli väärä, voidaan aloittaa uusi palautuminen eri ajankohdasta hyvin kivuttomasti. Zertossa ajatus on aina, että mahdolliset asetukset ja testit on jo palautumisen osalta suoritettu etukäteen. Varsinaisessa vikatilanteessa tarvitaan vain päätös palautumisesta sekä edellä mainitut tiedot. Muistamisen arvoista on, että tässä ratkaisussa päätös palautumisesta on aina ihmisellä. Koska vikatilanteet ja niiden korjaukset ovat moninaiset, ei tätä valintaa voi jättää automatiikan varaan.
Tietyin väliajoin on hyvä pysähtyä pohtimaan, miten aikaisemmin kuvatuista tilanteista oma ympäristönne selviää. Mitkä ovat toimenpiteet, kuinka kauan ympäristö on alhaalla ja minkä verran tehtyä työtä on tehty turhaan. DR-palveluihin liittyvässä keskustelussa tulee aina hyvää pohdintaa niin teknisestä kuin liiketoiminnan jatkuvuuden näkökulmasta. Aina alkuun tarkastellaan yhdessä asiakkaan liiketoimintaa ja keskustellaan millaisia haasteita historiassa on tullut ja miten niistä on selvitty. Tämän jälkeen lähdetään tarkentamaan yhdessä, miten ympäristö ja sen työkuormat sopivat DR-palvelun piiriin, ja minkälaista suojausta voidaan ja on viisasta lähteä rakentamaan.
Helpoin tapa vakuuttua Zerton toiminnasta on nähdä noin tunnin mittainen esitys, jossa näytämme konkreettisesti oikealla raudalla, miten suojaus ja palautuminen tapahtuu. Jatkon askelmerkit ovat monesti määritystyöpaja, jossa tarkemmin katsotaan suojattavien palvelinten määrä ja niiden muodostamat kokonaisuudet. Samalla voidaan jo tarkentaa hintatasoa sen muodostuessa suojattavien palvelinten- ja datan määristä. Määrityksen jälkeen rakennetaan usein koeympäristö, jossa replikoidaan muutamaa palvelinta ja voit rauhassa itse tutustua tuotteen ominaisuuksiin ja lupauksien pitävyyteen. Viimeinen vaihe on käyttöönotto, jossa laajennetaan replikointi koskemaan kaikkia aiemmin määriteltyjä palvelimia. Ei huolta, sekin operaatio on suojattavien palvelinten osalta katkoton ja taustalla tapahtuva.
Kun asia on sinulle ajankohtainen, tulemme mielellämme kertomaan lisää ja katsotaan yhdessä, miten Zerton avulla parannetaan yrityksenne liiketoiminnan jatkuvuutta entisestään.
Meidät tavoittaa: https://alpit.io/contact-us/