લોગ ક્યાંથી આવે છે? Veeam લોગ ડાઇવિંગ

અમે અનુમાન લગાવવાની રસપ્રદ દુનિયામાં અમારી નિમજ્જન ચાલુ રાખીએ છીએ ... લોગ દ્વારા સમસ્યાનિવારણ. IN પાછલો લેખ અમે મૂળભૂત શરતોના અર્થ પર સંમત થયા અને વીમની એકંદર રચનાને એક આંખે એક જ એપ્લિકેશન તરીકે જોઈ. આ માટેનું કાર્ય એ જાણવાનું છે કે લોગ ફાઇલો કેવી રીતે બને છે, તેમાં કેવા પ્રકારની માહિતી પ્રદર્શિત થાય છે અને તેઓ જે રીતે દેખાય છે તે શા માટે દેખાય છે.

તમને શું લાગે છે કે આ "લોગ" શું છે? મોટાભાગના લોકોના મતે, કોઈપણ એપ્લિકેશનના લોગને એક પ્રકારની સર્વશક્તિમાન એન્ટિટીની ભૂમિકા સોંપવી જોઈએ જે મોટાભાગે બેકયાર્ડમાં ક્યાંક વનસ્પતિ કરે છે, પરંતુ યોગ્ય સમયે તે ચમકતા બખ્તરમાં ક્યાંય બહાર દેખાય છે અને દરેકને બચાવે છે. એટલે કે, તેમાં દરેક ઘટકમાં સહેજ ભૂલોથી માંડીને વ્યક્તિગત ડેટાબેઝ વ્યવહારો સુધી બધું જ હોવું જોઈએ. અને તેથી ભૂલ પછી તરત જ તેને કેવી રીતે ઠીક કરવું તે લખવામાં આવ્યું હતું. અને આ બધું થોડા મેગાબાઇટ્સમાં ફિટ થવું જોઈએ, વધુ નહીં. તે માત્ર ટેક્સ્ટ છે! ટેક્સ્ટ ફાઇલો દસ ગીગાબાઇટ્સ લઈ શકતી નથી, મેં તે ક્યાંક સાંભળ્યું છે!

તેથી લોગ

વાસ્તવિક દુનિયામાં, લૉગ્સ એ માત્ર ડાયગ્નોસ્ટિક માહિતીનો આર્કાઇવ છે. અને ત્યાં શું સંગ્રહિત કરવું, સંગ્રહ માટે માહિતી ક્યાંથી મેળવવી અને તે કેટલી વિગતવાર હોવી જોઈએ, તે વિકાસકર્તાઓએ પોતે નક્કી કરવાનું છે. કોઈ ON / OFF સ્તરના રેકોર્ડ્સ રાખીને લઘુત્તમવાદના માર્ગને અનુસરે છે, અને કોઈ વ્યક્તિ જે તે પહોંચી શકે છે તે બધું ખંતપૂર્વક તૈયાર કરે છે. જો કે, કહેવાતા લોગીંગ લેવલને પસંદ કરવાની ક્ષમતા સાથેનો એક મધ્યવર્તી વિકલ્પ પણ છે, જ્યારે તમે પોતે જ દર્શાવો છો કે તમે કેટલી વિગતવાર માહિતી સંગ્રહિત કરવા માંગો છો અને તમારી પાસે કેટલી વધારાની ડિસ્ક જગ્યા છે =) VBR પાસે આવા છ સ્તરો છે. અને, મારો વિશ્વાસ કરો, તમે તમારી ડિસ્ક પર ખાલી જગ્યા સાથે સૌથી વિગતવાર લોગીંગ સાથે શું થાય છે તે જોવા માંગતા નથી.

