ලඝු-සටහන් පැමිණෙන්නේ කොහෙන්ද? වීම් ලොග් කිමිදීම

අපි ලඝු-සටහන් මගින් අනුමාන කිරීමේ ... දෝශ නිරාකරණයේ සිත් ඇදගන්නාසුළු ලෝකයට අපගේ ගිල්වීම දිගටම කරගෙන යන්නෙමු. තුල පෙර ලිපිය අපි මූලික පදවල අර්ථයට එකඟ වූ අතර Veeam හි සමස්ත ව්‍යුහය එක් ඇසකින් තනි යෙදුමක් ලෙස බැලුවෙමු. මේ සඳහා කර්තව්‍යය වන්නේ ලොග් ගොනු සෑදෙන්නේ කෙසේද, ඒවායේ කුමන ආකාරයේ තොරතුරු ප්‍රදර්ශනය කරන්නේද සහ ඒවා පෙනෙන ආකාරයට පෙනෙන්නේ මන්දැයි සොයා බැලීමයි.

ඔබ සිතන්නේ මෙම "ලොග්" මොනවාද? බොහෝ දෙනාට අනුව, ඕනෑම යෙදුමක ලඝු-සටහන්වලට සර්වබලධාරී වස්තුවක භූමිකාව පැවරිය යුතු අතර එය බොහෝ විට ගෙවත්තේ කොතැනක හෝ වෘක්ෂලතා කරයි, නමුත් නියම මොහොතේ දිදුලන සන්නාහයෙන් කොතැනකවත් නොපෙනී ගොස් සියල්ලන්ම බේරා ගනී. එනම්, එක් එක් සංරචකයේ ඇති සුළු දෝෂවල සිට තනි දත්ත සමුදා ගනුදෙනු දක්වා සෑම දෙයක්ම ඒවායේ අඩංගු විය යුතුය. දෝෂයෙන් පසු එය වෙනත් නිවැරදි කරන්නේ කෙසේදැයි වහාම ලියා ඇත. මේ සියල්ල මෙගාබයිට් කිහිපයකින් ගැලපේ, තවත් නැත. එය කෙටි පණිවිඩයක් පමණි! පෙළ ගොනු වලට ගිගාබයිට් දහයක් ගත නොහැක, මම එය කොහේ හරි අසා ඇත!

ඉතින් ලඝු-සටහන්

සැබෑ ලෝකයේ, ලඝු-සටහන් යනු රෝග විනිශ්චය තොරතුරු සංරක්ෂිතයක් පමණි. එහි ගබඩා කළ යුත්තේ කුමක්ද, ගබඩා කිරීම සඳහා තොරතුරු ලබා ගත යුත්තේ කොතැනින්ද සහ එය කෙතරම් සවිස්තරාත්මක විය යුතුද යන්න තීරණය කිරීම සංවර්ධකයින් සතු ය. යමෙක් ON / OFF මට්ටමේ වාර්තා තබා ගැනීමෙන් අවමවාදයේ මාවත අනුගමනය කරයි, සහ යමෙකු තමාට ළඟා විය හැකි සෑම දෙයක්ම කඩිසරව ලබා ගනී. ඊනියා ලොග් කිරීමේ මට්ටම තේරීමේ හැකියාව සමඟ අතරමැදි විකල්පයක් ද ඇතත්, ඔබට ගබඩා කිරීමට අවශ්‍ය විස්තරාත්මක තොරතුරු සහ ඔබට කොපමණ අමතර තැටි ඉඩ ප්‍රමාණයක් තිබේද යන්න ඔබම සඳහන් කරන විට =) VBR සතුව එවැනි මට්ටම් හයක් ඇත. තවද, මාව විශ්වාස කරන්න, ඔබගේ තැටියේ නිදහස් ඉඩක් සහිත වඩාත් සවිස්තරාත්මක ලොගින් වීමෙන් කුමක් සිදුවේදැයි බැලීමට ඔබට අවශ්ය නැත.

