Tunaendelea kuzama katika ulimwengu unaovutia wa kubahatisha ... utatuzi wa magogo. KATIKA tulikubaliana juu ya maana ya maneno ya msingi na kuangalia muundo wa jumla wa Veeam kama maombi moja kwa jicho moja. Kazi ya hii ni kujua jinsi faili za logi zinaundwa, ni aina gani ya habari inayoonyeshwa ndani yao na kwa nini wanaonekana jinsi wanavyoonekana.
Unafikiri "magogo" haya ni nini? Kulingana na wengi, magogo ya maombi yoyote yanapaswa kupewa jukumu la aina ya chombo chenye uwezo wote ambacho wakati mwingi huota mahali pengine kwenye uwanja wa nyuma, lakini kwa wakati unaofaa huonekana bila kutarajia katika silaha zinazoangaza na huokoa kila mtu. Hiyo ni, zinapaswa kuwa na kila kitu, kutoka kwa makosa madogo katika kila sehemu hadi shughuli za hifadhidata za kibinafsi. Na hivyo kwamba baada ya kosa iliandikwa mara moja jinsi nyingine ya kurekebisha. Na hii yote inapaswa kutoshea katika megabytes kadhaa, hakuna zaidi. Ni maandishi tu! Faili za maandishi haziwezi kuchukua makumi ya gigabytes, nilisikia mahali fulani!
Kwa hivyo magogo
Katika ulimwengu wa kweli, kumbukumbu ni kumbukumbu tu ya taarifa za uchunguzi. Na nini cha kuhifadhi huko, wapi kupata habari kwa ajili ya kuhifadhi na jinsi ya kina inapaswa kuwa, ni juu ya watengenezaji wenyewe kuamua. Mtu hufuata njia ya minimalism kwa kuweka rekodi za kiwango cha ON / OFF, na mtu hutafuta kila kitu anachoweza kufikia kwa bidii. Ingawa pia kuna chaguo la kati na uwezo wa kuchagua kinachojulikana Kiwango cha Kuingia, wakati wewe mwenyewe unaonyesha jinsi maelezo ya kina unayotaka kuhifadhi na ni kiasi gani cha nafasi ya ziada ya diski =) VBR ina ngazi sita kama hizo, kwa njia. Na, niniamini, hutaki kuona kinachotokea kwa ukataji wa kina zaidi na nafasi ya bure kwenye diski yako.
Sawa. Tulielewa takribani tunachotaka kuokoa, lakini swali la halali linatokea: wapi kupata habari hii kutoka? Bila shaka, tunaunda sehemu ya matukio ya kujiandikisha kwa michakato yetu ya ndani. Lakini nini cha kufanya wakati kuna mwingiliano na mazingira ya nje? Ili kutoteleza kwenye kuzimu ya mikongojo na baiskeli, Veeam huwa haizuii uvumbuzi ambao tayari umevumbuliwa. Wakati wowote kuna API iliyotengenezwa tayari, kazi iliyojengwa ndani, maktaba, n.k., tutatoa upendeleo kwa chaguzi zilizotengenezwa tayari kabla ya kuanza kuweka uzio wetu. Ingawa ya mwisho pia inatosha. Kwa hivyo, wakati wa kuchambua kumbukumbu, ni muhimu kuelewa kwamba sehemu kubwa ya makosa huanguka kwenye ujumbe kutoka kwa API za watu wengine, simu za mfumo, na maktaba zingine. Katika kesi hii, jukumu la VBR linakuja kusambaza makosa haya kwa faili za kumbukumbu. Na kazi kuu ya mtumiaji ni kujifunza kuelewa ni mstari gani unatoka kwa nani, na ni nini huyu "nani" anajibika. Kwa hivyo ikiwa nambari ya makosa kutoka kwa logi ya VBR inakupeleka kwenye ukurasa wa MSDN, ni sawa na ni sawa.
Kama tulivyokubaliana hapo awali: Veeam ni programu inayoitwa SQL-msingi. Hii ina maana kwamba mipangilio yote, taarifa zote na kwa ujumla kila kitu ambacho ni muhimu tu kwa kazi ya kawaida - kila kitu kinahifadhiwa kwenye hifadhidata yake. Kwa hivyo ukweli rahisi: kile ambacho sio kwenye kumbukumbu kinawezekana zaidi kwenye hifadhidata. Lakini hii sio risasi ya fedha pia: vitu vingine haviko kwenye kumbukumbu za ndani za vifaa vya Veeam, wala kwenye hifadhidata yake. Kwa hivyo, unahitaji kujifunza jinsi ya kusoma magogo ya mwenyeji, magogo ya mashine ya ndani na magogo ya kila kitu kinachohusika katika mchakato wa kuhifadhi na kurejesha. Na pia hutokea kwamba taarifa muhimu haipatikani popote wakati wote. Hiyo ndiyo njia.
Baadhi ya mifano ya API kama hizo
Orodha hii hailengi kuwa kamili ya kipekee, kwa hivyo hakuna haja ya kutafuta ukweli wa mwisho ndani yake. Madhumuni yake ni kuonyesha tu API na teknolojia za wahusika wengine zinazotumiwa katika bidhaa zetu.
Hebu tuanze na VMware.
Kwanza kwenye orodha itakuwa vSphere API. Inatumika kwa uthibitishaji, kusoma safu, kuunda na kufuta vijipicha, kuomba habari kuhusu mashine, na mengi (mengi) zaidi. Utendaji wa suluhisho ni pana sana, kwa hivyo naweza kupendekeza Rejeleo la VMware vSphere API kwa toleo ΠΈ . Kwa matoleo zaidi ya sasa, kila kitu ni googled.
VIX API. Uchawi mweusi wa hypervisor, ambayo kuna tofauti . API ya VMware ya kufanya kazi na faili kwenye mwenyeji bila kuunganishwa nao kupitia mtandao. Chaguo la mwisho wakati unahitaji kuweka faili kwenye mashine ambayo hakuna njia bora ya mawasiliano. Ni maumivu na mateso ikiwa faili ni kubwa na seva pangishi imepakiwa. Lakini hapa sheria inafanya kazi kwamba hata 56,6 Kb / s ni bora kuliko 0 Kb / s. Katika Hyper-V, kitu hiki kinaitwa PowerShell Direct. Lakini hiyo ilikuwa tu kabla
vSpehere Web Services API Kuanzia vSphere 6.0 (takriban, tangu API hii ilianzishwa kwa mara ya kwanza kwenye toleo la 5.5) inatumika kufanya kazi na mashine za wageni na imechukua VIX karibu kila mahali. Kwa kweli, hii ni API nyingine ya kudhibiti vSphere. Kwa wale wanaopenda, napendekeza kusoma mwongozo.
VDDK (Virtual Disk Development Kit). Maktaba, ambayo ilijadiliwa kwa sehemu katika hili . Inatumika kusoma diski pepe. Mara moja ilikuwa sehemu ya VIX, lakini baada ya muda ilihamishwa kwenye bidhaa tofauti. Lakini kama mrithi, hutumia nambari za makosa sawa na VIX. Lakini kwa sababu fulani, hakuna maelezo ya makosa haya katika SDK yenyewe. Kwa hivyo, iligunduliwa kwa hakika kwamba makosa ya VDDK na misimbo mengine ni tafsiri tu kutoka kwa msimbo wa binary hadi decimal. Inajumuisha sehemu mbili - nusu ya kwanza ni habari isiyo na kumbukumbu kuhusu muktadha, na sehemu ya pili ni makosa ya jadi ya VIX / VDDK. Kwa mfano, ikiwa tunaona:
VDDK error: 21036749815809.Unknown error
Kisha tunabadilisha hii kwa hex kwa ujasiri na kupata 132200000001. Tunatupa tu mwanzo usio na taarifa wa 132200, na salio itakuwa msimbo wetu wa makosa (VDDK 1: Hitilafu isiyojulikana). Kuhusu makosa ya mara kwa mara ya VDDK, hivi karibuni kulikuwa na tofauti .
Sasa wacha tuangalie MAJINI.
Hapa, kila kitu ambacho ni muhimu zaidi na muhimu kwetu kinaweza kupatikana katika kiwango Mtazamaji wa Tukio. Lakini kuna catch moja: kulingana na mila ndefu, Windows haiingizi maandishi kamili ya kosa, lakini nambari yake tu. Kwa mfano, kosa la 5 ni "Ufikiaji umekataliwa", na 1722 ni "Seva ya RPC haipatikani", na 10060 ni "Muunganisho umeisha". Kwa kweli, ni vizuri ikiwa unakumbuka zile maarufu zaidi, lakini vipi kuhusu ambazo hazijaonekana hadi sasa?
Na ili maisha yasionekane kama asali hata kidogo, makosa pia huhifadhiwa katika fomu ya hexadecimal, na kiambishi awali 0x8007. Kwa mfano, 0x8007000e ni kweli 14, Nje ya Kumbukumbu. Kwa nini na kwa nani hii ilifanyika ni siri iliyofunikwa na giza. Hata hivyo, orodha kamili ya makosa inaweza kupakuliwa bila malipo na bila SMS kutoka .
Kwa njia, wakati mwingine kuna viambishi vingine, sio tu 0x8007. Katika hali ya kusikitisha kama hii, ili kuelewa HRESULT ("kushughulikia matokeo"), unahitaji kutafakari kwa undani zaidi. kwa watengenezaji. Katika maisha ya kawaida, sikushauri kufanya hivi, lakini ikiwa ghafla ulisisitiza ukuta au una hamu tu, sasa unajua nini cha kufanya.
Lakini wandugu huko Microsoft walituhurumia kidogo na walionyesha ulimwengu kama matumizi . Hiki ni kipande kidogo cha furaha ambacho kinaweza kutafsiri misimbo ya makosa kuwa ya kibinadamu bila kutumia Google. Inafanya kazi kama hii.
C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
ERROR_INTERNAL_ERROR winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"Swali la halali linatokea: kwa nini hatuandiki mara moja usimbuaji kwenye magogo, lakini tuache nambari hizi za ajabu? Jibu liko katika maombi ya wahusika wengine. Unapovuta simu ya WinAPI mwenyewe, sio ngumu kufafanua majibu yake, kwa sababu kuna simu maalum ya WinAPI kwa hili. Lakini kama ilivyotajwa tayari, kila kitu kinachokuja kwetu tu katika majibu huingia kwenye kumbukumbu zetu. Na hapa, ili kuichambua, italazimika kufuatilia kila mara mkondo huu wa fahamu, kuvuta vipande na makosa ya Windows kutoka kwayo, kughairi na kuzibandika nyuma. Wacha tuwe waaminifu, sio shughuli ya kufurahisha zaidi.
API ya Usimamizi wa Faili ya Windows kutumika kwa kila njia iwezekanavyo wakati wa kufanya kazi na faili. Kuunda faili, kufuta, kufungua kwa kuandika, kufanya kazi na sifa, na kadhalika na kadhalika.
zilizotajwa hapo juu PowerShell moja kwa moja kama analog ya VIX API katika ulimwengu wa Hyper-V. Kwa bahati mbaya, sio rahisi sana: vikwazo vingi juu ya utendaji, haifanyi kazi na kila toleo la mwenyeji na si kwa wageni wote.
RPC (Remote Procedure Call) Sidhani kama kuna mtu mmoja ambaye amefanya kazi na WIndows ambaye hajaona makosa yanayohusiana na RPC. Licha ya dhana potofu maarufu, hii sio itifaki moja, lakini itifaki yoyote ya seva ya mteja ambayo inakidhi idadi ya vigezo. Hata hivyo, ikiwa kuna hitilafu ya RPC katika kumbukumbu zetu, 90% ya wakati itakuwa hitilafu kutoka kwa Microsoft RPC, ambayo ni sehemu ya DCOM (Mfano wa Kipengee Kinachosambazwa). Unaweza kupata idadi kubwa ya nyaraka kwenye mada hii kwenye wavu, lakini sehemu kubwa ya hiyo imepitwa na wakati. Lakini ikiwa kuna hamu ya papo hapo ya kusoma mada, basi naweza kupendekeza nakala , na orodha ndefu .
Sababu kuu za makosa ya RPC katika kumbukumbu zetu ni majaribio yaliyoshindwa ya kuwasiliana kati ya vipengele vya VBR (seva > wakala, kwa mfano) na mara nyingi kutokana na matatizo ya mawasiliano.
Sehemu ya juu kati ya vilele vyote ni hitilafu Seva ya RPC haipatikani (1722). Kwa maneno rahisi, mteja hakuweza kuanzisha muunganisho na seva. Jinsi gani na kwa nini - hakuna jibu moja, lakini kwa kawaida ni tatizo na uthibitishaji au upatikanaji wa mtandao kwa bandari 135. Mwisho ni wa kawaida kwa miundombinu yenye ugawaji wa bandari yenye nguvu. Juu ya mada hii, kuna hata . Na Microsoft ina kutafuta sababu ya kushindwa.
Hitilafu ya pili maarufu zaidi: Hakuna vidokezo zaidi vinavyopatikana kutoka kwa ramani ya mwisho (1753). Kiteja cha RPC au seva imeshindwa kujipa lango. Kawaida hutokea wakati seva (kwa upande wetu, mashine ya wageni) imesanidiwa ili kutenga milango kutoka kwa safu nyembamba ambayo imekamilika. Na ukiingia kutoka kwa upande wa mteja (kwa upande wetu, seva ya VBR), hii inamaanisha kuwa VeeamVssAgent wetu ama haikuanza au haikusajiliwa kama kiolesura cha RPC. Kuna pia juu ya mada hii .
Kweli, ili kukamilisha makosa 3 ya Juu ya RPC, tukumbuke simu ya chaguo la kukokotoa ya RPC haikufaulu (1726). Inaonekana ikiwa muunganisho umeanzishwa, lakini maombi ya RPC hayachakatwa. Kwa mfano, tunaomba taarifa kuhusu hali ya VSS (ghafla hivi sasa mgodi wa kivuli unafanywa huko, na tunajaribu kupanda), na kwa kujibu kwetu, kimya na kupuuza.
Windows Tape Backup API inahitajika kufanya kazi na maktaba za tepi au anatoa. Kama nilivyosema mwanzoni: hatuna furaha kuandika madereva yetu wenyewe na kisha kuteseka kwa msaada wa kila kifaa. Kwa hivyo, vim haina madereva yake mwenyewe. Yote kwa njia ya API ya kawaida, msaada ambao unatekelezwa na wachuuzi wa vifaa wenyewe. Kuna mantiki zaidi, sawa?
SMB / CIFS Kwa mazoea, kila mtu anaziandika kando, ingawa si kila mtu anakumbuka kwamba CIFS (Mfumo wa Faili wa Kawaida wa Mtandaoni) ni toleo la kibinafsi la SMB (Kizuizi cha Ujumbe wa Seva). Kwa hivyo hakuna ubaya kwa kujumlisha dhana hizi. Samba tayari ni utekelezaji wa LinuxUnix, na ina upekee wake, lakini mimi hupunguka. Ni nini muhimu hapa: wakati Veeam anauliza kuandika kitu kwa njia ya UNC (serverdirectory), seva hutumia uongozi wa viendesha mfumo wa faili, ikiwa ni pamoja na mup na mrxsmb, kuandika kwa mpira. Ipasavyo, madereva haya pia yatatoa makosa.
Huwezi kufanya bila Winsock API. Ikiwa kitu kinahitajika kufanywa kwenye mtandao, VBR hufanya kazi kupitia API ya Soketi ya Windows, maarufu kama Winsock. Kwa hivyo ikiwa tunaona rundo la IP: Bandari kwenye logi, hii ndio. Nyaraka rasmi zina orodha nzuri ya iwezekanavyo .
zilizotajwa hapo juu WMI (Ala za Usimamizi wa Windows) ni aina ya API yenye nguvu ya kudhibiti kila kitu na kila mtu katika ulimwengu wa Windows. Kwa mfano, wakati wa kufanya kazi na Hyper-V, karibu maombi yote kwa mwenyeji hupitia. Kwa neno moja, jambo hilo haliwezi kubadilishwa kabisa na lina nguvu sana katika uwezo wake. Katika jaribio la kusaidia kujua wapi na nini kimevunjwa, chombo kilichojengwa cha WBEMtest.exe husaidia sana.
Na mwisho kwenye orodha, lakini sio muhimu sana - VSS (Uhifadhi wa Kivuli wa Kiasi). Mada hiyo haiwezi kumaliza na ya kushangaza kama vile nyaraka nyingi zimeandikwa juu yake. Nakala ya Kivuli inaeleweka kwa urahisi kama aina maalum ya picha, ambayo kimsingi ni. Shukrani kwake, unaweza kufanya chelezo-tumizi-thabiti katika VMware, na karibu kila kitu katika Hyper-V. Nina mipango ya kutengeneza nakala tofauti na itapunguza kwenye VSS, lakini kwa sasa unaweza kujaribu kusoma . Tu kuwa makini, kwa sababu. kujaribu kuelewa VSS katika flash inaweza kusababisha kuumia kwa ubongo.
Juu ya hili, labda, tunaweza kuacha. Ninazingatia kazi ya kuelezea mambo ya msingi yaliyokamilika, kwa hivyo katika sura inayofuata tayari tutaangalia kumbukumbu. Lakini ikiwa una maswali yoyote, jisikie huru kuwauliza katika maoni.
Chanzo: mapenzi.com