દંડ. અમે લગભગ સમજી ગયા કે આપણે શું સાચવવા માંગીએ છીએ, પરંતુ એક કાયદેસર પ્રશ્ન ઊભો થાય છે: આ માહિતી ક્યાંથી મેળવવી? અલબત્ત, અમે અમારી આંતરિક પ્રક્રિયાઓ દ્વારા પોતાને લૉગ ઇન કરવા માટે ઇવેન્ટનો ભાગ બનાવીએ છીએ. પરંતુ જ્યારે બાહ્ય વાતાવરણ સાથે ક્રિયાપ્રતિક્રિયા હોય ત્યારે શું કરવું? ક્રૉચ અને સાયકલના નરકમાં ન સરકવા માટે, વીમ એવી શોધ ન કરે કે જેની શોધ થઈ ચૂકી હોય. જ્યારે પણ તૈયાર API, બિલ્ટ-ઇન ફંક્શન, લાઇબ્રેરી વગેરે હશે, ત્યારે અમે અમારા કોન્ટ્રાપ્શનને વાડ કરવાનું શરૂ કરતા પહેલા તૈયાર વિકલ્પોને પ્રાધાન્ય આપીશું. જોકે બાદમાં પણ પર્યાપ્ત છે. તેથી, લૉગ્સનું પૃથ્થકરણ કરતી વખતે, એ સમજવું અગત્યનું છે કે ભૂલોનો મોટો હિસ્સો તૃતીય-પક્ષ API, સિસ્ટમ કૉલ્સ અને અન્ય લાઇબ્રેરીઓના સંદેશાઓ પર પડે છે. આ કિસ્સામાં, VBR ની ભૂમિકા આ ​​ભૂલોને લોગ ફાઇલોની જેમ ફોરવર્ડ કરવા માટે નીચે આવે છે. અને વપરાશકર્તાનું મુખ્ય કાર્ય એ સમજવાનું શીખવાનું છે કે કઈ લાઇન કોની પાસેથી છે અને આ "કોણ" શું માટે જવાબદાર છે. તેથી જો VBR લોગમાંથી ભૂલ કોડ તમને MSDN પૃષ્ઠ પર લઈ જાય, તો તે સારું અને સાચું છે.

જેમ આપણે પહેલા સંમત થયા હતા: Veeam એ એક કહેવાતી SQL-આધારિત એપ્લિકેશન છે. આનો અર્થ એ છે કે બધી સેટિંગ્સ, બધી માહિતી અને સામાન્ય રીતે બધું જે ફક્ત સામાન્ય કાર્ય માટે જરૂરી છે - બધું તેના ડેટાબેઝમાં સંગ્રહિત છે. તેથી સરળ સત્ય: જે લોગમાં નથી તે ડેટાબેઝમાં મોટા ભાગે છે. પરંતુ આ સિલ્વર બુલેટ પણ નથી: કેટલીક વસ્તુઓ Veeam ઘટકોના સ્થાનિક લોગમાં નથી કે તેના ડેટાબેઝમાં નથી. તેથી, તમારે હોસ્ટ લોગ્સ, લોકલ મશીનના લોગ્સ અને બેકઅપ અને રિસ્ટોર પ્રક્રિયામાં સામેલ દરેક વસ્તુના લોગનો અભ્યાસ કેવી રીતે કરવો તે શીખવાની જરૂર છે. અને એવું પણ બને છે કે જરૂરી માહિતી ક્યાંય પણ ઉપલબ્ધ નથી. તે માર્ગ છે. 

આવા API ના કેટલાક ઉદાહરણો

આ સૂચિ અપવાદરૂપે પૂર્ણ થવાનો હેતુ નથી, તેથી તેમાં અંતિમ સત્ય શોધવાની જરૂર નથી. તેનો હેતુ ફક્ત અમારા ઉત્પાદનોમાં ઉપયોગમાં લેવાતી સૌથી સામાન્ય તૃતીય-પક્ષ API અને તકનીકો બતાવવાનો છે.

સાથે શરૂઆત કરીએ વીએમવેર. 

યાદીમાં પ્રથમ હશે vSphere API. પ્રમાણીકરણ, વંશવેલો વાંચવા, સ્નેપશોટ બનાવવા અને કાઢી નાખવા, મશીનો વિશે માહિતીની વિનંતી કરવા અને ઘણું બધું (ખૂબ જ) માટે વપરાય છે. સોલ્યુશનની કાર્યક્ષમતા ખૂબ વિશાળ છે, તેથી હું સંસ્કરણ માટે VMware vSphere API સંદર્ભની ભલામણ કરી શકું છું 5.5 и 6.0. વધુ વર્તમાન સંસ્કરણો માટે, બધું ફક્ત google કરેલ છે.

