{"id":97729,"date":"2020-10-21T08:42:22","date_gmt":"2020-10-21T06:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving"},"modified":"2020-10-21T08:42:22","modified_gmt":"2020-10-21T06:42:22","slug":"otkuda-berutsya-logi-veeam-log-diving","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Nga vijn\u00eb log\u00ebt? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nga<\/p>\n

Vazhdobot\u00eb e zhytjes son\u00eb n\u00eb bot\u00ebn interesante t\u00eb problemet t\u00eb zgjidhjes s\u00eb log\u00ebve. N\u00eb artikulli i m\u00ebparsh\u00ebm<\/a><\/noindex> kemi r\u00ebn\u00eb dakord mbi kuptimin e termaeve baz\u00eb dhe kemi hedhur nj\u00eb v\u00ebshtrim t\u00eb p\u00ebrgjithsh\u00ebm n\u00eb struktur\u00ebn e Veeam, si nj\u00eb aplikacion t\u00eb vet\u00ebm. Detyra n\u00eb k\u00ebt\u00eb \u2014 t\u00eb kuptojm\u00eb se si formohen skedar\u00ebt e log\u00ebve, \u00e7far\u00eb informacioni p\u00ebrmbajn\u00eb dhe p\u00ebrse duken ashtu si duken.<\/p>\n

\u00c7far\u00eb mendoni se jan\u00eb k\u00ebta \u00ablog\u00eb\u00bb? N\u00eb mendimin e shumic\u00ebs, log\u00ebve t\u00eb \u00e7do aplikacioni u \u00ebsht\u00eb dh\u00ebn\u00eb roli i nj\u00eb entiteti t\u00eb gjith\u00ebfuqish\u00ebm, i cili shumic\u00ebn e koh\u00ebs q\u00ebndron diku n\u00eb prapasken\u00eb, por n\u00eb momentin e duhur shfaqet nga askund n\u00eb kostum\u00eb t\u00eb ndritshme dhe shp\u00ebton t\u00eb gjith\u00eb. Dometh\u00ebn\u00eb, ata duhet t\u00eb p\u00ebrmbajn\u00eb gjith\u00e7ka, duke filluar nga gabimet m\u00eb t\u00eb vogla n\u00eb \u00e7do komponent, deri te transaksionet e ve\u00e7anta t\u00eb baz\u00ebs. Dhe q\u00eb pas nj\u00eb gabimi t\u00eb shkruhet menj\u00ebher\u00eb se si t\u00eb rregullohet. Dhe gjith\u00eb kjo duhet t\u00eb zmadhitet n\u00eb disa mega, jo m\u00eb shum\u00eb. Kjo \u00ebsht\u00eb thjesht tekst! Skedar\u00ebt tekstual\u00eb nuk mund t\u00eb peshojn\u00eb dhjet\u00ebra gigabajt, e kam d\u00ebgjuar ndonj\u00ebher\u00eb k\u00ebt\u00eb!<\/p>\n

Pra, log-\u00ebt<\/h2>\n

N\u00eb bot\u00ebn reale log-\u00ebt jan\u00eb thjesht nj\u00eb arkiv i informacionit diagnostik. Dhe \u00e7far\u00eb t\u00eb ruhet aty, nga t\u00eb merret informacioni p\u00ebr ruajtje dhe sa i detajuar duhet t\u00eb jet\u00eb, vendosin vet\u00eb zhvilluesit. Disa ndjekin rrug\u00ebn e minimalizmit duke ruajtur vet\u00ebm regjistrime t\u00eb nivelit ON\/OFF, nd\u00ebrsa disa tjer\u00eb mbledhin gjith\u00e7ka q\u00eb mund t\u00eb arrijn\u00eb. Megjithat\u00eb, ka edhe nj\u00eb variant t\u00eb nd\u00ebrmjet\u00ebm me mund\u00ebsin\u00eb p\u00ebr t\u00eb zgjedhur t\u00eb ashtuquajturin Logging Level, kur ti vet\u00eb tregon sa t\u00eb detajuar do t\u00eb doje t\u00eb ruaje informacionin dhe sa hap\u00ebsir\u00eb t\u00eb zbraz\u00ebt ke n\u00eb disqet =) N\u00eb VBR ka gjasht\u00eb nivele t\u00eb tilla, p\u00ebr m\u00eb tep\u00ebr. Besoni, nuk d\u00ebshironi t\u00eb shihni se \u00e7far\u00eb ndodh n\u00eb rastin e logimit maksimalisht t\u00eb detajuar me hap\u00ebsir\u00eb t\u00eb lir\u00eb n\u00eb disqet tuaja.<\/p>\n

