1.2.1 Datuak eta haien garrantzia ezagutzea

Babeskopiak zein daturen gainean egin behar ditugun jakiteko, enpresan erabiltzen diren datuak ezagutu behar ditugu: haien garrantzia eta kokapena. Adibidea: ez da gauza bera bezeroen datu-basean kudeatzen diren datuen garrantzia edo erabiltzaile baten PCko “Deskargak” direktorioarena.

Era berean, datu horien egungo tamaina ere ezagutu behar dugu, eta guztira zenbateko bolumena hartzen duten jakin. Zenbat eta handiagoa izan datuen tamaina, orduan eta handiagoa izango da babeskopiek hartuko duten espazioa.

Kontuan hartu beharreko beste alderdi bat da datu horiek jasaten dituzten aldaketak ezagutzea eta aldaketa horien bolumena estimatzea. Adibidea: ez da gauza bera datu-base batek egunean 10 bezero berri jasotzea edo gure online dendak orduko 15.000 salmenta jasotzea.

1.2.2 Babeskopiak hartzen duen espazioa

Babeskopia batek hartuko duen espazioa estimatzea erraza dirudi, baina ez da beti horrela; horregatik, lehen esan dugun bezala, datuak ezagutzea funtsezkoa da.

Kontuan hartu beharko dugu jatorrizko datuek zenbat okupatzen duten, zein backup estrategia erabiliko dugun eta jatorrizko datuetan egon daitekeen espazio-gehikuntza estimatu behar dugu.

Beraz, komeni da beti espazioa gorantz kalkulatzea, eta ahal dela espazio hori “beroan” handitzeko aukera izatea, babeskopiek egunero behar bezala funtziona dezaten.

1.2.3 Berreskuratu nahi dugun gutxieneko denbora-puntua

Posible da datuetan aldaketak egiten diren une berean eguneratzen diren babeskopiak izatea, baina sistema horiek martxan jartzea agian ez dago gure eskura (nola egiten diren ez dakigulako edo kostu handia dutelako).

Zenbait kasutan, enpresa batzuek datu batzuk galtzea onar dezakete, izan ere, kopiak “denbora errealean” egitea garestiagoa izan daiteke datu horiek berriro sortzea baino.

Adibidea: Enpresa batek agian ez du behar langileen fitxaketa-orduak gordetzen dituen datu-basearen babeskopia denbora errealean egitea; egun bateko datuak galtzea onargarria izan daiteke (babeskopia gauero egiten bada). Aldiz, marketinaren datu-basea denbora errealean babestu behar da.

1.2.4 Berreskuratu nahi dugun gehieneko denbora-puntua

Kontuan hartu beharreko beste alderdi garrantzitsu bat da datuak leheneratzeko zenbat denbora atzera joan nahi dugun pentsatzea. Ez da gauza bera duela ordubeteko datuak leheneratu nahi izatea, duela egun batekoak, aste batekoak edo urte batekoak; erabaki horrek eragina izango du babeskopia-estrategia osoan.

Horregatik, datuei merezi duten garrantzia eman behar zaie, eta oso litekeena da datu mota desberdinek gehieneko leheneratze-puntu desberdinak izatea.

Adibidea: Ez da gauza bera enpresa baten fakturazio-datuak (legeak agintzen du datu horiek gordetzea, adibidez 4 urtez), ia aldatzen ez den webgune baten datuak (astean behin egindako kopia batekin nahikoa izan daiteke) edo erabiltzaile baten karpeta pertsonala bere ekipoan (bere ekipoan enpresarentzat garrantzitsua den ezer gorde behar ez duenez, datu-galera bat onargarria izan liteke).

1.2.5 Babeskopiaren kokapena

Oso garrantzitsua da babeskopiaren kokapena zein izango den eta horrek izan ditzakeen ondorioak kontuan hartzea. Ikus ditzagun hainbat adibide:

• Babeskopia ekipo informatiko berean egitea erabakitzen badugu, elektrizitate-arazo batek jatorrizko datuak eta babeskopiak galtzea ekar dezake.

• Babeskopia jatorrizko datuak dauden ordenagailu-gela berean egiten badugu, gela horrek suntsitzen duen faktore baten eraginpean badago (sutea, lapurreta, …), datu guztiak galduko genituzke.

• Babeskopia bulego edo eraikin berean egitea erabakitzen badugu, aurreko puntuan bezala gerta daiteke.

• Babeskopia “hodeian” egitea erabakitzen badugu, babeskopia egiteko denbora eta datuak leheneratzeko denbora handitu daitezke.

• Babeskopia beste bulego batean egitea erabakitzen badugu, konexioaren menpe egongo gara; datuak zifratuta bidali beharko lirateke, eta babeskopia sortzeko eta leheneratzeko denborak ere kontuan hartu behar dira.

Ikus daitekeen bezala, aukera bakoitzak bere abantailak eta desabantailak ditu.

1.2.6 Babeskopia egiteko aurreikusitako denbora

Aurretik azaldutakoa kontuan hartuta, babeskopia egiteko behar den denbora oso garrantzitsua da, eta denborarekin alda daiteke. Ez da gauza bera megabyte gutxi batzuk edo hainbat gigabyte babestea.

Horregatik, gure babeskopiek zenbat denbora behar duten kontuan hartu behar dugu, behar bezala egiten direla ziurtatzeko eta denboran gainjarri ez daitezen.

1.2.7 Hondamendien aurkako berreskuratze-plana

Babeskopia bat izatea bezain garrantzitsua da balizko hondamendi baten aurrean plan bat izatea. Ez du zentzurik babeskopia bat izateak, baldin eta hura leheneratzeko asteak behar baditugu, kopien egoera ez dakigulako edo leheneratzea oso konplexua bada.

Beraz, oso garrantzitsua da hondamendien aurkako berreskuratze-plan eguneratu bat izatea, babeskopien kudeaketan aldaketarik egon den kontuan hartuko duena, egin beharreko urratsak jasoko dituena, etab.

Berreskuratze-plan hori noizean behin praktikan jarri beharko litzateke, oraindik baliagarria dela egiaztatzeko, eta hala ez bada, behar diren aldaketak egiteko.

Hondamendien aurkako berreskuratze-planak, gutxienez, honako hauek jaso beharko lituzke:

• Enpresan dauden babeskopien metodo eta estrategia desberdinak
  
• Babeskopiak egiten diren kokapenak
  
• Babeskopia egiten zaien datuen garrantzia
  
• Babeskopia egin zaien sistema bakoitza nola leheneratu
  
• Leheneraketak egiteko ordena eta, datuen garrantziaren arabera, lehentasunak

1.2.8 Datuak berreskuratzeko aurreikusitako denbora

Azken puntua, baina ez horregatik gutxiago garrantzitsua, datuak berreskuratzeko aurreikusitako denbora da.

Horregatik, datuak berreskuratzeko aurreikusitako denbora ezagutu behar dugu, langileekin, bezeroekin eta bestelakoekin denborak kudeatu ahal izateko.

Denbora hori, babeskopien tamaina bezala, aldatu egin daiteke denborarekin; beraz, noizean behin simulazioak egitea komeni da benetako berreskuratze-denborak zein diren egiaztatzeko.

Aurreko grafikoa kontuan hartuta:

RTO:

berreskuratze-denboraren helburua da (Recovery Time Objective), eta zerbitzua berriro martxan jartzeko behar den denbora da, edo gutxienez adostutako gutxieneko zerbitzua berrezartzeko behar dena. Zenbat eta txikiagoa izan berreskuratze-denbora, orduan eta hobe.

RPO:

berreskuratze-puntuaren helburua da (Recovery Point Objective), eta sistemak gorabehera gertatu aurreko zein denbora-puntura arte itzul daitezkeen adierazten du. Normalean babeskopiak egiten diren maiztasunak markatzen du. Berriz ere, zenbat eta T=0 puntutik gertuago egon, orduan eta hobe.

