موږ د اټکل کولو په زړه پورې نړۍ کې خپل ډوبیدو ته دوام ورکوو ... د لاګونو له لارې د ستونزو حل کول. IN
تاسو څه فکر کوئ چې دا "لاګ" دي؟ د ډیری په وینا ، د هر غوښتنلیک لاګونه باید د یو ډول ځواکمن وجود رول وګمارل شي چې ډیری وخت په انګړ کې یو ځای میوه کوي ، مګر په سم وخت کې په روښانه زغره کې له کوم ځای څخه څرګندیږي او هرڅوک وژغوري. دا دی، دوی باید هرڅه ولري، په هره برخه کې له لږو غلطیو څخه د انفرادي ډیټابیس لیږد پورې. او له همدې امله د تېروتنې وروسته سمدلاسه لیکل شوي چې څنګه یې سم کړئ. او دا ټول باید په یو څو میګابایټ کې فټ شي، نور نه. دا یوازې متن دی! د متن فایلونه نشي کولی لسګونه ګیګابایټونه واخلي، ما دا بل ځای اوریدلی!
نو logs
په ریښتینې نړۍ کې، لاګونه یوازې د تشخیصي معلوماتو آرشیف دي. او هلته څه ذخیره کول، چیرته د ذخیره کولو لپاره معلومات ترلاسه کول او دا باید څومره مفصل وي، پخپله پراختیا کونکو پورې اړه لري چې پریکړه وکړي. یو څوک د ON / OFF کچې ریکارډونو ساتلو سره د minimalism لاره تعقیبوي ، او څوک په لیوالتیا سره هر هغه څه راټولوي چې دوی ورته رسیدلی شي. که څه هم دلته یو منځګړی اختیار هم شتون لري چې د تش په نامه د ننوتلو کچې غوره کولو وړتیا لري، کله چې تاسو پخپله په ګوته کوئ چې تاسو څومره تفصيلي معلومات ساتل غواړئ او څومره اضافي ډیسک ځای لرئ =) VBR په لاره کې شپږ داسې کچې لري. او، په ما باور وکړئ، تاسو نه غواړئ وګورئ چې ستاسو په ډیسک کې د وړیا ځای سره د خورا مفصلو ننوتلو سره څه پیښیږي.
ښه. موږ په دقیق ډول پوهیږو چې موږ څه غواړو خوندي کړو، مګر یو مشروع پوښتنه راپورته کیږي: دا معلومات له کوم ځای څخه ترلاسه کړو؟ البته، موږ د خپلو داخلي پروسو لخوا د ځان د ننوتلو لپاره د پیښو برخه جوړوو. مګر څه باید وکړو کله چې د بهرني چاپیریال سره تعامل شتون ولري؟ د دې لپاره چې د کرچچونو او بایسکلونو دوزخ ته لاړ نشي، ویم د اختراعاتو اختراع نه کوي چې دمخه اختراع شوي. هرکله چې یو چمتو شوی API، جوړ شوی فنکشن، کتابتون، او داسې نور شتون ولري، موږ به مخکې له دې چې زموږ د ککړتیا د بندولو پیل پیل کړو چمتو شوي انتخابونو ته ترجیح ورکوو. که څه هم وروستی هم کافي دی. نو ځکه، کله چې د لاګونو تحلیل کول، دا مهمه ده چې پوه شي چې د تېروتنې لویه برخه د دریمې ډلې APIs، سیسټم کالونو، او نورو کتابتونونو پیغامونو باندې راځي. په دې حالت کې، د VBR رول د لاګ فایلونو په څیر د دې غلطیتونو لیږلو ته راځي. او د کارونکي اصلي دنده دا ده چې پوه شي چې کوم کرښه د چا څخه ده، او دا "څوک" د څه لپاره مسؤل دی. نو که د VBR لاګ څخه د خطا کوډ تاسو د MSDN پاڼې ته لیږي، دا ښه او سمه ده.
لکه څنګه چې موږ مخکې موافقه وکړه: Veeam یو تش په نامه SQL-based غوښتنلیک دی. دا پدې مانا ده چې ټول ترتیبات، ټول معلومات او په عموم کې هرڅه چې یوازې د عادي فعالیت لپاره اړین دي - هرڅه په ډیټابیس کې زیرمه شوي. له همدې امله ساده حقیقت: هغه څه چې په لاګونو کې ندي ډیری احتمال په ډیټابیس کې دي. مګر دا هم د سپینو زرو ګولۍ نه ده: ځینې شیان د ویم اجزاو په ځایی لاګونو کې ندي او نه هم د دې ډیټابیس کې. له همدې امله ، تاسو اړتیا لرئ زده کړئ چې څنګه د کوربه لاګونو مطالعه وکړئ ، د ځایی ماشین لاګونه او د هرڅه لاګونه چې د بیک اپ او بیا رغونې پروسې کې دخیل دي. او دا هم پیښیږي چې اړین معلومات په هیڅ ځای کې شتون نلري. همدا لاره ده.
د ورته APIs ځینې مثالونه
دا لیست په استثنایي ډول بشپړ نه دی ، نو پدې کې د حتمي حقیقت موندلو ته اړتیا نشته. د دې هدف یوازې زموږ په محصولاتو کې کارول شوي ترټولو عام دریمې ډلې APIs او ټیکنالوژۍ ښودل دي.
راځئ چې پیل وکړو VMware.
په لیست کې به لومړی وي vSphere API. د تصدیق کولو لپاره کارول کیږي، د درجه بندي لوستل، د سنیپ شاټونو جوړول او حذف کول، د ماشینونو په اړه د معلوماتو غوښتنه کول، او نور ډیر څه (ډیر ډیر). د حل فعالیت خورا پراخه دی ، نو زه کولی شم د نسخې لپاره د VMware vSphere API حواله وړاندیز وکړم
VIX API. د هایپروایزر تور جادو، د کوم لپاره چې یو جلا دی
vSpehere Web Services API د vSphere 6.0 څخه پیل کول (نږدې، ځکه چې دا API په لومړي ځل په 5.5 نسخه کې معرفي شوی) دا د میلمنو ماشینونو سره کار کولو لپاره کارول کیږي او نږدې هر ځای یې VIX ځای په ځای کړی. په حقیقت کې، دا د vSphere اداره کولو لپاره بل API دی. د هغو کسانو لپاره چې لیوالتیا لري، زه د مطالعې وړاندیز کوم
VDDK (د مجازی ډیسک پرمختیا کټ). د کتابتون، چې په دې برخه کې په جزوي توګه خبرې وشوې
VDDK error: 21036749815809.Unknown error
بیا موږ په زړورتیا سره دا هیکس ته واړوو او 132200000001 ترلاسه کړو. موږ په ساده ډول د 132200 غیرمعلوماتي پیل ردوو، او پاتې به زموږ د خطا کوډ وي (VDDK 1: نامعلومه تېروتنه). د ډیری مکرر VDDK غلطیو په اړه ، پدې وروستیو کې یو جلا شتون درلود
اوس راځئ چې وګورو وینډوز.
دلته ، هرڅه چې زموږ لپاره خورا اړین او مهم دي په معیار کې موندل کیدی شي پیښور لیدونکی. مګر دلته یو کیچ شتون لري: د اوږد دود سره سم، وینډوز د غلطۍ بشپړ متن نه ننوځي، مګر یوازې د هغې شمیره. د مثال په توګه، 5 تېروتنه "لاسرسی رد شوی" دی، او 1722 دی "د RPC سرور شتون نلري"، او 10060 دی "د پیوستون وخت پای ته رسیدلی". البته، دا خورا ښه ده که تاسو خورا مشهور په یاد ولرئ، مګر د هغه څه په اړه چې تر اوسه نه لیدل کیږي؟
او د دې لپاره چې ژوند په هیڅ ډول د شاتو په څیر نه ښکاري، غلطۍ هم په هیکساډیسیمل بڼه کې زیرمه شوي، د مخکینۍ 0x8007 سره. د مثال په توګه، 0x8007000e په حقیقت کې 14 دی، د حافظې څخه بهر. ولې او د چا لپاره دا کار وشو یو راز دی چې په تیاره کې پټ دی. په هرصورت، د غلطیو بشپړ لیست وړیا او پرته له SMS څخه ډاونلوډ کیدی شي
په لاره کې، ځینې وختونه نور مخابرات شتون لري، نه یوازې 0x8007. په داسې غمجن حالت کې، د HRESULT د پوهیدو لپاره ("د پایلې اداره")، تاسو اړتیا لرئ چې حتی ژور فکر وکړئ.
مګر په مایکروسافټ کې ملګري په موږ لږ رحم وکړ او نړۍ ته یې یو کار وښود
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 مستقیم په Hyper-V نړۍ کې د VIX API د انلاګ په توګه. له بده مرغه، دومره انعطاف وړ نه دی: په فعالیت کې ډیری محدودیتونه، دا د کوربه هرې نسخې سره کار نه کوي او نه د ټولو میلمنو سره.
RPC (د ریموټ پروسیجر کال) زه فکر نه کوم چې یو واحد سړی شتون لري چې د وینډوز سره یې کار کړی وي چې د RPC پورې اړوند غلطی یې نه وي لیدلی. د مشهور غلط مفکورې سره سره، دا یو واحد پروتوکول نه دی، مګر د پیرودونکي سرور پروتوکول چې یو شمیر پیرامیټونه پوره کوي. په هرصورت، که زموږ په لاګونو کې د RPC تېروتنه وي، د وخت 90٪ دا به د مایکروسافټ RPC څخه یوه تېروتنه وي، کوم چې د DCOM (توزیع شوي اجزاو ماډل) برخه ده. تاسو کولی شئ په شبکه کې د دې موضوع په اړه خورا لوی اسناد ومومئ، مګر د هغې لویه برخه خورا زوړ ده. مګر که چیرې د موضوع مطالعې لپاره شدیده لیوالتیا وي، نو زه کولی شم د مقالو وړاندیز وکړم
زموږ په لاګونو کې د RPC تېروتنې اصلي لاملونه د VBR اجزاوو (سرور> پراکسي، د مثال په توګه) او ډیری وختونه د مخابراتو ستونزو له امله د اړیکو ناکامه هڅې دي.
د ټولو سرونو په مینځ کې پورتنۍ برخه تېروتنه ده د RPC سرور شتون نلري (1722). په ساده شرایطو کې، پیرودونکي نشي کولی د سرور سره اړیکه جوړه کړي. څنګه او ولې - هیڅ یو ځواب شتون نلري، مګر معمولا دا د تصدیق کولو یا 135 پورټ ته د شبکې لاسرسي سره ستونزه ده. وروستی د متحرک بندر دندې سره د زیربناوو لپاره معمول دی. په دې موضوع کې، حتی شتون لري
دویمه خورا مشهوره تېروتنه: د پای ټکي نقشه کونکي (1753) څخه نور پای ټکي شتون نلري. د RPC مراجع یا سرور ځان ته د پورټ په ټاکلو کې پاتې راغلی. معمولا واقع کیږي کله چې سرور (زموږ په قضیه کې د میلمه ماشین) تنظیم شوی ترڅو په متحرک ډول د محدود حد څخه بندرونه تخصیص کړي چې پای ته رسیدلی وي. او که تاسو د پیرودونکي اړخ څخه لاګ ان شئ (زموږ په قضیه کې ، د VBR سرور) ، د دې معنی دا ده چې زموږ VeeamVssAgent یا پیل نه و یا د RPC انٹرفیس په توګه راجستر شوی نه و. په دې موضوع کې هم شتون لري
ښه ، د غوره 3 RPC غلطیو بشپړولو لپاره ، راځئ چې په یاد ولرو د RPC فنکشن کال ناکام شو (1726). داسې ښکاري چې اړیکه جوړه شوې وي، مګر د RPC غوښتنې نه دي پروسس شوي. د مثال په توګه، موږ د VSS د وضعیت په اړه د معلوماتو غوښتنه کوو (ناڅاپه همدا اوس هلته د سیوري ماین جوړیږي، او موږ هڅه کوو چې پورته شي) او موږ ته په ځواب کې، چوپتیا او سترګې پټوو.
د وینډوز ټیپ بیک اپ API د ټیپ کتابتونونو یا ډرایو سره کار کولو ته اړتیا ده. لکه څنګه چې ما په پیل کې یادونه وکړه: موږ د خپلو چلوونکو په لیکلو کې خوښ نه یو او بیا د هرې وسیلې په ملاتړ رنځ کوو. له همدې امله ، ویم خپل هیڅ ډرایور نلري. ټول د معیاري API له لارې ، د کوم ملاتړ چې پخپله د هارډویر پلورونکو لخوا پلي کیږي. دومره ډیر منطقي، سمه ده؟
SMB / CIFS د عادت څخه بهر، هرڅوک دوی په څنګ کې لیکي، که څه هم هرڅوک په یاد نه لري چې CIFS (د عام انټرنیټ فایل سیسټم) یوازې د SMB (د سرور پیغام بلاک) شخصي نسخه ده. نو د دې مفکورو په عمومي کولو کې هیڅ شی نشته. سامبا لا دمخه د لینکس یونیکس تطبیق دی، او دا خپل ځانګړتیاوې لري، مګر زه یې ډډه کوم. دلته څه مهم دي: کله چې Veeam د UNC لارې (serverdirectory) ته د یو څه لیکلو غوښتنه کوي، سرور بال ته د لیکلو لپاره د mup او mrxsmb په شمول د فایل سیسټم ډرایورونو درجه بندي کاروي. په دې اساس، دا چلوونکي به هم تېروتنې رامنځته کړي.
پرته نشي کولی Winsock API. که په شبکه کې یو څه ترسره کولو ته اړتیا وي، VBR د وینډوز ساکټ API له لارې کار کوي، چې د وینساک په نوم پیژندل کیږي. نو که موږ د IP یوه ډله وګورو: په لاګ کې پورټ، دا دی. رسمي اسناد د امکان تر حده ښه لیست لري
پورته یادونه وشوه WMI (د وینډوز مدیریت وسیله) د وینډوز نړۍ کې د هرڅه او هرچا اداره کولو لپاره یو ډول عالي API دی. د مثال په توګه، کله چې د Hyper-V سره کار کوي، کوربه ته نږدې ټولې غوښتنې د هغې له لارې ځي. په یوه کلمه کې، شی په بشپړ ډول نه بدلیدونکی او په خپلو وړتیاوو کې خورا پیاوړی دی. د دې په موندلو کې د مرستې په هڅه کې چې چیرته او څه مات شوي دي، د WBEMtest.exe جوړ شوی وسیله ډیره مرسته کوي.
او په لیست کې وروستی، مګر په هیڅ معنی کې لږ اهمیت نلري - VSS (حجم سیوري ذخیره). موضوع هومره بې مانا او پراسرار ده څومره چې په دې اړه ډیر اسناد لیکل شوي دي. د سیوري کاپي په ساده ډول د ځانګړي ډول سنیپ شاټ په توګه پیژندل کیږي، کوم چې په اصل کې دا دی. د هغه څخه مننه، تاسو کولی شئ په VMware کې د غوښتنلیک سره سم بیک اپ جوړ کړئ، او نږدې هرڅه په Hyper-V کې. زه پلان لرم چې په VSS کې د یو څه فشار سره جلا مقاله جوړه کړم ، مګر د اوس لپاره تاسو کولی شئ د لوستلو هڅه وکړئ
په دې کې، شاید، موږ ودروو. زه د بشپړ شوي لومړني شیانو تشریح کولو دنده په پام کې نیسم، نو په راتلونکي فصل کې به موږ دمخه لاګونه وګورو. مګر که تاسو کومه پوښتنه لرئ، په تبصرو کې د هغوی څخه پوښتنه وکړئ.
سرچینه: www.habr.com