Mir\u00eb. Ne e kuptuam p\u00ebrfundimisht se \u00e7far\u00eb d\u00ebshirojm\u00eb t\u00eb ruajm\u00eb, por lind pyetja legjitime: nga ku ta marrim k\u00ebt\u00eb informacion? Disa ngjarje p\u00ebr logim, sigurisht, i krijojm\u00eb ne vet\u00eb me proceset tona t\u00eb brendshme. Por \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb kur ndodh interaksioni me ambientin e jasht\u00ebm? Q\u00eb t\u00eb mos biem n\u00eb nj\u00eb kaos t\u00eb plot\u00eb t\u00eb zgjidhjeve t\u00eb p\u00ebrkohshme dhe ideve t\u00eb reja, Veeam ka tendenc\u00ebn t\u00eb mos shpik\u00eb ato q\u00eb jan\u00eb tashm\u00eb t\u00eb shpikura. P\u00ebrher\u00eb, kur ekziston nj\u00eb API i gatsh\u00ebm, nj\u00eb funksion i integruar n\u00eb sistem, nj\u00eb bibliotek\u00eb etj., ne do t'i japim p\u00ebrpar\u00ebsi mund\u00ebsive t\u00eb gatshme, p\u00ebrpara se t\u00eb fillojm\u00eb t\u00eb krijojm\u00eb zgjidhje t\u00eb sajuara. Megjithat\u00eb, ka mjaft prej t\u00eb fundit. Prandaj, gjat\u00eb analiz\u00ebs s\u00eb log\u00ebve \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptojm\u00eb se pjesa m\u00eb e madhe e gabimeve vjen nga mesazhet e API-ve t\u00eb jashtme, thirrjeve sistemike dhe biblioteka t\u00eb tjera. N\u00eb k\u00ebt\u00eb rast, roli i VBR p\u00ebrfshin d\u00ebrgimin e k\u00ebtyre gabimeve n\u00eb skedar\u00ebt e log\u00ebve ashtu si jan\u00eb. Dhe detyra kryesore e p\u00ebrdoruesit \u00ebsht\u00eb t\u00eb m\u00ebsoj\u00eb t\u00eb kuptoj\u00eb se cila rresht vjen nga kush, dhe p\u00ebr \u00e7far\u00eb p\u00ebrgjegj\u00ebs \u00ebsht\u00eb ky \u201ckush\u201d. Prandaj, n\u00ebse kodi i gabimit nga logu VBR ju \u00e7on n\u00eb faqen e MSDN, kjo \u00ebsht\u00eb normale dhe e sakt\u00eb.<\/p>\n

Si\u00e7 kemi r\u00ebn\u00eb dakord m\u00eb par\u00eb: Veeam \u00ebsht\u00eb nj\u00eb aplikacion i tipit SQL-based. K\u00ebshtu q\u00eb t\u00eb gjitha cil\u00ebsimet, gjith\u00eb informacioni dhe gjith\u00e7ka q\u00eb nevojitet p\u00ebr funksionimin normal \u2013 gjith\u00e7ka ruhet n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb tij. Pra, e thjesht: ajo q\u00eb nuk shfaqet n\u00eb loga, shum\u00eb mund t\u00eb jet\u00eb n\u00eb baz\u00eb. Por kjo nuk \u00ebsht\u00eb nj\u00eb zgjidhje magjike: disa informacione nuk ndodhen n\u00eb logat lokale t\u00eb komponent\u00ebve t\u00eb Veeam, as n\u00eb baz\u00ebn e saj. Prandaj, duhet t\u00eb m\u00ebsohemi t\u00eb studiojm\u00eb logat e hostit, logat e makin\u00ebs lokale dhe logat e gjith\u00e7kaje q\u00eb merr pjes\u00eb n\u00eb procesin e backup-it dhe restaurimit. Ngjithashtu ndodh edhe q\u00eb informacioni i nevojsh\u00ebm nuk \u00ebsht\u00eb askund. K\u00ebshtu \u00ebsht\u00eb rruga. <\/p>\n