1.3.1 Fitxategiak kopiatzea

Metodo sinpleena izango litzateke. Datu garrantzitsuen kopia bat egingo dugu beste kokapen edo euskarri batean. Sistema honekin, denbora-tarte jakin bakoitzean fitxategiak gordetzen dira eta datuen kopia oso bat lortzen dugu.

Arazoa da ez dugula aukera izango fitxategi bat azken kopia baino lehenagoko egoerara berreskuratzeko. Hau da, babeskopia goizeko 6:00etan egiten bada, ezin izango dugu fitxategiaren aurreko egoera lortu. Erabiltzaileak 11:00etan fitxategia hondatzen badu, 6:00etako egoerara itzul gaitezke, baina ez atzoko egoerara.

1.3.2 Bloke-mailako sistema inkrementala

Aldatu diren bloke fisikoak bakarrik kopiatzean oinarritzen da. Jatorrizko fitxategia alde batetik gordeta eduki beharko dugu, eta hortik aurrera aldaketak bakarrik gordeko ditugu modu inkrementalean.

Fitxategia berreskuratzeko, lehenik jatorrizko fitxategi osoa leheneratu beharko dugu, eta ondoren bloke inkrementalak aplikatu interesatzen zaigun berreskuratze-puntura iritsi arte.

1.3.3 Sistema inkremental edo diferentzial bitarra

Aurrekoaren antzekoa da, baina oraingoan blokeak (1K, 4K, 8K…) erabili beharrean, zati inkrementala edo diferentziala maila bitarrean egiten da.

1.3.4 Fitxategien bertsioak

Fitxategien bertsionatzea hainbat modutan egin daiteke:

• Fitxategi-sistema erabiliz: badira fitxategi-sistemak fitxategi bat aldatzen denean automatikoki bertsio berri bat sortzen dutenak.

• Eskuzko bertsionatzea: erabiltzaileak fitxategiaren bertsio berri bat sortu nahi duenean, eskuz ekintza bat egin behar du bertsio berria gordetzeko.

1.4.1 Babeskopia oso anitzak

Metodo hau sinpleena litzateke, baina baita espazio gehien hartuko lukeena ere, eta ziurrenik denbora gehien beharko lukeena, kopiatu beharreko datuen arabera.

Metodo honetan, gorde nahi ditugun datuen kopia osoa egin genezake nahi dugun adina kokapenetan. Demagun fitxategi hondatu batetik 3 egun atzera berreskuratzeko aukera izan nahi dugula; horrek esan nahi du 3 kokapen desberdin izan beharko genituzkeela, eta egunero datuen babeskopia oso bat egingo genukeela. Adibidez:

• 1. kokapena: astelehenean lehen babeskopia osoa egingo genuke

• 2. kokapena: asteartean bigarren babeskopia osoa egingo genuke

• 3. kokapena: asteazkenean hirugarren babeskopia osoa egingo genuke

• 1. kokapena: ostegunean babeskopia osoa egingo genuke (asteleheneko datuak gainidatziz)

• …

Ikus daitekeenez, estrategia ziklikoa eta sinplea da, eta zenbait kasutan nahikoa izan daiteke. Hala ere, lehen aipatu bezala, egunero babeskopia oso bat egingo da; beraz, kontuan hartu behar dira behar den denbora, hartzen duen espazioa, …

1.4.2 Inkrementalak eta/edo diferentzialak

Normalean metodo ohikoena da, eta programa gehienek aukera hauek eskaintzen dituzte babeskopiak egiteko.

Babeskopia inkrementalak eta/edo diferentzialak erabiltzeak datuak puntu zehatz bateraino leheneratzeko aukera ematen du. Horregatik oso garrantzitsua da zenbat denborara arte berreskuratu nahi dugun kontuan hartzea; izan ere, ez da gauza bera astebete, hilabete bat edo urtebete atzera leheneratu nahi izatea, espazioaren kalkuluan eragin zuzena duelako.

