Tā kā es joprojām neesmu iepazīstinājis ar sevi vai savu bloga ideju, šo ierakstu es gribu sākt ar nelielu paskaidrojumu. Es grasos atspoguļot visas savas galvenās intereses, un tās ir salīdzinoši plašas, sniedzoties no ļoti tehniskiem jautājumiem līdz tīri cilvēciskiem. Tā nav pati labākā pieeja, jo drošāk ir rakstīt kādai konkrētai nišai, lai lasītājiem nebūtu jāsaskaras ar sevi neinteresējošiem ierakstiem, bet es gluži vienkārši negribu atstāt novārtā lietas, kas ir svarīgas man pašam. Tas nozīmē, ka mana bloga profils būs salīdzinoši eklektisks, jo ietvers būtiski atšķirīgas tēmas. Šis būs pirmais ieraksts par kaut ko tehnisku, kurā es paskaidrošu, kā izveidoju sev automātisku rezerves kopiju veidošanās kārtību. Tas ir paredzēts ar datoriem pieredzējušai mērķauditorijai, kurai nevajag visu paskaidrot soli pa solim. Pārējiem es varētu ieteikt apskatīties uz SyncBack bezmaksas versijām, kuras it kā esot visai vienkārši lietojamas.

Mans vietējais tīkls (LAN) sastāv no trīs datoriem: diviem stacionārajiem, no kuriem viens ir serveris, un viena portatīvā. Uz servera darbojas FreeBSD ar ZFS, ko es to izmantošu rezerves kopiju glabāšanai, un uz pārējiem datoriem ir Windows. Līdz šim es rezerves kopijas taisīju ar rokām, bet ir skaidrs, ka to vajag automatizēt, lai samazināt iespēju kļūdīties. Robotiem, es gribēju teikt, datoriem daudz labāk izdodas atcerēties lietas periodiski kā man.

Es zinu, ka daudzi atstāj šos jautājumus novārtā, jo diski tomēr parasti darbojas gadiem pirms nomirst. Loģiskās sekas tam ir tādas, ka ik pa laikam var dzirdēt, ka kādam ir pazuduši svarīgi dati. Es atzīšos, ka man pašam nav sveša sajūta, ka ar mani jau nu tas nevarētu notikt, bet es apzinos, cik neracionāli tas ir, tāpēc arī izlēmu to beidzot sakārtot.

Pirmais solis bija lejupielādēt bezmaksas HD Tune versiju un veikt diska S.M.A.R.T. īpašību diagnostiku. Vienkārši ir jāuzstāda un jāpalaiž HD Tune, jāizvēlas pārbaudāmais disks un Health cilne. Paskaidrojumus par atsevišķām īpašībām var izlasīt šajā Wikipedia tabulā. Manā gadījumā situācija izskatās drūma, jo ne tikai ir dažādas kļūdas, kas pats par sevi nozīmētu, ka disks var kuru katru mirkli aizceļot labākos medību laukos, bet šīs kļūdas arī pārsniedz ražotāja noteiktās kritiskās robežas. Faktiski, man ir aizdomas, ka tos vajadzētu apmainīt garantijā. Tas gan nenozīmē, ka veikt rezerves kopijas ir vērts tikai tad, ja disks ir tūlītējās briesmās, jo nelaime citreiz var nākt arī klusiņām.

Nākošais solis bija nokonfigurēt uz servera rsync(1) moduli, kurā glabāsies visi dati. Es gluži vienkārši paņēmu paraugu no noklusētā konfigurācijas faila un pievienoju tam “read only = no” rindiņu, lai būtu iespējams ierakstīt datus.

Tālāk es uz Windows darbstacijas caur Cygwin uzstādīju rsync, pievienoju Cygwin “bin” mapi pie sistēmas ceļa (PATH) mainīgā, uzstādīju Cygwin Unicode atbalsta ielāpu un izveidoju batch skriptu ar vairākām rsync rindiņām, kas saglabāja visas man svarīgās lietas uz rsync servera. Konkrētās komandas izskatījās aptuveni šādi:

rsync --delete-after --exclude-from=exclude.txt -ayq Downloads 10.0.0.2::backup"

Failiem es izmantoju absolūtos ceļus, un parametru nozīmes ir šādas:

• --delete-after parūpējas, lai uz servera neglabātos faili, kas uz vietējā datora ir izdzēsti. Tas ir nedaudz bīstami, jo, izdzēšot tos nejauši, tie nākošajā rezerves kopiju veidošanas reizē tiks izdzēsti arī no servera, bet es to risinu atsevišķi ar ZFS.
• --exclude-from norāda uz teksta failu ar failu nosaukumiem, ko nevajag saglabāt. Manā gadījumā tie ir Thumbs.db, ~* un *.tmp.
• -a nozīmē arhivēšanu un kopē norādīto mapi rekursīvi.
• -y ir “fuzzy” failu atpazīšana, kas izmanto heiristiku, lai mēģinātu nepārsūtīt par jaunu failus, kas ir, piemēram, tikai pārsaukti. Šī parametra dēļ ir jāizmanto --delete-after vienkārši --delete vietā, lai faili netiktu izdzēsti pirms tos var izmantot.
• -q nozīmē, ka šī komanda noritēs “klusi”, izņemot gadījumus, kad ir notikusi kāda kļūda.
• Downloads ir mape, kurai es gribu izveidot rezerves kopiju.
• 10.0.0.2 ir serveris un ::backup apzīmē rsync moduļa nosaukumu.

Nākošais solis bija pievienot izveidoto .bat skriptu pie automātiskajām Windows darbībām, kaut kā līdzīga cron(8) uz Unix-veidīgajām sistēmām. Tā kā šī ir Vista, es devos uz kontroles paneli, atvēru “System and Maintenance” un tur izvēlējos “Schedule tasks“. Tālāk vienkārši vajadzēja izvēlēties “Create Basic Task“, iestatīt laiku un citas opcijas un norādīt .bat faila atrašanās vietu. Pie opcijām es izvēlējos, lai skripts tiktu iedarbināts pat tad, ja noteiktajā laikā dators ir bijis izslēgts, lai nodrošinātos, ka rezerves kopijas ir tikušas izveidotas. Uz Windows XP šim procesam nevajadzētu īpaši atšķirties.

Tas arī bija viss. Es to biju izdarījis praktiski bez aizķeršanās, un pie Google tantes man bija jāvēršas tikai par rsync Unicode atbalstu uz Cygwin, kas izrādījās pavisam nesāpīgi atrisināms. Tagad man ir rezerves kopijas uz vietējā servera, un es apsveru svarīgākos failus katram gadījumam turēt arī attālināti. Faktiski, ar daļu no tiem es jau tā daru, izmantojot sava drauga serveri. Rezultāts ir tāds, ka man svarīgās lietas ir dublētas uz vairākiem diskiem un tie ir tik atšķirīgi, ka iespēja tiem visiem nomirt vienlaicīgi ir pavisam maza.

Jāpiezīmē, ka, kopējot lokālajā tīklā, var būt laba ideja atslēgt rsync algoritmu. Tas ir viltīgs veids, kā pārsūtīt tikai failu deltas (izmaiņas), nevis visus failus, bet var būt mazāk noderīgs, ja runa ir par LAN ātrumiem. Es ievēroju, ka man pārraide notika tikai ar 4 MiB/s, kas ir krietni lēnāk kā reizumis darbojas pat WAN (plašākais tīkls). Citiem vārdiem, vēl ir vieta eksperimentiem.