Veeam Log Diving: komponendid ja sõnastik

Meil Veeamis meeldib logid. Kuna enamik meie lahendustest on modulaarne, kirjutavad nad päris palju logisid. Arvestades, et meie tegevusala on teie andmete säilitamine (st rahuliku une tagamine), peavad logid mitte ainult fikseerima iga liigutuse, vaid tegema seda ka üsna põhjalikult. See on vajalik, et juhul, kui midagi juhtub, oleks selge, kuidas see "midagi" juhtus, kes on süüdi ja mida edaspidi teha. Siin on nagu kriminalistikaga: kunagi ei tea, milline pisiasi aitab sul leida Laura Palmersi mõrvari.

Seetõttu otsustasin alustada artiklite seeriat, kus järk-järgult räägin, mida me logides kirjutame, kus me neid hoiame, kuidas mitte hulluks minna nende struktuurist ja mida neis sees otsida.

Miks sari artikleid ja miks mitte kõik korraga ära kirjeldada?

Lihtsalt loetleda, milline logi kus asub ja mis seal on, on üsna tühine idee. Ja selle teabe ajakohasena hoidmisest mõelda on isegi hirmus. Kõikide Veeam Backup & Replication logide loetlemine on tabel, mis on mitme lehe suurune peene kirjakujudega. Ja tegelikult kehtib see ainult avaldamise ajaks, kuna järgmise plaastri väljaandmisel võivad ilmuda uued logid, muutuda võivad vanade säilitatavate andmete loogika jne. Seetõttu on palju kasulikum selgitada nende struktuuri ja sisu. See võimaldab paremini orienteeruda, kui lihtsalt nimede päheõppimine.

Seepärast, et mitte hüpata peadpidi tekstimere sügavusse, teeme selles artiklis muid ettevalmistusi. Seega täna me ei uuri loge, vaid lähme kaugelt: koostame glossaariumi ja arutame Veeami struktuuri logide genereerimise seisukohalt.

Glossaar ja žargoon

Siin tasub eelkõige vabandada nende ees, kes kaitsevad vene keele puhtust ja Ožegovi sõnaraamatust. Me kõik armastame oma emakeelt, kuid kergelt mõrvatu IT- tööstus töötab inglise keeles. Me ei ole seda välja mõelnud, vaid nii on ajalooliselt kujunenud. Ma ei ole süüdi, see tuli iseenesest (c)

Meie valdkonnas on anglicismide (ja žargooni) probleemil oma spetsiifilisus. Kui süütu sõna nagu «host» või «külaline» tähendab kogu maailmas juba ammu täiesti konkreetseid asju, siis ⅙ maapinnast jätkub kangelaste madistamine ja tõukamine sõnastikesse. Ja rangelt kohustuslik argument on «Aga meil tööl...».

Lisaks on olemas puhtalt meie terminoloogia, mis on iseloomulik just Veeami toodetele, kuigi mõned sõnad ja väljendid on muutunud laialdaselt kasutatavaks. Seetõttu lepime nüüd kokku, mida iga termin tähendab, ja edaspidi mõtlen sõna «külaline» all just seda, mis on selles peatükis kirjas, mitte seda, millega olete harjunud oma töökohal. Ja jah, see ei ole isiklikult minu soov, see on tööstuses kehtestatud terminid. Nendega võitlemine on mõttetu. Kuigi ma olen alati kommentaarides arvamusavalduste poolt.

Kahjuks on meie töös ja toodetes äärmiselt palju termineid, seega ei hakka ma neid kõiki loetlema. Ainult kõige põhilisemad ja vajalikud, et ellu jääda teabe meres varukoopiate ja logide kohta. Huvi korral võin samuti pakuda artiklit kollaatide kohta, kus ta tõi välja ka termini nimekirja, mis puudutab selle funktsionaalsuse osa.

Host (Hernia): Virtuaalsuse maailmas on see masin, millel on hüpervisor. Füüsiline, virtuaalne, pilve- — pole vahet. Kui hüpervisor (ESXi, Hyper-V, KVM jne) on millegil käivitatud, nimetatakse seda «millegiks» hostiks. Olgu see kümne rack'i klaster või teie sülearvuti poolte virtuaaliga labori jaoks — kui olete hüpervisori käivitanud, siis olete host. Sest hüpervisor hostib virtuaalmasinaid. On isegi legend, et VMware soovis kunagi saavutada tugevat assotsiatsiooni sõnaga host, seostades selle just ESXi-ga. Kuid see ei õnnestunud.