හොඳයි. අපට සුරැකීමට අවශ්‍ය දේ අපි දළ වශයෙන් තේරුම් ගත්තෙමු, නමුත් නීත්‍යානුකූල ප්‍රශ්නයක් පැන නගී: මෙම තොරතුරු ලබා ගන්නේ කොහෙන්ද? ඇත්ත වශයෙන්ම, අපි අපගේ අභ්‍යන්තර ක්‍රියාවලීන් මගින් අපව ලොග් කිරීම සඳහා සිදුවීම්වල කොටසක් සාදන්නෙමු. නමුත් බාහිර පරිසරය සමඟ අන්තර් ක්රියාවක් ඇති විට කුමක් කළ යුතුද? කිහිලිකරු සහ බයිසිකල් වල නිරය තුලට නොපැමිණීම සඳහා, Veeam දැනටමත් නිර්මාණය කර ඇති නව නිපැයුම් සොයා නොගැනීමට නැඹුරු වේ. සූදානම් කළ API, බිල්ට්-ඉන් ශ්‍රිතය, පුස්තකාලය යනාදිය ඇති සෑම විටම, අපගේ ප්‍රතිවිරෝධතාවලට වැට බැඳීමට පෙර අපි සූදානම් කළ විකල්ප සඳහා මනාප ලබා දෙන්නෙමු. දෙවැන්න ද ප්රමාණවත් වුවද. එබැවින්, ලඝු-සටහන් විශ්ලේෂණය කිරීමේදී, දෝෂ වල සිංහයාගේ කොටස තෙවන පාර්ශවීය APIs, පද්ධති ඇමතුම් සහ වෙනත් පුස්තකාලවල පණිවිඩ මත වැටෙන බව වටහා ගැනීම වැදගත්ය. මෙම අවස්ථාවෙහිදී, VBR හි කාර්යභාරය මෙම දෝෂයන් ලොග් ගොනු වෙත යොමු කිරීම වෙත පැමිණේ. පරිශීලකයාගේ ප්‍රධාන කර්තව්‍යය වන්නේ කුමන රේඛාව කාගෙන්ද යන්න සහ මෙම “කවුද” වගකිව යුත්තේ කුමක් දැයි තේරුම් ගැනීමට ඉගෙන ගැනීමයි. එබැවින් VBR ලොගයෙන් දෝෂ කේතයක් ඔබව MSDN පිටුවකට ගෙන යන්නේ නම්, එය හොඳයි සහ නිවැරදියි.

අප කලින් එකඟ වූ පරිදි: Veeam යනු ඊනියා SQL මත පදනම් වූ යෙදුමකි. මෙයින් අදහස් වන්නේ සියලු සැකසුම්, සියලු තොරතුරු සහ සාමාන්යයෙන් සාමාන්ය ක්රියාකාරීත්වය සඳහා පමණක් අවශ්ය වන සියල්ල - සෑම දෙයක්ම එහි දත්ත ගබඩාවේ ගබඩා කර ඇති බවයි. එබැවින් සරල සත්යය: ලඝු-සටහන් වල නොමැති දේ බොහෝ විට දත්ත ගබඩාවේ ඇත. නමුත් මෙය රිදී උණ්ඩයක් ද නොවේ: සමහර දේවල් Veeam සංරචකවල දේශීය ලොගවල හෝ එහි දත්ත ගබඩාවේ නොමැත. එමනිසා, ඔබ සත්කාරක ලොග්, දේශීය යන්ත්‍රයේ ලොග් සහ උපස්ථ සහ ප්‍රතිසාධන ක්‍රියාවලියට සම්බන්ධ සෑම දෙයකම ලඝු-සටහන් අධ්‍යයනය කරන්නේ කෙසේදැයි ඉගෙන ගත යුතුය. අවශ්‍ය තොරතුරු කොතැනකවත් නොතිබීම ද සිදු වේ. ඒ මාර්ගයයි. 

එවැනි API සඳහා උදාහරණ කිහිපයක්