Beraz, metodologia hau erabiltzean —ohikoena dena— espazioaren estimazioa nahiko zabala izan behar da, eta etorkizunean espazioaren hazkundea kontuan hartu behar da.

1.4.3 Estrategia pertsonalizatua

Aurretik aipatu den bezala, ingurune adina estrategia egon daitezke. Horregatik, gure datuen, gure ingurune teknologikoaren eta gure negozio-ereduaren arabera, estrategia propio bat sortu beharko dugu.

Metodo hau konplexuena izan daiteke, agian eskuz egin behar izango dugulako; hala ere, horrela bermatuko dugu backup egin behar ditugun datuen atal bakoitzari dagokion garrantzia emango diogula.

1.4.4 Programak uzten diguna

Backupak kudeatzeko programa bat erabiltzen badugu, azkenean programak eskaintzen dituen aukeretara mugatuta egongo gara. Aipatu den bezala, inkremental/diferentzial estrategia da gehien erabiltzen dena; beraz, programa gehienek aukera hori izan beharko lukete.

Programaren arabera, aukera hauek izan ditzakegu: estrategien konbinazioak egitea, kopiak urruneko sistemetara bidaltzea (hodeira, FTP bidez, SSH bidez…), egunean hainbat kopia egitea… Horregatik, gure esku geratzen da programa desberdinak aztertzea eta gure beharretara hobekien egokitzen dena aukeratzea.

2.1.1 Rsync urrunetik sinkronizatzeko

Dakigunez, ez genuke inoiz segurtasun-kopiarik egin behar lokalean disko gogor berean, ezta ekipo berean eduki ere; beraz, beharrezkoa da beste zerbitzari batzuetatik edo beste zerbitzarietara segurtasun-kopiak egin ahal izatea.

Imajinatu /home/sistemas karpeta partekatu bateko datuak 10.40.30.200 urruneko zerbitzarira kopiatu nahi ditugula, eta kopia bat /home/backups karpetan utzi:

ruben@vega:~$ rsync -av /home/sistemas  root@10.40.30.200:/home/backups

Komando honekin sinkronizazioa egingo dugu urruneko zerbitzarira, SSH erabiliz eta root erabiltzailearekin konektatuz. Komandoaren atal desberdinen azalpena:

• rsync sinkronizazioa egiteko erabiltzen dugun programa da.

• -av sinkronizazioa artxibo moduan eta “verbose” moduan egiten duten parametroak dira (zer sinkronizatzen ari den erakusten du).

• /home/sistemas sinkronizatuko ditugun jatorrizko datuak dauden direktorioa da.

• root urruneko zerbitzarira konektatzeko erabiliko dugun erabiltzailea da.

• @10.40.30.200: SSH bidez konektatuko garen zerbitzaria da kopia egiteko. KONTUZ! Garrantzitsua da “@” ikurra eta amaierako “:” jartzea.

• /home/backups sinkronizatutako datuen kopia utziko dugun tokia da.

Aipatu den bezala, rsync-ek SSH erabiliko du urruneko konexioa egiteko; beraz, datuak modu seguru eta zifratuan bidaliko dira.

2.1.2 Urruneko datuak eskuratzea

Sinkronizazioa alderantzizko ordenan egin nahi badugu, hau da, backup zerbitzarian egonda urruneko zerbitzari batetik datuak ekarri nahi baditugu, komandoa honakoa izango litzateke:

root@backups:~# rsync -av 10.40.30.5:/home/sistemas  /home/backups

Kasu honetan, backup zerbitzarian egonda, 10.40.30.5 zerbitzaritik datuak ekarriko ditugu. Kasu honetan, zerbitzariaren IP helbidearen aurretik ez dugu erabiltzailea jarri; beraz, konexioa une honetan erabiltzen ari garen erabiltzailearekin egingo da, kasu honetan root.