Kaasaegses maailmas on mõisted «host» ja «server» peaaegu ühesugused, mis tekitab suhtlemises teatud segadust, eriti kui jutt käib Windowsi infrastruktuurist. Seega võib igat masinat, millel asub mõni meie jaoks huvitav teenus, julgelt nimetada hostiks. Näiteks WinSocki logides tähistatakse sõnaga host kõike. Klasikaline «Host not found» on selle näide. Seega lähtume kontekstist, kuid peame meeles — virtuaalsuse maailmas on host see, kes hostib külalisi (selle kohta kaks rida allpool).

Kohalikest žargoonidest (peamiselt akronüümidest, antud juhul) tuleb meelde, et VMware on VI, vSphere on VC ja Hyper-V on HV.

Külastaja (Guest): Virtuaalne masin, mis töötab hostis. Siin ei ole isegi midagi seletada, kõik on nii loogiline ja lihtne. Kuid paljud püüavad siia tuua mingeid teisi tähendusi.

Miks? Ma ei tea.
Külastaja OS, vastavalt sellele, on külastusmasina operatsioonisüsteem. Ja nii edasi.

Varukoopia / Replikatsiooni Ülesanne (Backup / Replication Job): Puhas VMWare’i žargoon, mis tähistab ühte ülesannet. Varukoopia ülesanne = Backup job. Kuidas seda ilusti eesti keelde tõlkida – seda ei ole keegi välja mõelnud, seega kõik räägivad ‘job’ ära. Rõhk viimasele silbile.

Jah, niimoodi lihtsalt räägitakse ‘job’. Ja isegi kirjalikult nii kirjutatakse, ja kõik on hästi.
Igasugused Varukoopiad, Varukoopia Ülesanded jne, aitäh, aga ei ole vaja. Lihtsalt ‘job’, ja teid mõistetakse. Peamine on rõhk panna viimasele silbile.

Varukoopia (Backup, bäkap. Tõelistele vanadele fännidele on lubatud ka ‘bakaap’): Peale ilmse (kusagil asuv varukoopia andmetest) tähendab see veel ka ülesannet (kolm rida ülespoole, kui juba unustanud), mille tulemusena see varukoopia fail tekib. Ilmselt on inglise keele emakeelsetel liiga mugav pidevalt öelda ‘I ran my backup job’, seega nad ütlevad lihtsalt ‘I ran my backup’, ja kõik omavahel aru saavad. Pakun välja, et toetame seda imelist algatust.

Konsolideerimine (Consolidate): Termin, mis ilmus ESXi 5.0-s. Valik menüüs, mis tegeleb snapshots’idega, mis käivitab tegevuse nimetatud 'orphaned' snapshots’ide kustutamiseks. St snapshotsid, mis füüsiliselt on olemas, kuid on kadunud loogilisest struktuurist. Teoreetiliselt ei tohiks see protsess mõjutada menüüs kuvatavaid faile, kuid juhtub igasuguseid asju. Konsolideerimise protsessi sisu on see, et andmed snapshot’ist (child disk) kirjutatakse põhikettale (parent disk). Kettaste ühendamise protsessi nimetatakse ühendamiseks (merge). Kui on antud käsk konsolideerimiseks, siis võib snapshot’i teave kustutada andmebaasist enne, kui snapshot on ühendatud ja kustutatud. Ja kui snapshot’it ei õnnestunud mingil põhjusel kustutada, siis tekivad need samad orphaned snapshots’id. VMware'il onpole halb KB Ja me ka kunagi.

olen kirjutatud Habrisse (Habr).  Väga lai mõisted, kuid virtualiseerimise maailmas mõistetakse selle all kohta, kus hoitakse virtuaalmasinate faile. Igal juhul on vaja selgelt mõista konteksti ja kahtluste korral täpsustada, mida teie vestluspartner silmas pidas. 

Proxy (Proksi): Oluline on kohe mõista, et Veeam Proxy ei ole täpselt see, millega oleme harjunud interneti maailmas. Veeam'i toodete raames on see mingi entiteet, mis tegeleb andmete edastamisega ühest kohast teise. Kui mitte minna detailidesse, siis VBR on juhtserver ja proksi on selle tööloomad. Teisisõnu, proksi on masin, mille kaudu voolab liiklus ja millel on VBR komponentsid, mis aitavad liiklusel navigeerida. Näiteks edastada andmeid ühest kanalist teise või lihtsalt seotud oma ketastega (HotAdd režiim).