මෙම ලැයිස්තුව සුවිශේෂී ලෙස සම්පූර්ණ කිරීම අරමුණු කර නැති නිසා එහි ඇති අවසාන සත්‍යය සෙවීමට අවශ්‍ය නොවේ. එහි පරමාර්ථය වන්නේ අපගේ නිෂ්පාදනවල භාවිතා වන වඩාත් පොදු තෙවන පාර්ශවීය API සහ තාක්ෂණයන් පෙන්වීම පමණි.

අපි පටන් ගනිමු VMware. 

ලැයිස්තුවේ පළමුවැන්නා වනු ඇත vSphere API. සත්‍යාපනය, ධූරාවලිය කියවීම, ස්නැප්ෂොට් සෑදීම සහ මැකීම, යන්ත්‍ර පිළිබඳ තොරතුරු ඉල්ලා සිටීම සහ තවත් බොහෝ දේ (ඉතා බොහෝ) සඳහා භාවිතා වේ. විසඳුමේ ක්‍රියාකාරිත්වය ඉතා පුළුල් වේ, එබැවින් මට අනුවාදය සඳහා VMware vSphere API යොමු නිර්දේශ කළ හැකිය 5.5 и 6.0. වඩාත් වත්මන් අනුවාද සඳහා, සියල්ල ගූගල් කර ඇත.

VIX API. හයිපර්වයිසර්ගේ කළු මැජික්, ඒ සඳහා වෙනම එකක් ඇත දෝෂ ලැයිස්තුව. ජාලය හරහා ඒවාට සම්බන්ධ නොවී ධාරකයේ ගොනු සමඟ වැඩ කිරීම සඳහා VMware API. ඔබට වඩා හොඳ සන්නිවේදන නාලිකාවක් නොමැති යන්ත්‍රයක ගොනුවක් තැබීමට අවශ්‍ය වූ විට අවසාන විකල්පයකි. ගොනුව විශාල නම් සහ ධාරකය පටවා ඇත්නම් එය වේදනාව සහ දුක් වේදනා වේ. නමුත් මෙහි රීතිය ක්‍රියාත්මක වන්නේ 56,6 Kb / s පවා 0 Kb / s ට වඩා හොඳ බවයි. Hyper-V හි, මෙම දෙය PowerShell Direct ලෙස හැඳින්වේ. නමුත් ඒ මීට පෙර පමණි

vSpehere වෙබ් සේවා API vSphere 6.0 සිට (ආසන්න වශයෙන්, මෙම API පළමු වරට 5.5 අනුවාදයෙන් හඳුන්වා දුන් බැවින්) එය ආගන්තුක යන්ත්‍ර සමඟ වැඩ කිරීමට භාවිතා කරන අතර සෑම තැනකම පාහේ VIX ආදේශ කර ඇත. ඇත්ත වශයෙන්ම, මෙය vSphere කළමනාකරණය සඳහා තවත් API වේ. උනන්දුවක් දක්වන අය සඳහා, මම අධ්යයනය කිරීමට නිර්දේශ කරමි отличный අත්පොත. 

VDDK (Virtual Disk Development Kit). මෙහි අර්ධ වශයෙන් සාකච්ඡා වූ පුස්තකාලය ලිපියයි. අතථ්‍ය තැටි කියවීමට භාවිතා කරයි. වරෙක එය VIX හි කොටසක් වූ නමුත් කාලයත් සමඟ එය වෙනම නිෂ්පාදනයක් බවට පත් විය. නමුත් උරුමක්කාරයෙකු ලෙස, එය VIX වැනි දෝෂ කේත භාවිතා කරයි. නමුත් කිසියම් හේතුවක් නිසා, SDK තුළම මෙම දෝෂ පිළිබඳ විස්තරයක් නොමැත. එමනිසා, වෙනත් කේත සමඟ VDDK දෝෂයන් ද්විමය සිට දශම කේතය දක්වා පරිවර්තනයක් පමණක් බව ආනුභවිකව සොයා ගන්නා ලදී. එය කොටස් දෙකකින් සමන්විත වේ - පළමු භාගය සන්දර්භය පිළිබඳ ලේඛනගත නොකළ තොරතුරු වන අතර දෙවන කොටස සාම්ප්‍රදායික VIX / VDDK දෝෂ වේ. උදාහරණයක් ලෙස, අපි දකිනවා නම්:

VDDK error: 21036749815809.Unknown error

එවිට අපි නිර්භීතව මෙය hex බවට පරිවර්තනය කර 132200000001 ලබා ගනිමු. අපි සරලව 132200 හි තොරතුරු රහිත ආරම්භය ඉවතලන අතර ඉතිරිය අපගේ දෝෂ කේතය වනු ඇත (VDDK 1: නොදන්නා දෝෂය). නිතර නිතර VDDK දෝෂ ගැන, මෑතකදී වෙනම එකක් විය ලිපියක්.

දැන් අපි බලමු වින්ඩෝස්.

මෙන්න, අපට වඩාත්ම අවශ්ය හා වැදගත් සියල්ල සම්මතයෙන් සොයාගත හැකිය සිද්ධි නිරීක්ෂකයා. නමුත් එක් අල්ලා ගැනීමක් තිබේ: දිගු සම්ප්රදායට අනුව, වින්ඩෝස් දෝෂයේ සම්පූර්ණ පාඨය ලොග් නොකරයි, නමුත් එහි අංකය පමණි. උදාහරණයක් ලෙස, දෝෂය 5 "ප්‍රවේශය ප්‍රතික්ෂේප කර ඇත", සහ 1722 "RPC සේවාදායකය නොමැත", සහ 10060 "සම්බන්ධතා කාලය අවසන්" වේ. ඇත්ත වශයෙන්ම, ඔබට වඩාත්ම ප්‍රසිද්ධ ඒවා මතක නම් එය විශිෂ්ටයි, නමුත් මෙතෙක් නොදුටු ඒවා ගැන කුමක් කිව හැකිද? 

ජීවිතය කිසිසේත් මී පැණි මෙන් නොපෙනෙන පරිදි, දෝෂ 0x8007 උපසර්ගය සමඟ ෂඩාස්‍රාකාර ස්වරූපයෙන් ද ගබඩා වේ. උදාහරණයක් ලෙස, 0x8007000e ඇත්ත වශයෙන්ම 14, මතකයෙන් බැහැර වේ. මෙය සිදු කළේ ඇයි සහ කවුරුන් සඳහාද යන්න අඳුරෙන් වැසී ගිය අභිරහසකි. කෙසේ වෙතත්, සම්පූර්ණ දෝෂ ලැයිස්තුවක් නොමිලේ සහ කෙටි පණිවුඩයකින් තොරව බාගත කළ හැකිය devcenter.

මාර්ගය වන විට, සමහර විට 0x8007 පමණක් නොව වෙනත් උපසර්ග ඇත. එවැනි කණගාටුදායක තත්වයක් තුළ, HRESULT ("ප්‍රතිඵල හසුරුව") තේරුම් ගැනීමට, ඔබ ඊටත් වඩා ගැඹුරින් සොයා බැලිය යුතුය. ලේඛනගත කිරීම සංවර්ධකයින් සඳහා. සාමාන්‍ය ජීවිතයේදී, මෙය කිරීමට මම ඔබට උපදෙස් දෙන්නේ නැත, නමුත් ඔබ හදිසියේම බිත්තියට තද කළහොත් හෝ කුතුහලයෙන් සිටින්නේ නම්, දැන් ඔබ කුමක් කළ යුතු දැයි ඔබ දන්නවා.

නමුත් මයික්‍රොසොෆ්ට් එකේ සහෘදයෝ අපි ගැන ටිකක් අනුකම්පා කරලා ලෝකෙට ප්‍රයෝජනයක් පෙන්නුවා ERR. මෙය Google භාවිතා නොකර දෝෂ කේත මිනිසා බවට පරිවර්තනය කළ හැකි කොන්සෝල සතුටේ කුඩා කොටසකි. ඒක වැඩ කරන්නේ මෙහෙමයි.

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"