VIX API. હાઇપરવાઇઝરનો કાળો જાદુ, જેના માટે એક અલગ છે ભૂલ યાદી. નેટવર્ક પર તેમને કનેક્ટ કર્યા વિના હોસ્ટ પર ફાઇલો સાથે કામ કરવા માટે VMware API. જ્યારે તમારે મશીનમાં ફાઇલ મૂકવાની જરૂર હોય ત્યારે છેલ્લા ઉપાયનો એક પ્રકાર કે જેનાથી વધુ સારી સંચાર ચેનલ નથી. જો ફાઇલ મોટી હોય અને હોસ્ટ લોડ થયેલ હોય તો તે પીડા અને વેદના છે. પરંતુ અહીં નિયમ કામ કરે છે કે 56,6 Kb/s પણ 0 Kb/s કરતાં વધુ સારી છે. હાયપર-વીમાં, આ વસ્તુને પાવરશેલ ડાયરેક્ટ કહેવામાં આવે છે. પરંતુ તે પહેલા જ હતું

vSpehere વેબ સેવાઓ API vSphere 6.0 થી શરૂ કરીને (અંદાજે, કારણ કે આ API પ્રથમ સંસ્કરણ 5.5 પર રજૂ કરવામાં આવ્યું હતું) તેનો ઉપયોગ ગેસ્ટ મશીનો સાથે કામ કરવા માટે થાય છે અને લગભગ દરેક જગ્યાએ VIX નું સ્થાન લીધું છે. હકીકતમાં, vSphere નું સંચાલન કરવા માટે આ બીજું API છે. રસ ધરાવતા લોકો માટે, હું અભ્યાસ કરવાની ભલામણ કરું છું отличный મેન્યુઅલ 

વીડીડીકે (વર્ચ્યુઅલ ડિસ્ક ડેવલપમેન્ટ કીટ). જેમાં આંશિક રીતે લાયબ્રેરીની ચર્ચા કરવામાં આવી હતી લેખ. વર્ચ્યુઅલ ડિસ્ક વાંચવા માટે વપરાય છે. એક સમયે તે VIX નો ભાગ હતો, પરંતુ સમય જતાં તેને એક અલગ ઉત્પાદનમાં ખસેડવામાં આવ્યો. પરંતુ વારસદાર તરીકે, તે VIX જેવા જ એરર કોડનો ઉપયોગ કરે છે. પરંતુ કેટલાક કારણોસર, SDK માં જ આ ભૂલોનું કોઈ વર્ણન નથી. તેથી, તે પ્રાયોગિક રીતે જાણવા મળ્યું હતું કે અન્ય કોડ્સ સાથેની VDDK ભૂલો માત્ર બાઈનરીથી દશાંશ કોડમાં અનુવાદ છે. તે બે ભાગો ધરાવે છે - પ્રથમ અર્ધ સંદર્ભ વિશે બિનદસ્તાવેજીકૃત માહિતી છે, અને બીજો ભાગ પરંપરાગત VIX / VDDK ભૂલો છે. ઉદાહરણ તરીકે, જો આપણે જોઈએ:

VDDK error: 21036749815809.Unknown error

પછી અમે હિંમતભેર આને હેક્સમાં કન્વર્ટ કરીએ છીએ અને 132200000001 મેળવીએ છીએ. અમે ફક્ત 132200 ની માહિતી વિનાની શરૂઆતને કાઢી નાખીએ છીએ, અને બાકીનો આપણો એરર કોડ હશે (VDDK 1: અજાણી ભૂલ). સૌથી વધુ વારંવાર થતી VDDK ભૂલો વિશે, તાજેતરમાં જ એક અલગ હતી લેખ.

હવે ચાલો જોઈએ વિન્ડોઝ.

અહીં, અમારા માટે સૌથી જરૂરી અને મહત્વપૂર્ણ છે તે બધું ધોરણમાં મળી શકે છે ઇવેન્ટ વ્યૂઅર. પરંતુ ત્યાં એક કેચ છે: લાંબી પરંપરા અનુસાર, વિન્ડોઝ ભૂલના સંપૂર્ણ ટેક્સ્ટને લૉગ કરતું નથી, પરંતુ ફક્ત તેનો નંબર. ઉદાહરણ તરીકે, ભૂલ 5 એ "એક્સેસ નકારેલ" છે, અને 1722 છે "The RPC સર્વર અનુપલબ્ધ છે", અને 10060 એ "કનેક્શન સમય સમાપ્ત" છે. અલબત્ત, જો તમને સૌથી પ્રસિદ્ધ યાદ હોય તો તે સરસ છે, પરંતુ અત્યાર સુધી અદ્રશ્ય લોકો વિશે શું? 