Repository (Repo):  Tehniliselt on see lihtsalt VBR andmebaasi kirje, mis näitab kohta, kus varukoopiad asuvad, ja kuidas sellele kohale ühenduda. Tegeliselt võib see olla nii lihtsalt CIFS jagamine kui ka eraldi ketas, server või pilves asuv ämbri. Taaskord, oleme kontekstis, kuid mõistame, et repo on lihtsalt koht, kus teie varukoopiad asuvad.

 Snapshot (SnaapsSHOT): Oxfordi grammatika armastajad eelistavad rääkida kes schnEpshot, kes schnApShot, kuid kooliõpetajate seas domineerib grammatikaliselt vale määratlus. Kui keegi ei tea – see on tehnoloogia, mis võimaldab taastada ketta oleku kindlal ajahetkel. See toimub kas ajutise I/O operatsioonide suunamise kaudu peamisest kettast – siis nimetatakse seda RoW (Redirect on Write) snaapshtiks – või kirjutatavate plokkide teisaldamise kaudu teie kettalt teisele – seda nimetatakse CoW (Copy on Write) snaapshtiks. Just tänu nende funktsioonide laiale rakendusele suudab Veeam oma varukoopiaime teostada. Tõepoolest, mitte ainult temaga, kuid see on järgnevate väljaannete teema.

ESXi dokumentatsiooni ja logide ümber valitseb segadus, ja snapshotide kontekstis võib leida nii snapshotid, redo logid kui isegi delta disk. Veeami dokumentatsioonis sellist segadust ei ole, ja snapshot on snapshot, samal ajal kui redo log on just REDO fail, mis on loodud sõltumatult non-persistent kettalt. REDO failid kustutatakse virtuaalmasina väljalülitamisel, seega nende segamine snapshotidega on vale tee.

Sünteetiline (Synthetic): Sünteetilised varukoopiad viitavad reverse incremental ja forever forward varukoopiatele. Kui te pole selle terminiga kokku puutunud, siis see on lihtsalt üks mehhanisme, mida kasutatakse varukoopiate ahela konverteerimiseks. Kuid logides võib kohata ka mõistet Transform, mis kasutatakse täiskopeerimise loomise kontekstis inkrementidest (synthetic full).

Ülesanne (Task): See on iga masina töötlemise protsess tööülesande raames. Küsimus on selles: kui teil on varukoopiate tööülesanne, kuhu on lisatud kolm masinat. Seega, iga masin töödeldakse eraldi ülesandes. Kokku on neli logi: peamine tööülesande kohta ja kolm ülesande kohta. Siiski on siin oluline nüanss: aja jooksul on sõna „ülesanne” muutunud liialt palju tähendusi omavaks. Kui räägime üldistest logidest, siis mõistame, et ülesanne on just VM. Kuid oma „ülesanded” on ka proxy ja repository juures. Seal võib see tähendada nii virtuaalset ketast, virtuaalset masinat kui ka kogu tööülesannet. Seega on oluline konteksti mitte kaotada.

Veeam %name% Teenus (Service):  Eduka varundamise nimel töötab korraga mitu teenust, mille nimekirja leiate tavapärasest haldustööriistast. Nende nimed peegeldavad üsna selgelt nende olemust, kuid nende seas on üks kõige olulisem — Veeam Backup Service, ilma milleta teised ei tööta.

VSS: Tehniliselt peaks VSS alati tähendama Microsoft Volume Shadow Copy Service'i. Tegelikult kasutatakse seda paljude poolt sünonüümina Application-Aware Image Processing'ile. Mis on loomulikult kategooriliselt vale, kuid see on lugu, millega seostatakse: „Iga maastur võib olla jeep ning sind mõistetakse.”

Fantastilised logid ja kohad, kus nad elavad

Soovin alustada seda peatükki suure saladuse paljastamisega — millisena kuvatakse logides aeg?

Mäleta:

• ESXi kirjutab alati logisid UTC+0 ajavööndisse.
• vCenter hoiab logisid oma ajavööndi järgi.
• Veeam hoiab logisid serveri aja ja ajavööndi põhjal, kus see asub.
• Kuid ainult Windowsi sündmused EVTX formaadis ei ole seotud millegagi. Kui neid avada, siis aeg arvestatakse ümber masina järgi, millel neid avatakse. Kõige mugavam variant, kuigi sellel on ka oma keerukused. Ainus märkimisväärne raskus on lokalite erinevus. See on praktiliselt garanteeritud tee loetamatute logideni. Jah, on võimalusi, kuidas seda parandada, kuid lepime lihtsalt kokku, et IT-s toimib kõik inglise keeles ja lepime alati kokku seente seadistamisel ingliskeelses lokaadis. Palun. 

Nüüd räägime siiski kohtadest, kus logid elavad, ja kuidas neid hankida. VBRi puhul on kaks lähenemist. 

Esimene variant sobib, kui te ei soovi otsida üldisest kruusast faile, mis on seotud just teie murega. Selle jaoks on meil eraldi wizard, kellele saab näidata konkreetset tööd ja konkreetset perioodi, mille jooksul logid vajate. Edasi läheb ta ise kaustadesse ning kogub kõik vajaliku ühte arhiivi. Kuidas ja kus seda otsida ja kuidas sellega töötada, on üksikasjalikult selgitatud selles KVs.

Kuid wizard kogub logisid mitte kõigist ülesannetest ja näiteks restoranide, failoverite või failbackide logide uurimise vajaduse korral suunduge kausta %ProgramData%/Veeam/Backup. See on VBRi peamine logide salvestuskoht ja %ProgramData% on peidetud kaust, mis on normaalne. Muide, vaikeasukoht on võimalik ümber määrata registri võtme abil, näiteks REG_SZ: LogDirectory HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication oksas.

Linuxi masinatel tuleks tööagentide logisid otsida aadressilt /var/log/VeeamBackup/, kui kasutatakse root- või sudo kontot. Kui selliseid privileege ei ole, otsige logisid kaustast /tmp/VeeamBackup. 

Veeam agent for %OS_name% logid tuleb otsida %ProgramData%/Veeam/Endpoint (või %ProgramData%/Veeam/Backup/Endpoint) ja /var/log/veeam vastavalt.

Kui kasutate Application-Aware Image Processing (mis on tõenäoliselt nii), siis olukord on veidi keerulisem. Teil on vaja meie abifailide logisid, mis on salvestatud virtuaalmasina sisse, ja VSS logisid. Kuidas ja kust neid rõõme hankida, on üksikasjalikult kirjeldatud selles artiklis. Ja loomulikult on olemas erinev artikkel nõutavate süsteemilogide kogumise kohta. 

Windowsi sündmusi on mugav koguda vastavalt selles KVs. Kui kasutate Hyper-V-d, siis on olukord keerulisem, kuna vajalikud on ka kõik tema logid harust Applications and Service Logs > Microsoft > Windows. Kuigi alati võite minna ka natuke tobedamat teed ja lihtsalt võtta kõik objektid %SystemRoot%\System32\winevt\Logs.

Kui teil installimise või uuendamise ajal midagi katki läheb, leiate kõik vajaliku kaustast %ProgramData%/Veeam/Setup/Temp. Kuigi ma ei varjaks, et OS-i sündmustest võib leida kasulikumat teavet kui nendest logidest. Ülejäänud huvitav teave asub %Temp% kaustas, kuid seal on enamasti installimise logid seotud tarkvaraga, nagu andmebaasid, .Net raamatukogud ja muu. Pea meeles, et Veeam installitakse msi-st ja kõik selle komponendid installitakse samuti eraldi msi paketina, isegi kui seda GUI-s ei kuvata. Seega, kui ühe komponendi installimine ebaõnnestub, peatub kogu VBR installimine. Seetõttu tuleb vaadata logisid ja uurida, mis täpselt läks katki ja millal.

Ja viimaseks elu nipiks: installimise ajal vea saamisel ärge kiirustage OK nuppu vajutama. Esiteks koguge logid, seejärel vajutage OK. Nii saate veahetke logi, ilma et see lõpuks prügi täis oleks.

Aeg-ajalt tuleb ka vSphere logidesse sisse vaadata. See on väga tänamatu ülesanne, kuid kui käised üles hyvi, tuleb teha ka sellist tööd. Lihtsaim variant on, et vajame vmware.log logisid, kus on kirjas virtuaalmootori sündmused, need asuvad .vmx faili lähedal. keerukama juhtumi korral avame Google'i ja otsime, kus teie hosti versiooni logid asuvad, sest VMware armastab seda kohta iga versiooni puhul muuta. Näiteks artikkel 7.0, aga siin on 5.5. vCenter logide jaoks korrake protsessi Google's otsides. Kuid üldiselt huvitavad meid hosti sündmuste logid hostd.log, vCenteri juhtimise all olevate hostide sündmused vpxa.log, tuum logid vmkernel.log ja autentimise logid auth.log. Ja eriti rasketel juhtudel võib abi tulla SSO logist, mis asub SSO kaustas.

