Networker jälle

 Ikka Networkeriga maadlemine. Kõik varukoopia tegemised üle võetud ja nüüd avastamist kui palju. Kui varem kloonimist ei kasutatud, siis nüüd vaatasin, et miks peaks nädalalõpus koopiat mõnest save set'ist pea kolm korda tegema. Regulaarne ehk igapäevane, nädalalõpu oma ja kuu lõpus kuu oma. Peale varukoopiate asja ülevõtmist hakkas see häirima ja uurisin kloonimise varianti ning leidsin, et parem see kasutusele võtta. Varukoopia käib nädala lõpuni tavaliselt ja viimastest nädala lõpus tehtavatest täisvarukoopiatest teen nädala lõpus hoopis klooni teistele lintidele. Ja kuu lõpus teen veel teise klooni samadest asjadest kolmandatele lintidele või siis klooni nädalalõpu kloonist. Kumb variant mugavam tundub.
-----------------------------------------------------------
  Märkus iseendale: paistab, et kloon kloonist variant on natuke lollikindlam ja võtab vähem aega. Sai just natuke hooletu oldud ning läks lintidele 3 save set'i topelt. Poleks probleemi polnud, kui nende save set'ide maht poleks kokku nii 1.8 TB . Ja kirjutamiskiirus lindile DD pealt on nii 40-80MB/sek versus üle 200 MB/sek, mis on lindilt lindile tegemise puhul.
mminfo query vajalike save set'ide jaoks:

mminfo -o n -q "pool=week clone,savetime>10/27/12,savetime<10/30/12" -r ssid,cloneid,name,totalsize | uniqln -

(uniqln sorteerib välja ainult unikaalsed read)
-----------------------------------------------------------

  Leidsin ka, et Networkeri GUI'st ei saa kloonimise protsesse ära katkestada, selleks peab hoopis  jobquery ja jobkill utiliite kasutama. Kasutades infot kohast http://nsrd.info/blog/2011/03/17/killing-scheduled-cloning-operations/

# jobquery
jobquery> show name:; job id:; job state:
jobquery> print type: clone job; job state: ACTIVE;
                      job id: 4929644;
                   job state: ACTIVE;
                        name: clone.linux clones;

jobquery> quit

# jobkill -j 4929644 

Ja tööle pandud kloonimise töö, mille jaoks linti ei saanud sise panna, saigi katkestatud.

  Sain ka DD voluumi osas targemaks. Hakkas teine täis saama ja peaaegu aasta vanad save set'id istusid peal ning ei kustutatud midagi ära. Algselt oli DD voluumi jaks pandud retention time aasta ning Recycling Auto. Sellise konfi juures ei saanud vanu save set'e Recycled staatusesse panna. Ühendasin DD voluumi lahti, Networkeri GUI's määrasin DD voluumi Recycle variandi Manual'iks ning sain hakata vanemaid save set'e Recycled olekusse panema. Kõigepealt sai 6 kuu vanused save set'id välja võetud. Esialgu ülevaatlik pilt:

mminfo -q "volume=ddvolume.001,savetime<6 months ago" -r savetime,ssid,client,name,level,state

Siis ainult SSID'd faili:

mminfo -q "volume=ddvolume.001,savetime<6 months ago" -r ssid > ssids.txt

Peale seda panin save set'id Recyclable olekusse(kuigi seda vist poleks vaja olnud):

for /f %i in (ssids.txt) do (nsrmm -o recyclable -S %i)

Järgnevalt kustutasin Networkeri andmebaasist save set'ide info ära:

for /f %i in (ssids.txt) do (nsrmm -dPy -S %i & nsrmm -dy -S %i)

Ning lõpuks DD voluumi pealt ruumi juurde:

nsrclone -P -W ddvolume.001

Kõige lõpuks siis DD enda peal filesys clean start ning ruumiprobleem selleks korraks lahendatud. Kuna save set'ide aegumine sai DD voluumi peal paika pandud, siis edaspidi saab asja cmd failiga atuomatiseerida, võttes mminfo'ga välja kõik 6 kuud vanad ja Recycled olekus olevad save set'id:

mminfo -q "volume=ddvoluum.001,ssrecycle,savetime<6 months ago" -r ssid > ssids.txt

SSD kettaste kasutusaeg

On kettakast ja SSD kettad sees. Kasutuses 3..4 kuud ja juba tunnistas kettakast ühe SSD ketta kõlbmatuks ning nõuab väljavahetamist. Esimese hooga paneb imestama, sest nii kiiresti pole veel ühtegi tavalist ketast kettakastis katki läinud, kuid tõenäoliselt on kettakastidel rangemad standardid ja ketas vahetatakse välja juba siis, kui on kahtlus, et see võib probleeme tekitada. Probleemne ketas otseselt katki ei olnud, aga oli tekkinud piisavalt palju (40) vigu nimega "Drive Recovered Error". Tegemist ei paista olevat "non recoverable" vigadega ja tõenäoliselt kodukasutuses olles laseks selle kettaga rahulikult edasi, aga nagu näha, kettakastile ei sobi enam. Standardid kõrged.

Viimasel paaril nädalal on üsna palju aega võtnud Networker, Networker, Networker ja jälle Networker. Varukoopiate ajastatuse paikapanek, lintide pool'id, mida kirjutada lintidele, mida DataDomain'i peale, kloonid, varukoopiate tegemiste jälgimine jne. Ja muidugi dokumenteerimine, mis kuidas töötab ja kuhu läheb. Mis veel nikerdamist vajab on igasugune raportite saatmine ja et tulemustest oleks hea ülevaade.

Tarkvara bugid rõõmustavad jälle, teevad igapäevase töö huvitavamaks. Oli vaja Exchange 2010 saada varundama Datadomain seadme peale. Varukoopia tegemiseks on Networker 7.6 SP3 ja Networker Module For Microsoft Applications. Viimasest hetkel kasutuses versioon 2.3. Kõik Networkeri kliendid/grupid/DD seadmed/poolid jne paigas ja konfigureeritud, aga varukoopiat ei toimu. Niisama failidest veel tehti varukoopiat, aga "APPLICATIONS:\Microsoft Exchange 2010" save set ei toiminud kuidagi. Sai siis igasugustes logides tuhnitud kuni jõudsin failin nmm.raw log failini Exchange serveril, mis ütles niipalju et:

An error occurred while checking the event log for data corruption errors. RM was unable to read the event log. 
Additional info: Cannot open log Application on machine .. Windows has not provided an error code..

Nagu windowsi puhul ikka, sai restarti proovitud, kuid kuna see ei aidanud, läksin ja vaatasin EMC lehelt, mis infot sealt leiab. Ja leidsin, et neil "Cumulative Fix package" 2.3 jaoks väljas ja ka uus 2.4 versioon olemas. 2.3 paranduste readme fail vihjas, et tegemist võib olla tarkvara veaga.

NW135291 - Exchange 2010 backup fails if there are any old JET errors in the event viewer

Eeldasin, et 2.4's on samad parandused sees ja installisin uue versiooni ning peale uut serveri restarti hakkas varukoopia ilma probleemideta tööle. Vähem linti kirjutamist jälle igapäevaselt.