Disa shembuj t\u00eb till\u00eb t\u00eb API-ve<\/h4>\n

Ky list\u00eb nuk ka p\u00ebr q\u00ebllim t\u00eb jet\u00eb gjithnj\u00eb e plot\u00eb, k\u00ebshtu q\u00eb mos e k\u00ebrkoni t\u00eb v\u00ebrtet\u00ebn n\u00eb instanc\u00ebn e fundit n\u00eb t\u00eb. Detyra e tij \u00ebsht\u00eb vet\u00ebm t\u00eb tregoj\u00eb API-t\u00eb dhe teknologjit\u00eb m\u00eb t\u00eb zakonshme t\u00eb jashtme, t\u00eb p\u00ebrdorura n\u00eb produktet tona.<\/p>\n

T\u00eb fillojm\u00eb me VMware<\/strong>. <\/p>\n

E para n\u00eb list\u00eb do t\u00eb jet\u00eb vSphere API<\/strong>. P\u00ebrdoret p\u00ebr autentikimin, leximin e hierarkis\u00eb, krijimin dhe eliminimin e snapshot-eve, k\u00ebrkimin e informacionit mbi makinat dhe shum\u00eb (shum\u00eb) gj\u00ebra t\u00eb tjera. Funksionaliteti i zgjidhjes \u00ebsht\u00eb shum\u00eb i gjer\u00eb, k\u00ebshtu q\u00eb t\u00eb gjith\u00eb ata q\u00eb jan\u00eb t\u00eb interesuar mund t'u rekomandoj  VMware vSphere API Reference p\u00ebr versionin 5.5<\/u><\/a><\/noindex> dhe 6.0<\/u><\/a><\/noindex>. P\u00ebr versionet m\u00eb aktuale, gjith\u00e7ka k\u00ebrkohet n\u00eb Google.<\/p>\n

VIX API<\/strong>. Magjia e zez\u00eb e hipervizorit, p\u00ebr t\u00eb cil\u00ebn ka nj\u00eb list\u00eb t\u00eb ve\u00e7ant\u00eb gabimesh<\/u><\/a><\/noindex>. VMware API p\u00ebr t\u00eb punuar me skedar\u00ebt n\u00eb host pa u lidhur me ta p\u00ebrmes rrjetit. Nj\u00eb opsion i fundit kur duhet t\u00eb vendos\u00ebsh nj\u00eb skedar n\u00eb makin\u00eb, p\u00ebr t\u00eb cil\u00ebn nuk ka nj\u00eb kanal m\u00eb t\u00eb mir\u00eb lidhjeje. Paraqet dhimbje dhe vuajtje, n\u00ebse skedari \u00ebsht\u00eb i madh dhe host-i \u00ebsht\u00eb i ngarkuar. Por k\u00ebtu zbatohen rregulli se edhe 56.6 Kb\/s \u00ebsht\u00eb m\u00eb mir\u00eb se 0 Kb\/s. N\u00eb Hyper-V, gj\u00eb e ngjashme quhet PowerShell Direct. Por kjo ka qen\u00eb deri n\u00eb shfaqjen e<\/p>\n