Koormav? Segane? Hirmutav? Kuid see pole isegi pooleteist ääreline teave, millega meie tugi iga päev töötavad. Nad on tõeliselt ägedad.

Veeami komponendid

Ja lõpetuseks räägime veidi Veeam Backup & Replication komponentidest. Sest kui otsite valu põhjust, on hea aru saada, kuidas patsient on üles ehitatud.

Nii, nagu kõik kindlasti teavad, on Veeam Backup SQL-põhine rakendus. See tähendab, et kõik seadistused, kogu teave ja kõik, mis on vajalik normaalseks tööks, on kõik tema andmebaasis. Täpsemalt on neid kaks, kui räägime VBR-i ja EM-i kombinatsioonist: VeeamBackup ja VeeamBackupReporting, vastavalt. Nii see on: paigaldame veel ühe rakenduse — tekib veel üks andmebaas. Et mitte hoida kõiki mune ühes korvis.

Kuid et kogu see süsteem sujuvalt töötaks, vajame me teenuste ja rakenduste komplekti, mis ühendavad kõik komponendid ühte. Näiteks niimoodi see ühes mu laboris välja näeb:

Peamise dirigeerijana on Veeam Backup Service. Just tema vastutab teabe vahetamise eest andmebaasidega. Ta vastutab ka kõigi ülesannete käivitamise eest, tegeleb eraldatud ressursside orkestreerimisega ja toimib suhtluskeskusena erinevatele konsoolidele, agentidele ja muule. Ühesõnaga, temata ei saa kuidagi, kuid see ei tähenda, et ta teeb kõike üksi.

Selle elluviimisel aitab tal Veeam Backup Manager. See ei ole teenus, vaid ühing, mis tegeleb tööde käivitamisega ja jälgib nende seadistust. Backup service'i töölehik, millega ta ühendub hostidega, loob snapshots, jälgib säilitamise reegleid ja nii edasi.

Kuid naaseme teenuste loendi juurde. Veeam Broker Service. Ilmus v9.5 (ja see ei ole krüptomünte kaevandav tööriist, nagu mõned siis arvasid). Tegeleb VMware hostide andmete kogumise ja nende ajakohasena hoidmisega. Kuid ärge kiirustage kohe vihaste kommentaaridega, et me teid nuhitakse ja kõik teie kasutajanime/paroolid ülemusele edastatakse. Tegelikult on see natuke lihtsam. Kui käivitate varundamise, siis esiteks peate ühendama hostiga ja värskendama kõik tema struktuuri andmed. See on üsna aeglane ja kohmakas protsess. Mõelge vaid, kui kaua teie veebikeskkonnas sisse logimine aega võtab, ja pidage meeles, et seal arvestatakse ainult ülemist kihti. Ja seejärel peate avama kogu hierarhia soovitud kohta, muide. Ühesõnaga, kohutav. Kui käivitate kümme varundust, peab iga töö selle protseduuri läbi viima. Suurte infrastruktuuride korral võib see protsess võtta kümme minutit või kauem. Seetõttu otsustati sellele eraldi teenus välja töötada, mille kaudu oleks alati võimalik saada ajakohast teavet. See kontrollib ja skaneerib kogu lisatud infrastruktuuri käivitamisel ning püüab seejärel töötada ainult inkrementaalsete muudatuste tasemel. Nii et isegi kui käivitate samaaegselt sada varundust, küsivad nad kõik teavet meie vahendajalt ega koorma hoste oma päringutega. Kui olete ressursside pärast mures, siis meie arvutuste kohaselt vajavad 5000 virtuaalmasina jaoks vaid umbes 100 Mb mälu.

Edasi liigume Veeami konsool. Samuti Veeam Remote Console, samuti Veeam.Backup.Shell. See on see graafiline kasutajaliides, mida näeme ekraanipiltidel. Kõik on lihtne ja ilmne — konsooli saab käivitada kust tahes, peaasi, et see oleks Windows ja oleks ühendus VBR-serveriga. Üks asi, mida saab öelda: FLR-protsess mountib punktid lokaalsetesse süsteemidesse (s.o. masinasse, kus konsool on käivitatud). Ja erinevad Veeami uurijad käivituvad ka lokaalselt, kuna need on konsooli osa. Kuid see suunab mind juba sügavamasse arutellu…