અને જેથી જીવન મધ જેવું લાગતું નથી, ભૂલો પણ હેક્સાડેસિમલ સ્વરૂપમાં સંગ્રહિત થાય છે, ઉપસર્ગ 0x8007 સાથે. ઉદાહરણ તરીકે, 0x8007000e ખરેખર 14 છે, મેમરીની બહાર. આ શા માટે અને કોના માટે કરવામાં આવ્યું તે અંધકારમાં ઘેરાયેલું રહસ્ય છે. જો કે, ભૂલોની સંપૂર્ણ સૂચિ મફતમાં અને SMS વિના ડાઉનલોડ કરી શકાય છે વિકાસ કેન્દ્ર.

માર્ગ દ્વારા, કેટલીકવાર અન્ય ઉપસર્ગો હોય છે, માત્ર 0x8007 જ નહીં. આવી દુઃખદ પરિસ્થિતિમાં, HRESULT ("પરિણામ હેન્ડલ") ને સમજવા માટે, તમારે વધુ ઊંડાણપૂર્વક તપાસ કરવાની જરૂર છે દસ્તાવેજીકરણ વિકાસકર્તાઓ માટે. સામાન્ય જીવનમાં, હું તમને આ કરવાની સલાહ આપતો નથી, પરંતુ જો તમે અચાનક દિવાલ સામે દબાવો છો અથવા ફક્ત વિચિત્ર છો, તો હવે તમે જાણો છો કે શું કરવું.

પરંતુ માઈક્રોસોફ્ટના સાથીઓએ અમારા પર થોડી દયા કરી અને વિશ્વને ઉપયોગીતા બતાવી ERR. આ કન્સોલ સુખનો એક નાનો ટુકડો છે જે ગૂગલનો ઉપયોગ કર્યા વિના ભૂલ કોડને માનવમાં અનુવાદિત કરી શકે છે. તે આ રીતે કામ કરે છે.

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 ફાઇલો સાથે કામ કરતી વખતે દરેક સંભવિત રીતે ઉપયોગમાં લેવાય છે. ફાઇલો બનાવવી, કાઢી નાખવી, લખવા માટે ખોલવી, વિશેષતાઓ સાથે કામ કરવું, અને બીજું ઘણું બધું.

ઉપર ઉલ્લેખ કર્યો છે પાવરશેલ ડાયરેક્ટ હાઇપર-વી વિશ્વમાં VIX API ના એનાલોગ તરીકે. કમનસીબે, એટલું લવચીક નથી: કાર્યક્ષમતા પર ઘણા બધા નિયંત્રણો, તે હોસ્ટના દરેક સંસ્કરણ સાથે કામ કરતું નથી અને બધા અતિથિઓ સાથે નહીં.

આર.પી.સી. (રિમોટ પ્રોસિજર કૉલ) મને નથી લાગતું કે વિન્ડોઝ સાથે કામ કરનાર એક પણ વ્યક્તિ છે જેણે RPC-સંબંધિત ભૂલો જોઈ નથી. લોકપ્રિય ગેરસમજ હોવા છતાં, આ એક પ્રોટોકોલ નથી, પરંતુ કોઈપણ ક્લાયંટ-સર્વર પ્રોટોકોલ છે જે સંખ્યાબંધ પરિમાણોને સંતોષે છે. જો કે, જો અમારા લોગમાં RPC ભૂલ હશે, તો 90% વખતે તે Microsoft RPC તરફથી ભૂલ હશે, જે DCOM (ડિસ્ટ્રિબ્યુટેડ કમ્પોનન્ટ ઑબ્જેક્ટ મોડલ) નો ભાગ છે. તમે નેટ પર આ વિષય પરના દસ્તાવેજોનો વિશાળ જથ્થો શોધી શકો છો, પરંતુ તેમાંનો સિંહનો હિસ્સો તદ્દન જૂનો છે. પરંતુ જો વિષયનો અભ્યાસ કરવાની તીવ્ર ઇચ્છા હોય, તો હું લેખોની ભલામણ કરી શકું છું RPC શું છે?, કેવી રીતે આરપીસી વર્ક્સ અને લાંબી યાદી RPC ભૂલો.