නීත්‍යානුකූල ප්‍රශ්නයක් පැන නගී: අපි වහාම විකේතනය ලඝු-සටහන් වෙත නොලියන්නේ ඇයි, නමුත් මෙම අද්භූත කේතයන් තබන්නේ ඇයි? පිළිතුර තෙවන පාර්ශවීය යෙදුම්වල ඇත. WinAPI ඇමතුම් කිහිපයක් ඔබ විසින්ම ඇද ගන්නා විට, එහි ප්‍රතිචාරය විකේතනය කිරීම අපහසු නොවේ, මන්ද මේ සඳහා විශේෂ WinAPI ඇමතුමක් පවා ඇත. නමුත් දැනටමත් සඳහන් කර ඇති පරිදි, ප්‍රතිචාර වලින් පමණක් අපට ලැබෙන සෑම දෙයක්ම අපගේ ලොග් වලට ඇතුල් වේ. මෙන්න, එය විකේතනය කිරීම සඳහා, යමෙකුට මෙම විඥාන ප්‍රවාහය නිරන්තරයෙන් අධීක්ෂණය කිරීමට සිදුවනු ඇත, එයින් වින්ඩෝස් දෝෂ සහිත කෑලි ඇදගෙන ඒවා විකේතනය කර නැවත ඇලවිය යුතුය. වඩාත් උද්යෝගිමත් ක්‍රියාකාරකම නොව අවංක වෙමු.

වින්ඩෝස් ගොනු කළමනාකරණ API ගොනු සමඟ වැඩ කිරීමේදී හැකි සෑම ආකාරයකින්ම භාවිතා වේ. ගොනු නිර්මාණය කිරීම, මකා දැමීම, ලිවීම සඳහා විවෘත කිරීම, ගුණාංග සමඟ වැඩ කිරීම සහ යනාදිය.

ඉහත සඳහන් PowerShell Direct Hyper-V ලෝකයේ VIX API හි ප්‍රතිසමයක් ලෙස. අවාසනාවකට, එතරම් නම්‍යශීලී නොවේ: ක්‍රියාකාරීත්වයේ බොහෝ සීමාවන්, එය සත්කාරකයේ සෑම අනුවාදයක් සමඟම ක්‍රියා නොකරන අතර සියලුම අමුත්තන් සමඟ නොවේ.

ආර්පීසී (දුරස්ථ ක්‍රියාපටිපාටිය ඇමතුම) RPC සම්බන්ධ දෝෂ නොදැකපු එකෙක්වත් WIndows එක්ක වැඩ කරලා ඇති කියලා මම හිතන්නේ නැහැ. ජනප්‍රිය වැරදි වැටහීමක් තිබියදීත්, මෙය තනි ප්‍රොටෝකෝලයක් නොව, පරාමිති ගණනාවක් තෘප්තිමත් කරන ඕනෑම සේවාදායක-සේවාදායක ප්‍රොටෝකෝලයකි. කෙසේ වෙතත්, අපගේ ලොග් වල RPC දෝෂයක් තිබේ නම්, එය 90% ක්ම DCOM (Distributed Component Object Model) හි කොටසක් වන Microsoft RPC වෙතින් වන දෝෂයකි. ඔබට මෙම මාතෘකාව පිළිබඳ විශාල ලේඛන ප්‍රමාණයක් ජාලයෙන් සොයාගත හැකිය, නමුත් එහි සිංහ කොටස තරමක් යල් පැන ගිය ය. නමුත් මාතෘකාව අධ්යයනය කිරීමට දැඩි ආශාවක් තිබේ නම්, එවිට මට ලිපි නිර්දේශ කළ හැකිය RPC යනු කුමක්ද?, කෙසේද RPC වැඩ සහ දිගු ලැයිස්තුව RPC දෝෂ.

අපගේ ලොග් වල RPC දෝෂ ඇතිවීමට ප්‍රධාන හේතු වන්නේ VBR සංරචක අතර සන්නිවේදනය කිරීමට අසාර්ථක උත්සාහයන් (උදාහරණයක් ලෙස සේවාදායකය > ප්‍රොක්සි) සහ බොහෝ විට සන්නිවේදන ගැටළු නිසා ය.