Järgmine huvitav teenus — Veeami varunduskatalooge andmete teenus. Teenused nimega Veeam Guest Catalog Service on tuntud. See tegeleb failisüsteemide indekseerimisega külastusmasinatel ja täidab nende teadmistega kausta VBRCatalog. Kasutatakse ainult seal, kus indekseerimise võimalus on lubatud. Selle lubamine on mõistlik ainult siis, kui teil on Enterprise Manager. Seega, meie soovitus: ärge lubage indekseerimist lihtsalt niisama, kui teil ei ole EM-i. Hoidke oma närve ja tehnilise toe aega.

Teiste oluliste teenuste seast tasub välja tuua Veeam Installer Service, mille abil toimub vajalike komponentide edastamine ja installimine proksidesse, ladustamisruumidesse ja muudesse väravatesse. Tegelikult toob see vajalikud .msi paketid serveritesse ja viib nende installimise läbi. 

Veeam Data Mover — kasutab proksides (ja mitte ainult) käivitatavaid abiteenuseid andmete edastamiseks. Näiteks varundamisel loeb üks agent faile hosti andmestooridest, samas kui teine salvestab need hoolikalt varukoopiasse.

Erakordselt tahan mainida olulist asja, millele kliendid sageli reageerivad — see on teenuste ja programmide omaduste loendi teabe versioonide erinevus. Jah, nimekiri on sama, kuid versioonides võib olla täielik segadus. See ei ole visuaalselt meeldiv, kuid on täiesti normaalne, kui kõik töötab stabiilselt. Näiteks Installer teenusel on versiooninumber oluliselt madalam kui naaberteenustel. Kohutav ja õudne? Ei, kuna see ei paigalda end tervikuna, vaid uuendab lihtsalt oma DLL-i. Patchis v9.5 U4 toimus tugiteenuste jaoks õudne unenägu: kõigil teenustel olid uued versioonid, välja arvatud kõige olulisemal. Patchis U4b hõivas transportteenus kõiki teisi lausa kahe versiooniga (arvude järgi). Ja see on samuti normaalne — selles leiti tõsine viga, mistõttu sai see boonuse uuenduse võrreldes teistega. Seega, kokkuvõttes: versioonide erinevus VÕIB olla probleem, kuid kui erinevus on olemas ja kõik töötab hästi, siis see tõenäoliselt ongi nii. Kuid keegi ei keela teil seda tehnilise toe kaudu selgitada.

Need olid nn kohustuslikud või Mandatory teenused. Kuid on ka terve rida abiteenuseid, nagu Tape Service, Mount Service, vPowerNFS Service ja nii edasi.

Hyper-V puhul on põhimõtteliselt kõik sama, lihtsalt on olemas spetsiifiline Veeam Backup Hyper-V Integration Service ja oma draiver CBT töötamiseks.

Ja lõpus arutame, kes töötab virtuaalmasinates varundamise ajal. Pre- ja post-freeze skriptide käivitamiseks, šedou kopiate loomiseks, metadate kogumiseks, SQL tehingulogide töötlemiseks ja muuks kasutatakse Veeam Guest Helper. Ja kui failisüsteemide indekseerimine toimub, Veeam Guest Indexer . Need on ajutised teenused, mis käivitatakse varundamise ajaks ja eemaldatakse pärast seda.

Linuxi masinate puhul on kõik palju lihtsam, kuna süsteemil on palju sisseehitatud teeke ja võimalusi. Näiteks indekseerimine tehakse läbi mlocate.

Sellega on praegu kõik

Ma ei julge teid enam piinata ja lühike sissejuhatus Veeami tagaplaanisse on minu arvates lõpetatud. Jah, me ei ole isegi lähedale jõudnud logidele, kuid uskuge mind, et see teave, mis nendes esitatakse, ei näeks välja nagu seosetu teadvuse voog, on selline sissejuhatus täiesti vajalik. Logide juurde plaanin liikuda alles kolmandas artiklis, samas kui järgmise kavaga on selgitada, kes genereerib logisid, mis täpselt neis kajastub ja miks just nii, mitte teisiti.

Allikas: habr.com