vSphere Web Services API<\/strong> Duke filluar nga vSphere 6.0 (afro, pasi p\u00ebr her\u00eb t\u00eb par\u00eb ky API u paraqit n\u00eb versionin 5.5) p\u00ebrdoret p\u00ebr t\u00eb punuar me makinat virtuale dhe tashm\u00eb pothuajse kudo ka z\u00ebvend\u00ebsuar VIX. N\u00eb thelb, ky \u00ebsht\u00eb nj\u00eb tjet\u00ebr API p\u00ebr menaxhimin e vSphere. Ata q\u00eb jan\u00eb t\u00eb interesuar mund t\u00eb rekomandojn\u00eb studimin e nj\u00eb<\/u><\/a><\/noindex> manuali t\u00eb shk\u00eblqyer. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Biblioteka, p\u00ebr t\u00eb cil\u00ebn \u00ebsht\u00eb folur pjes\u00ebrisht n\u00eb k\u00ebt\u00eb artikulli yn\u00eb<\/u><\/a><\/noindex>. P\u00ebrdoret p\u00ebr t\u00eb lexuar disqet virtuale. Disa koh\u00eb m\u00eb par\u00eb ishte pjes\u00eb e VIX, por me kalimin e koh\u00ebs \u00ebsht\u00eb nxjerr\u00eb n\u00eb nj\u00eb produkt t\u00eb ve\u00e7ant\u00eb. Megjithat\u00eb, si pasardh\u00ebs, p\u00ebrdor t\u00eb nj\u00ebjtat kode gabimi si VIX.  Por p\u00ebr nj\u00eb arsye t\u00eb caktuar, n\u00eb vete SDK nuk ka asnj\u00eb p\u00ebrshkrim t\u00eb k\u00ebtyre gabimeve. Prandaj, p\u00ebrmes eksperienc\u00ebs, u zbulua se gabimet VDDK me kode t\u00eb tjera jan\u00eb thjesht nj\u00eb translacion nga binar n\u00eb dekad\u00eb. Kjo p\u00ebrb\u00ebhet nga dy pjes\u00eb \u2013 ajo e par\u00eb p\u00ebrfaq\u00ebson informacionin e pa dokumentuar n\u00eb kontekst, nd\u00ebrsa pjesa e dyt\u00eb \u2013 gabimet tradicionale VIX\/VDDK. P\u00ebr shembull, n\u00ebse shohim:<\/p>\n

Gabim VDDK: 21036749815809.Gabim i panjohur<\/code><\/p>\n

Ajo sigurisht q\u00eb kthehet n\u00eb hex dhe marrim 132200000001. Fillimi jo-informatik 132200 thjesht e heqim, nd\u00ebrsa pjesa e mbetur do t\u00eb jet\u00eb kodi yn\u00eb i gabimit (VDDK 1: Gabim i panjohur). P\u00ebr gabimet m\u00eb t\u00eb zakonshme VDDK, sapo ishte realizuar nj\u00eb diskutim t\u00eb ve\u00e7ant\u00eb artikulli<\/u><\/a><\/noindex>.<\/p>\n

Tani do t\u00eb shqyrtojm\u00eb Windows<\/strong>. <\/p>\n

K\u00ebtu gjith\u00e7ka e nevojshme dhe e r\u00ebnd\u00ebsishme p\u00ebr ne mund t\u00eb gjendet n\u00eb standardin Event Viewer<\/strong>. Por ka nj\u00eb ngat\u00ebrrim: sipas nj\u00eb tradite t\u00eb vjet\u00ebr, Windows regjistron jo tekstin e plot\u00eb t\u00eb gabimit, por vet\u00ebm numrin e tij. P\u00ebr shembull, gabimi 5 \u00ebsht\u00eb \u201cQasje e ndaluar\u201d, nd\u00ebrsa 1722 \u00ebsht\u00eb \u201cServeri RPC nuk \u00ebsht\u00eb i disponuesh\u00ebm\u201d, e 10060 \u00ebsht\u00eb \u201cKoha e lidhjes skadoi\u201d. Sigurisht, \u00ebsht\u00eb mir\u00eb n\u00ebse e mban mend gabimet m\u00eb t\u00eb njohura, por si t\u00eb veprosh me ato q\u00eb nuk jan\u00eb par\u00eb m\u00eb par\u00eb? <\/p>\n

Dhe q\u00eb jeta t\u00eb mos duket krejt si mjalt\u00eb, gabimet gjithashtu ruhen n\u00eb form\u00ebn hexadecimale, me prefixin 0x8007. P\u00ebr shembull, 0x8007000e \u2014 n\u00eb t\u00eb v\u00ebrtet\u00eb \u00ebsht\u00eb 14, Out of Memory. Pse dhe p\u00ebr k\u00eb ishte b\u00ebr\u00eb k\u00ebshtu \u2014 \u00ebsht\u00eb nj\u00eb mister i mbuluar n\u00eb err\u00ebsir\u00eb. Megjithat\u00eb, lista e plot\u00eb e gabimeve mund t\u00eb shkarkohet falas dhe pa SMS nga devcentra<\/u><\/a><\/noindex>.<\/p>\n