અમારા લોગમાં RPC ભૂલોના મુખ્ય કારણો VBR ઘટકો (ઉદાહરણ તરીકે સર્વર > પ્રોક્સી) વચ્ચે વાતચીત કરવાના નિષ્ફળ પ્રયાસો છે અને મોટેભાગે સંચાર સમસ્યાઓને કારણે.

તમામ ટોપ્સમાં ટોચની ટોચ એ ભૂલ છે RPC સર્વર અનુપલબ્ધ છે (1722). સરળ શબ્દોમાં, ક્લાયંટ સર્વર સાથે જોડાણ સ્થાપિત કરી શક્યું નથી. કેવી રીતે અને શા માટે - ત્યાં કોઈ એક જવાબ નથી, પરંતુ સામાન્ય રીતે તે પ્રમાણીકરણ અથવા પોર્ટ 135 પર નેટવર્ક ઍક્સેસ સાથે સમસ્યા છે. બાદમાં ગતિશીલ પોર્ટ અસાઇનમેન્ટ સાથેના ઇન્ફ્રાસ્ટ્રક્ચર માટે લાક્ષણિક છે. આ વિષય પર, ત્યાં પણ છે અલગ HF. અને માઇક્રોસોફ્ટ પાસે છે વિશાળ માર્ગદર્શિકા નિષ્ફળતાનું કારણ શોધવા માટે.

બીજી સૌથી લોકપ્રિય ભૂલ: એન્ડપોઇન્ટ મેપર (1753) થી વધુ કોઇ એન્ડપોઇન્ટ્સ ઉપલબ્ધ નથી. RPC ક્લાયંટ અથવા સર્વર પોતાને પોર્ટ સોંપવામાં નિષ્ફળ થયું. સામાન્ય રીતે ત્યારે થાય છે જ્યારે સર્વર (અમારા કિસ્સામાં, ગેસ્ટ મશીન) એક સાંકડી શ્રેણીમાંથી પોર્ટ્સને ગતિશીલ રીતે ફાળવવા માટે રૂપરેખાંકિત કરવામાં આવે છે જે સમાપ્ત થઈ ગઈ છે. અને જો તમે ક્લાયન્ટ બાજુથી લોગ ઇન કરો છો (અમારા કિસ્સામાં, VBR સર્વર), તો આનો અર્થ એ છે કે અમારું VeeamVssAgent કાં તો શરૂ થયું નથી અથવા RPC ઇન્ટરફેસ તરીકે નોંધાયેલ નથી. આ વિષય પર પણ છે અલગ HF.

સારું, ટોચની 3 RPC ભૂલો પૂર્ણ કરવા માટે, ચાલો યાદ રાખીએ કે RPC ફંક્શન કૉલ નિષ્ફળ ગયો (1726). જો કનેક્શન સ્થાપિત થઈ ગયું હોય તો દેખાય છે, પરંતુ RPC વિનંતીઓ પર પ્રક્રિયા કરવામાં આવતી નથી. ઉદાહરણ તરીકે, અમે VSS ની સ્થિતિ વિશેની માહિતી માટે વિનંતી કરીએ છીએ (અચાનક અત્યારે ત્યાં પડછાયાની ખાણ બનાવવામાં આવી રહી છે, અને અમે ચઢવાનો પ્રયાસ કરી રહ્યા છીએ), અને અમારા જવાબમાં, મૌન અને અવગણના કરીએ છીએ.

વિન્ડોઝ ટેપ બેકઅપ API ટેપ લાઇબ્રેરીઓ અથવા ડ્રાઇવ્સ સાથે કામ કરવા માટે જરૂરી છે. જેમ મેં શરૂઆતમાં ઉલ્લેખ કર્યો છે: અમને અમારા પોતાના ડ્રાઇવરો લખવામાં અને પછી દરેક ઉપકરણના ટેકાથી પીડાય છે તેમાં કોઈ આનંદ નથી. તેથી, વિમ પાસે તેના પોતાના કોઈ ડ્રાઇવરો નથી. બધા પ્રમાણભૂત API દ્વારા, જેનું સમર્થન હાર્ડવેર વિક્રેતાઓ દ્વારા પોતે જ લાગુ કરવામાં આવે છે. તેથી વધુ તાર્કિક, અધિકાર?