සියලුම මුදුන් අතර ඉහළම දෝෂය වන්නේ RPC සේවාදායකය නොමැත (1722). සරලව කිවහොත්, සේවාදායකයාට සේවාදායකය සමඟ සම්බන්ධතාවයක් ඇති කර ගැනීමට නොහැකි විය. කෙසේද සහ ඇයි - තනි පිළිතුරක් නොමැත, නමුත් සාමාන්‍යයෙන් එය සත්‍යාපනය සමඟ හෝ 135 වරායට ජාල ප්‍රවේශය සමඟ ගැටලුවකි. දෙවැන්න ගතික වරාය පැවරුම් සහිත යටිතල පහසුකම් සඳහා සාමාන්‍ය වේ. මෙම මාතෘකාව මත, පවා ඇත වෙනම HF. ඒ වගේම Microsoft සතුයි විශාල මාර්ගෝපදේශය අසාර්ථක වීමට හේතුව සොයා ගැනීමට.

දෙවන වඩාත් ජනප්‍රිය දෝෂය: අන්ත ලක්ෂ්‍ය සිතියම්කරුගෙන් (1753) තවත් අන්ත ලක්ෂ්‍ය නොමැත. RPC සේවාලාභියා හෝ සේවාදායකය තමාට වරායක් පැවරීමට අසමත් විය. සාමාන්‍යයෙන් සිදු වන්නේ සේවාදායකය (අපගේ නඩුවේදී, ආගන්තුක යන්ත්‍රය) අවසන් වූ පටු පරාසයක සිට ගතිකව වරායන් වෙන් කිරීමට වින්‍යාස කර ඇති විටය. තවද ඔබ සේවාදායක පාර්ශවයෙන් (අපගේ නඩුවේදී, VBR සේවාදායකය) ලොග් වන්නේ නම්, මෙයින් අදහස් කරන්නේ අපගේ VeeamVssAgent RPC අතුරුමුහුණතක් ලෙස ආරම්භ නොකළ හෝ ලියාපදිංචි කර නොමැති බවයි. මෙම මාතෘකාව මත ද ඇත වෙනම HF.

හොඳයි, ඉහළම RPC දෝෂ 3 සම්පූර්ණ කිරීමට, RPC ක්‍රියාකාරී ඇමතුම අසාර්ථක වූ බව මතක තබා ගනිමු (1726). සම්බන්ධතාවය ස්ථාපිත කර ඇත්නම් දිස්වේ, නමුත් RPC ඉල්ලීම් ක්‍රියාත්මක නොවේ. උදාහරණයක් ලෙස, අපි VSS හි තත්ත්වය පිළිබඳ තොරතුරු ඉල්ලා සිටිමු (හදිසියේම දැන් එහි සෙවනැලි පතලක් සාදනු ලබන අතර, අපි නැගීමට උත්සාහ කරමු), සහ අපට ප්‍රතිචාර වශයෙන්, නිශ්ශබ්දව සහ නොසලකා හරින්න.

Windows Tape Backup API ටේප් පුස්තකාල හෝ ධාවකයන් සමඟ වැඩ කිරීමට අවශ්ය වේ. මම ආරම්භයේ සඳහන් කළ පරිදි: අපගේම රියදුරන් ලිවීමෙන් පසුව එක් එක් උපාංගයේ සහාය ඇතිව දුක් විඳීමෙන් අපට සතුටක් නැත. එබැවින්, vim හට තමන්ගේම රියදුරන් නොමැත. සියල්ල සම්මත API හරහා, දෘඪාංග වෙළෙන්දන් විසින්ම ක්‍රියාත්මක කරන ලද සහාය. ගොඩක් තාර්කිකයි නේද?