P\u00ebr m\u00eb tep\u00ebr, ndonj\u00ebher\u00eb hasen edhe prefikse t\u00eb tjera, jo vet\u00ebm 0x8007. N\u00eb k\u00ebt\u00eb situat\u00eb t\u00eb trishtueshme p\u00ebr t\u00eb kuptuar HRESULT (\u201cresult handle\u201d) duhet t\u00eb zbresim edhe m\u00eb thell\u00eb n\u00eb dokumentacion<\/u><\/a><\/noindex> p\u00ebr zhvilluesit. N\u00eb jet\u00ebn e zakonshme nuk ju rekomandoj ta b\u00ebni k\u00ebt\u00eb, por n\u00ebse ndodhet n\u00eb presion ose thjesht jeni kurioz, tani e dini se \u00e7far\u00eb t\u00eb b\u00ebni.<\/p>\n

Por shok\u00ebt n\u00eb Microsoft na pan\u00eb me m\u00ebshir\u00eb dhe na ofruan nj\u00eb utilitar ERR<\/u><\/a><\/noindex>. Ky \u00ebsht\u00eb nj\u00eb cop\u00eb konsoli e lumtur q\u00eb di t\u00eb p\u00ebrkthej\u00eb kodet e gabimeve n\u00eb gjuh\u00ebn e zakonshme pa p\u00ebrdorur Google. Funksionon rreth k\u00ebshtu.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# p\u00ebr hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ndodhi nj\u00eb gabim i brendsh\u00ebm.\n# si nj\u00eb HRESULT: Serious: SUCCESS (0), FACILITY_NULL (0x0), Kodi 0x54f\n# p\u00ebr hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ndodhi nj\u00eb gabim i brendsh\u00ebm.\n# 2 ndeshje t\u00eb gjetura p\u00ebr \"0x54f\"<\/code><\/pre>\n
Nje pyetje legjitime shfaqet: p\u00ebrse ne nuk shkruajm\u00eb menj\u00ebher\u00eb shpjegim n\u00eb log, por i l\u00eb k\u00ebto kode t\u00eb mistershme? P\u00ebrgjigjja \u00ebsht\u00eb n\u00eb aplikacione t\u00eb pal\u00ebve t\u00eb treta. Kur ju vet\u00eb b\u00ebni thirrje p\u00ebr ndonj\u00eb WinAPI, shpjegimi i p\u00ebrgjigjes nuk \u00ebsht\u00eb i v\u00ebshtir\u00eb, sepse p\u00ebr k\u00ebt\u00eb ekziston nj\u00eb thirrje speciale WinAPI. Por si\u00e7 u tha, n\u00eb log-un ton\u00eb mb\u00ebrrin gjith\u00e7ka q\u00eb vjen n\u00eb p\u00ebrgjigjet tona. Dhe k\u00ebtu p\u00ebr shpjegim do t\u00eb duhej t\u00eb monitoronim vazhdimisht k\u00ebt\u00eb rrjedh\u00eb mendimesh, t\u00eb nxirrnim cop\u00ebza me gabime t\u00eb Windows-it, t\u2019i shpjegonim ato dhe t\u2019i vendosnim prapa. Le t\u00eb themi se nuk \u00ebsht\u00eb nj\u00eb aktivitet shum\u00eb arg\u00ebtues.<\/p>\n
Windows File Management API <\/strong>p\u00ebrdoret n\u00eb m\u00ebnyr\u00eb t\u00eb ndryshme gjat\u00eb pun\u00ebs me skedar\u00eb. Krijimi i skedar\u00ebve, fshirja, hapja p\u00ebr shkruar, puna me atributet dhe shum\u00eb t\u00eb tjera.<\/p>\n
T\u00eb p\u00ebrmendurit m\u00eb lart PowerShell Direct<\/strong> si nj\u00eb analog i VIX API n\u00eb bot\u00ebn e Hyper-V. Fatkeq\u00ebsisht, nuk \u00ebsht\u00eb aq fleksib\u00ebl: ka shum\u00eb kufizime n\u00eb funksionalitet, nuk punon me \u00e7do version t\u00eb host-it dhe aspak me t\u00eb gjith\u00eb mysafir\u00ebt.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Mendoj se nuk ka asnj\u00eb njeri q\u00eb ka punuar me Windows dhe nuk ka par\u00eb gabime q\u00eb lidhen me RPC. N\u00eb kund\u00ebrshtim me mitin popullor, kjo nuk \u00ebsht\u00eb nj\u00eb protokoll i vet\u00ebm, por \u00e7do protokoll klient-server q\u00eb p\u00ebrmbush nj\u00eb s\u00ebr\u00eb kriteresh. Megjithat\u00eb, n\u00ebse kemi nj\u00eb gabim RPC n\u00eb log-et tona, n\u00eb 90% t\u00eb rasteve do t\u00eb jet\u00eb nj\u00eb gabim nga Microsoft RPC, i cili \u00ebsht\u00eb pjes\u00eb e DCOM (Distributed Component Object Model). N\u00eb internet mund t\u00eb gjeni nj\u00eb sasi t\u00eb madhe dokumentacioni mbi k\u00ebt\u00eb tem\u00eb, por pjesa m\u00eb e madhe e saj \u00ebsht\u00eb shum\u00eb e vjetruar. Por n\u00ebse keni d\u00ebshir\u00eb t\u00eb thelloni k\u00ebt\u00eb tem\u00eb, mund t\u00eb rekomandoj artikuj \u00c7far\u00eb \u00ebsht\u00eb RPC?<\/u><\/a><\/noindex>, Si Funksionon RPC<\/u> <\/a><\/noindex>dhe nj\u00eb list\u00eb t\u00eb gjat\u00eb gabimete RPC<\/u><\/a><\/noindex>.<\/p>\n
Arsyet kryesore p\u00ebr shfaqjen e gabimeve RPC n\u00eb log-et tona \u2014 jan\u00eb p\u00ebrpjekjet e d\u00ebshtuara p\u00ebr nd\u00ebrveprimin midis komponent\u00ebve VBR (server > proxy, p\u00ebr shembull) dhe shpeshher\u00eb p\u00ebr shkak t\u00eb problemeve me komunikimin.<\/p>\n
Gabimi m\u00eb i r\u00ebnd\u00ebsish\u00ebm nga t\u00eb gjitha gabimet \u2014 \u00ebsht\u00eb gabimi The RPC server is unavailable (1722). N\u00eb terma t\u00eb thjesht\u00eb, klienti nuk arriti t\u00eb vendos\u00eb nj\u00eb lidhje me serverin. Si dhe pse \u2014 nuk ka nj\u00eb p\u00ebrgjigje t\u00eb vetme, por zakonisht \u00ebsht\u00eb nj\u00eb problem me autentifikimin ose me qasjen n\u00eb rrjet deri n\u00eb portin 135. Kjo \u00ebsht\u00eb karakteristike p\u00ebr infrastrukturat me caktimin dinamik t\u00eb porteve. Ka madje edhe nj\u00eb KV t\u00eb ve\u00e7ant\u00eb<\/u><\/a><\/noindex>. E p\u00ebr Microsoft \u2014 nj\u00eb udh\u00ebzues t\u00eb holl\u00ebsish\u00ebm<\/u><\/a><\/noindex> p\u00ebr gjetjen e shkaqeve t\u00eb defekteve.<\/p>\n
Gabimi i dyt\u00eb m\u00eb i njohur: There are no more endpoints available from the endpoint mapper (1753). Klienti ose serveri RPC nuk mund\u00ebn t\u00eb caktuan nj\u00eb port p\u00ebr veten e tyre. Zakonisht ndodh kur serveri (n\u00eb rastin ton\u00eb, makina e gazd\u00ebs) \u00ebsht\u00eb konfiguruar p\u00ebr caktimin dinamik t\u00eb porteve nga nj\u00eb gam\u00eb t\u00eb ngusht\u00eb, e cila ka p\u00ebrfunduar. Nd\u00ebrsa nga ana e klientit (n\u00eb rastin ton\u00eb, serveri VBR), kjo do t\u00eb thot\u00eb se VeeamVssAgent ton\u00eb ose nuk \u00ebsht\u00eb nisur, ose nuk \u00ebsht\u00eb regjistruar si nj\u00eb nd\u00ebrfaqe RPC. P\u00ebr k\u00ebt\u00eb tem\u00eb ka gjithashtu nj\u00eb KV t\u00eb ve\u00e7ant\u00eb<\/u><\/a><\/noindex>.<\/p>\n
Dhe p\u00ebr t\u00eb p\u00ebrfunduar Top-3 gabimeve RPC, le t\u00eb p\u00ebrmendim RPC function call failed (1726). Ky gabim shfaqet n\u00ebse lidhja \u00ebsht\u00eb krijuar, por k\u00ebrkesat RPC nuk p\u00ebrpunohen. P\u00ebr shembull, ne k\u00ebrkojm\u00eb informacion mbi statusin e VSS (ndoshta aty po b\u00ebhet nj\u00eb kopje kaq shpejt, nd\u00ebrsa ne po mundohemi ta marrim informacionin), dhe n\u00eb p\u00ebrgjigje marrim heshtje dhe injorim.<\/p>\n
Windows Tape Backup API <\/strong>nevojn\u00eb p\u00ebr t\u00eb punuar me bibliotekat ose disk\u00ebt kaset\u00eb. Si\u00e7 e kam p\u00ebrmendur n\u00eb fillim: t\u00eb shkruash driver\u00ebt e tu dhe t\u00eb vuash m\u00eb pas me mb\u00ebshtetjes e \u00e7do pajisjeje nuk na jep asnj\u00eb k\u00ebnaq\u00ebsi. Prandaj, Veeam-nuk ka asnj\u00eb driver t\u00eb tij. T\u00eb gjitha kalojn\u00eb p\u00ebrmes API-t standard, mb\u00ebshtetje t\u00eb cilit realizojn\u00eb vet\u00eb prodhuesit e pajisjeve. Ka shum\u00eb logjik\u00eb n\u00eb k\u00ebt\u00eb, apo jo?<\/p>\n
SMB\/CIFS<\/strong> T\u00eb gjith\u00eb shkruajn\u00eb aty pran\u00eb, megjithat\u00eb nuk jan\u00eb shum\u00eb ata q\u00eb e mbajn\u00eb mend se CIFS (Common Internet File System) \u2014 \u00ebsht\u00eb thjesht nj\u00eb version privat i SMB (Server Message Block). Prandaj nuk ka asgj\u00eb t\u00eb keqe n\u00eb p\u00ebrgjith\u00ebsimin e k\u00ebtyre koncepteve. K\u00ebshtu q\u00eb Samba \u2014 \u00ebsht\u00eb implementimi LinuxUnix, dhe atje ka disa ve\u00e7ori t\u00eb veta, por kjo \u00ebsht\u00eb nj\u00eb ndarje. \u00c7far\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme k\u00ebtu: kur Veeam k\u00ebrkon t\u00eb shkruaj\u00eb di\u00e7ka n\u00eb nj\u00eb rrug\u00eb UNC (serverdirectory), serveri p\u00ebrdor hierarkin\u00eb e drejtorive t\u00eb sistemit t\u00eb skedar\u00ebve, duke p\u00ebrfshir\u00eb mup dhe mrxsmb, p\u00ebr t\u00eb shkruar n\u00eb ndarjen. Padyshim, gabimet do t\u00eb gjenerohen gjithashtu nga k\u00ebto drejtorit\u00eb.<\/p>\n
Nuk mund t\u00eb kalojm\u00eb pa Winsock API<\/strong>. N\u00ebse duhet t\u00eb b\u00ebjm\u00eb di\u00e7ka p\u00ebrmes rrjetit, VBR punon p\u00ebrmes Windows Socket API, i njohur si Winsock. Pra, n\u00ebse shohim n\u00eb log bashkimin IP:Port, \u00ebsht\u00eb kjo. N\u00eb dokumentacionin zyrtar ka nj\u00eb list\u00eb t\u00eb mir\u00eb t\u00eb mund\u00ebsive i gabimeve<\/u><\/a><\/noindex>.<\/p>\n
T\u00eb p\u00ebrmendurit m\u00eb lart WMI<\/strong> (Windows Management Instrumentation) \u2014 \u00ebsht\u00eb nj\u00eb API all-powerful p\u00ebr menaxhimin e gjith\u00e7kaje n\u00eb bot\u00ebn Windows. P\u00ebr shembull, kur punoni me Hyper-V, pothuajse t\u00eb gjitha k\u00ebrkesat ndaj hostit ndodhin sakt\u00ebsisht p\u00ebrmes tij. N\u00eb nj\u00eb fjal\u00eb, \u00ebsht\u00eb nj\u00eb gj\u00eb e domosdoshme dhe shum\u00eb e fuqishme n\u00eb mund\u00ebsit\u00eb e saj. N\u00eb p\u00ebrpjekjet p\u00ebr t\u00eb ndihmuar t\u00eb kuptoni se ku dhe \u00e7far\u00eb ka d\u00ebshtuar, \u00ebsht\u00eb shum\u00eb e dobishme mjeti i p\u00ebrfshir\u00eb WBEMtest.exe.<\/p>\n
Dhe i fundit n\u00eb list\u00eb, por aspak i fundit n\u00eb r\u00ebnd\u00ebsi \u2014 VSS<\/strong> (Volume Shadow Storage). Tema \u00ebsht\u00eb aq e pasur dhe misteroze saq\u00eb \u00ebsht\u00eb shkruar shum\u00eb dokumentacion p\u00ebr t\u00eb. Kopja e Hijes \u00ebsht\u00eb m\u00eb e leht\u00eb p\u00ebr t'u kuptuar si nj\u00eb tip i ve\u00e7ant\u00eb i snapshot-it, me t\u00eb cilin praktikisht \u00ebsht\u00eb. Fal\u00eb saj, n\u00eb VMware mund t\u00eb b\u00ebhen backup-e t\u00eb konsistente me aplikacionin, nd\u00ebrsa n\u00eb Hyper-V, gati gjith\u00e7ka. Kam plane p\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb artikull t\u00eb ve\u00e7ant\u00eb me nj\u00eb p\u00ebrmbledhje mbi VSS, por deri at\u00ebher\u00eb mund t\u00eb provoni t\u00eb lexoni k\u00ebt\u00eb p\u00ebrshkrim<\/u><\/a><\/noindex>. Vet\u00ebm me kujdes, sepse p\u00ebrpjekja p\u00ebr t\u00eb kuptuar VSS me nj\u00eb shikim mund t\u00eb \u00e7oj\u00eb n\u00eb l\u00ebndime t\u00eb trurit.<\/p>\n
N\u00eb k\u00ebt\u00eb pik\u00eb, mund t\u00eb ndalojm\u00eb. E kam konsideruar t\u00eb p\u00ebrfunduar detyr\u00ebn p\u00ebr t\u00eb shpjeguar gj\u00ebrat m\u00eb themelore, k\u00ebshtu q\u00eb n\u00eb kapitullin e ardhsh\u00ebm do t\u00eb shikojm\u00eb n\u00eb loge. Por n\u00ebse keni pyetje t\u00eb mbetura, mos hezitoni t'i p\u00ebrmendni ato n\u00eb komentet.<\/p>\n<\/p>\n
Burimi: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d… \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433\u0430 \u043f\u043e \u043b\u043e\u0433\u0430\u043c. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0434\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438\u0441\u044c \u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0438 \u0431\u0430\u0437\u043e\u0432\u044b\u0445 \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u0432 \u0438 \u043e\u0434\u043d\u0438\u043c \u0433\u043b\u0430\u0437\u043a\u043e\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043e\u0431\u0449\u0443\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 Veeam, \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0417\u0430\u0434\u0430\u0447\u0430 \u043d\u0430 \u044d\u0442\u0443 — \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u043b\u043e\u0433 \u0444\u0430\u0439\u043b\u044b, \u0447\u0442\u043e \u0437\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0432 \u043d\u0438\u0445 \u043e\u0442\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0430 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442 \u043a\u0430\u043a \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442. \u041a\u0430\u043a \u0432\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u0447\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97730,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nga vijn\u00eb log\u00ebt? Veeam Log Diving | ProHoster","description":"Vazhdojm\u00eb zhytjen ton\u00eb n\u00eb bot\u00ebn fascinante t\u00eb logeve...","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0442\u043a\u0443\u0434\u0430 \u0431\u0435\u0440\u0443\u0442\u0441\u044f \u043b\u043e\u0433\u0438? Veeam Log Diving | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d...","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-21T06:42:22+00:00","article:modified_time":"2020-10-21T06:42:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97729","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:14:39","updated":"2022-09-30 13:30:55","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}