એસએમબી / સીઆઈએફએસ આદતને લીધે, દરેક જણ તેમને સાથે સાથે લખે છે, જોકે દરેકને યાદ નથી હોતું કે CIFS (કોમન ઈન્ટરનેટ ફાઇલ સિસ્ટમ) એ SMB (સર્વર મેસેજ બ્લોક) નું માત્ર એક ખાનગી સંસ્કરણ છે. તેથી આ ખ્યાલોનું સામાન્યીકરણ કરવામાં કંઈ ખોટું નથી. સામ્બા પહેલેથી જ LinuxUnix અમલીકરણ છે, અને તેની પોતાની વિશિષ્ટતાઓ છે, પરંતુ હું વિષયાંતર કરું છું. અહીં શું મહત્વનું છે: જ્યારે Veeam UNC પાથ (serverdirectory) પર કંઈક લખવાનું કહે છે, ત્યારે સર્વર બોલ પર લખવા માટે, mup અને mrxsmb સહિત ફાઈલ સિસ્ટમ ડ્રાઈવરોના વંશવેલોનો ઉપયોગ કરે છે. તદનુસાર, આ ડ્રાઇવરો પણ ભૂલો પેદા કરશે.

વિના કરી શકતા નથી વિન્સૉક API. જો નેટવર્ક પર કંઈક કરવાની જરૂર હોય, તો VBR વિન્ડોઝ સોકેટ API દ્વારા કામ કરે છે, જે વિન્સૉક તરીકે પ્રખ્યાત છે. તેથી જો આપણે લોગમાં આઈપી:પોર્ટનો સમૂહ જોઈએ, તો આ તે છે. સત્તાવાર દસ્તાવેજોમાં શક્યની સારી સૂચિ છે ભૂલો.

ઉપર ઉલ્લેખ કર્યો છે ડબલ્યુએમઆઈ (Windows Management Instrumentation) એ Windows વિશ્વમાં દરેક વસ્તુ અને દરેકને મેનેજ કરવા માટે એક પ્રકારનું સર્વશક્તિમાન API છે. ઉદાહરણ તરીકે, હાયપર-વી સાથે કામ કરતી વખતે, હોસ્ટને લગભગ બધી વિનંતીઓ તેમાંથી પસાર થાય છે. એક શબ્દમાં, વસ્તુ તેની ક્ષમતાઓમાં એકદમ બદલી ન શકાય તેવી અને ખૂબ જ શક્તિશાળી છે. ક્યાં અને શું તૂટી ગયું છે તે શોધવામાં મદદ કરવાના પ્રયાસમાં, બિલ્ટ-ઇન WBEMtest.exe ટૂલ ઘણી મદદ કરે છે.

અને સૂચિમાં છેલ્લું, પરંતુ કોઈ પણ રીતે ઓછું મહત્વ નથી - વીએસએસ (વોલ્યુમ શેડો સ્ટોરેજ). આ વિષય જેટલો અખૂટ અને રહસ્યમય છે તેટલો જ તેના પર દસ્તાવેજો લખવામાં આવ્યા છે. શેડો કોપીને ખાસ પ્રકારના સ્નેપશોટ તરીકે સમજવામાં આવે છે, જે સારમાં છે. તેના માટે આભાર, તમે VMware માં એપ્લિકેશન-સતત બેકઅપ બનાવી શકો છો, અને લગભગ બધું Hyper-V માં. મારી પાસે VSS પર થોડો સ્ક્વિઝ સાથે એક અલગ લેખ બનાવવાની યોજના છે, પરંતુ હમણાં માટે તમે વાંચવાનો પ્રયાસ કરી શકો છો આ વર્ણન. ફક્ત સાવચેત રહો, કારણ કે. ફ્લેશમાં VSS ને સમજવાનો પ્રયાસ કરવાથી મગજમાં ઈજા થઈ શકે છે.

આના પર, કદાચ, આપણે રોકી શકીએ. હું પૂર્ણ થયેલ સૌથી મૂળભૂત બાબતોને સમજાવવાના કાર્યને ધ્યાનમાં લઈશ, તેથી આગામી પ્રકરણમાં આપણે પહેલાથી જ લોગ જોઈશું. પરંતુ જો તમારી પાસે કોઈ પ્રશ્નો હોય, તો ટિપ્પણીઓમાં તેમને પૂછવા માટે નિઃસંકોચ.

સોર્સ: www.habr.com