SMB / CIFS CIFS (Common Internet File System) යනු SMB (Server Message Block) හි පුද්ගලික අනුවාදයක් බව සැමට මතක නැති වුවද පුරුද්දෙන් බැහැරව, සෑම කෙනෙකුම ඒවා එක පැත්තකින් ලියයි. එබැවින් මෙම සංකල්ප සාමාන්යකරණය කිරීමේ වරදක් නැත. Samba දැනටමත් LinuxUnix ක්‍රියාත්මක කිරීමක් වන අතර, එයට එහිම විශේෂතා ඇත, නමුත් මම ඉවත් වෙමි. මෙහිදී වැදගත් වන්නේ: Veeam විසින් UNC මාර්ගයට (සේවාදායක බහලුම) යමක් ලිවීමට ඉල්ලා සිටින විට, සේවාදායකය විසින් පන්දුවට ලිවීමට mup සහ mrxsmb ඇතුළු ගොනු පද්ධති ධාවක ධුරාවලිය භාවිතා කරයි. ඒ අනුව, මෙම රියදුරන් ද දෝෂ ජනනය කරනු ඇත.

නැතුව බෑ Winsock API. ජාලය හරහා යමක් කිරීමට අවශ්‍ය නම්, VBR Windows Socket API හරහා ක්‍රියා කරයි, එය ජනප්‍රිය Winsock ලෙස හැඳින්වේ. ඉතින් අපි ලොග් එකේ IP:Port පොකුරක් දැක්කොත් මේක තමයි. නිල ලේඛනවල හැකි හොඳ ලැයිස්තුවක් ඇත වැරදි.

ඉහත සඳහන් ඩබ්ලිව්.එම්.අයි (Windows Management Instrumentation) යනු Windows ලෝකයේ සෑම දෙයක්ම සහ සියලු දෙනා කළමනාකරණය කිරීම සඳහා සර්වබලධාරී API වර්ගයකි. උදාහරණයක් ලෙස, Hyper-V සමඟ වැඩ කරන විට, ධාරකයට කරන සියලුම ඉල්ලීම් පාහේ එය හරහා යයි. වචනයෙන් කියනවා නම්, දෙය සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය කළ නොහැකි අතර එහි හැකියාවන්ගෙන් ඉතා බලවත් ය. බිඳී ඇත්තේ කොතැනද සහ කුමක් දැයි සොයා ගැනීමට උපකාර කිරීමට උත්සාහ කිරීමේදී, ගොඩනඟන ලද WBEMtest.exe මෙවලම බොහෝ සෙයින් උපකාරී වේ.

ලැයිස්තුවේ අන්තිමයා, නමුත් කිසිසේත්ම වැදගත්කමක් නැත - එස්එස්එස් (වෙළුම් සෙවන ගබඩාව). මාතෘකාව බොහෝ ලියකියවිලි ලියා ඇති පරිදි විස්තර කළ නොහැකි හා අද්භූත ය. සෙවනැලි පිටපත ඉතා සරලව වටහාගෙන ඇත්තේ විශේෂ ස්නැප්ෂොට් වර්ගයක් ලෙසයි, සාරය වශයෙන් එයයි. ඔහුට ස්තූතියි, ඔබට VMware හි යෙදුම්-අනුකූල උපස්ථ සෑදිය හැකිය, සහ Hyper-V හි සෑම දෙයක්ම පාහේ. මම VSS මත යම් මිරිකීමක් සමඟ වෙනම ලිපියක් කිරීමට සැලසුම් කර ඇත, නමුත් දැනට ඔබට කියවීමට උත්සාහ කළ හැකිය මෙම විස්තරය. පරෙස්සම් වන්න, මන්ද. ෆ්ලෑෂ් එකකින් VSS තේරුම් ගැනීමට උත්සාහ කිරීම මොළයේ තුවාල වීමට හේතු විය හැක.

මේ මත, සමහර විට, අපට නතර කළ හැකිය. සම්පුර්ණ කරන ලද මූලික කරුණු පැහැදිලි කිරීමේ කාර්යය මම සලකමි, එබැවින් ඊළඟ පරිච්ඡේදයේ අපි දැනටමත් ලඝු-සටහන් දෙස බලමු. නමුත් ඔබට කිසියම් ප්රශ්නයක් ඇත්නම්, අදහස් දැක්වීමේදී ඔවුන්ගෙන් විමසීමට නිදහස් වන්න.

මූලාශ්රය: www.habr.com