لاګ له کوم ځای څخه راځي؟ Veeam Log Diving

لاګ له کوم ځای څخه راځي؟ Veeam Log Diving

موږ د اټکل کولو په زړه پورې نړۍ کې خپل ډوبیدو ته دوام ورکوو ... د لاګونو له لارې د ستونزو حل کول. IN پخوانۍ مقاله موږ د اساسي شرایطو په معنی موافقه وکړه او د ویام ټول جوړښت ته مو د یوې سترګې سره د یو واحد غوښتنلیک په توګه وکتل. د دې لپاره دنده دا ده چې معلومه کړي چې څنګه د لاګ فایلونه رامینځته کیږي ، کوم ډول معلومات په دوی کې ښودل شوي او ولې دوی هغه ډول ګوري چې دوی ورته ګوري.

تاسو څه فکر کوئ چې دا "لاګ" دي؟ د ډیری په وینا ، د هر غوښتنلیک لاګونه باید د یو ډول ځواکمن وجود رول وګمارل شي چې ډیری وخت په انګړ کې یو ځای میوه کوي ، مګر په سم وخت کې په روښانه زغره کې له کوم ځای څخه څرګندیږي او هرڅوک وژغوري. دا دی، دوی باید هرڅه ولري، په هره برخه کې له لږو غلطیو څخه د انفرادي ډیټابیس لیږد پورې. او له همدې امله د تېروتنې وروسته سمدلاسه لیکل شوي چې څنګه یې سم کړئ. او دا ټول باید په یو څو میګابایټ کې فټ شي، نور نه. دا یوازې متن دی! د متن فایلونه نشي کولی لسګونه ګیګابایټونه واخلي، ما دا بل ځای اوریدلی!

نو logs

په ریښتینې نړۍ کې، لاګونه یوازې د تشخیصي معلوماتو آرشیف دي. او هلته څه ذخیره کول، چیرته د ذخیره کولو لپاره معلومات ترلاسه کول او دا باید څومره مفصل وي، پخپله پراختیا کونکو پورې اړه لري چې پریکړه وکړي. یو څوک د ON / OFF کچې ریکارډونو ساتلو سره د minimalism لاره تعقیبوي ، او څوک په لیوالتیا سره هر هغه څه راټولوي چې دوی ورته رسیدلی شي. که څه هم دلته یو منځګړی اختیار هم شتون لري چې د تش په نامه د ننوتلو کچې غوره کولو وړتیا لري، کله چې تاسو پخپله په ګوته کوئ چې تاسو څومره تفصيلي معلومات ساتل غواړئ او څومره اضافي ډیسک ځای لرئ =) VBR په لاره کې شپږ داسې کچې لري. او، په ما باور وکړئ، تاسو نه غواړئ وګورئ چې ستاسو په ډیسک کې د وړیا ځای سره د خورا مفصلو ننوتلو سره څه پیښیږي.

ښه. موږ په دقیق ډول پوهیږو چې موږ څه غواړو خوندي کړو، مګر یو مشروع پوښتنه راپورته کیږي: دا معلومات له کوم ځای څخه ترلاسه کړو؟ البته، موږ د خپلو داخلي پروسو لخوا د ځان د ننوتلو لپاره د پیښو برخه جوړوو. مګر څه باید وکړو کله چې د بهرني چاپیریال سره تعامل شتون ولري؟ د دې لپاره چې د کرچچونو او بایسکلونو دوزخ ته لاړ نشي، ویم د اختراعاتو اختراع نه کوي چې دمخه اختراع شوي. هرکله چې یو چمتو شوی API، جوړ شوی فنکشن، کتابتون، او داسې نور شتون ولري، موږ به مخکې له دې چې زموږ د ککړتیا د بندولو پیل پیل کړو چمتو شوي انتخابونو ته ترجیح ورکوو. که څه هم وروستی هم کافي دی. نو ځکه، کله چې د لاګونو تحلیل کول، دا مهمه ده چې پوه شي چې د تېروتنې لویه برخه د دریمې ډلې APIs، سیسټم کالونو، او نورو کتابتونونو پیغامونو باندې راځي. په دې حالت کې، د VBR رول د لاګ فایلونو په څیر د دې غلطیتونو لیږلو ته راځي. او د کارونکي اصلي دنده دا ده چې پوه شي چې کوم کرښه د چا څخه ده، او دا "څوک" د څه لپاره مسؤل دی. نو که د VBR لاګ څخه د خطا کوډ تاسو د MSDN پاڼې ته لیږي، دا ښه او سمه ده.

لکه څنګه چې موږ مخکې موافقه وکړه: Veeam یو تش په نامه SQL-based غوښتنلیک دی. دا پدې مانا ده چې ټول ترتیبات، ټول معلومات او په عموم کې هرڅه چې یوازې د عادي فعالیت لپاره اړین دي - هرڅه په ډیټابیس کې زیرمه شوي. له همدې امله ساده حقیقت: هغه څه چې په لاګونو کې ندي ډیری احتمال په ډیټابیس کې دي. مګر دا هم د سپینو زرو ګولۍ نه ده: ځینې شیان د ویم اجزاو په ځایی لاګونو کې ندي او نه هم د دې ډیټابیس کې. له همدې امله ، تاسو اړتیا لرئ زده کړئ چې څنګه د کوربه لاګونو مطالعه وکړئ ، د ځایی ماشین لاګونه او د هرڅه لاګونه چې د بیک اپ او بیا رغونې پروسې کې دخیل دي. او دا هم پیښیږي چې اړین معلومات په هیڅ ځای کې شتون نلري. همدا لاره ده. 

د ورته APIs ځینې مثالونه

دا لیست په استثنایي ډول بشپړ نه دی ، نو پدې کې د حتمي حقیقت موندلو ته اړتیا نشته. د دې هدف یوازې زموږ په محصولاتو کې کارول شوي ترټولو عام دریمې ډلې APIs او ټیکنالوژۍ ښودل دي.

راځئ چې پیل وکړو 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 Web Services API د vSphere 6.0 څخه پیل کول (نږدې، ځکه چې دا API په لومړي ځل په 5.5 نسخه کې معرفي شوی) دا د میلمنو ماشینونو سره کار کولو لپاره کارول کیږي او نږدې هر ځای یې VIX ځای په ځای کړی. په حقیقت کې، دا د vSphere اداره کولو لپاره بل API دی. د هغو کسانو لپاره چې لیوالتیا لري، زه د مطالعې وړاندیز کوم ښه لارښود 

VDDK (د مجازی ډیسک پرمختیا کټ). د کتابتون، چې په دې برخه کې په جزوي توګه خبرې وشوې مقالې. د مجازی ډیسکونو لوستلو لپاره کارول کیږي. یو وخت دا د VIX برخه وه، مګر د وخت په تیریدو سره دا یو جلا محصول ته لیږدول شوی. مګر د وارث په توګه، دا د VIX په څیر ورته غلطی کوډونه کاروي. مګر د ځینو دلیلونو لپاره، پخپله SDK کې د دې غلطیتونو هیڅ توضیح شتون نلري. له همدې امله، دا په تجربه سره معلومه شوه چې د نورو کوډونو سره د VDDK تېروتنې یوازې د بائنری څخه ډیسیمال کوډ ته ژباړه ده. دا دوه برخې لري - لومړۍ نیمایي د شرایطو په اړه غیر مستند معلومات دي، او دویمه برخه دوديزه VIX / VDDK تېروتنې دي. د مثال په توګه، که موږ وګورو:

VDDK error: 21036749815809.Unknown error

بیا موږ په زړورتیا سره دا هیکس ته واړوو او 132200000001 ترلاسه کړو. موږ په ساده ډول د 132200 غیرمعلوماتي پیل ردوو، او پاتې به زموږ د خطا کوډ وي (VDDK 1: نامعلومه تېروتنه). د ډیری مکرر VDDK غلطیو په اړه ، پدې وروستیو کې یو جلا شتون درلود مقاله.

اوس راځئ چې وګورو وینډوز.

دلته ، هرڅه چې زموږ لپاره خورا اړین او مهم دي په معیار کې موندل کیدی شي پیښور لیدونکی. مګر دلته یو کیچ شتون لري: د اوږد دود سره سم، وینډوز د غلطۍ بشپړ متن نه ننوځي، مګر یوازې د هغې شمیره. د مثال په توګه، 5 تېروتنه "لاسرسی رد شوی" دی، او 1722 دی "د 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 په هره ممکنه طریقه کارول کیږي کله چې د فایلونو سره کار کوي. د فایلونو جوړول، حذف کول، د لیکلو لپاره خلاصول، د ځانګړتیاوو سره کار کول، او داسې نور.

پورته یادونه وشوه PowerShell مستقیم په Hyper-V نړۍ کې د VIX API د انلاګ په توګه. له بده مرغه، دومره انعطاف وړ نه دی: په فعالیت کې ډیری محدودیتونه، دا د کوربه هرې نسخې سره کار نه کوي او نه د ټولو میلمنو سره.

RPC (د ریموټ پروسیجر کال) زه فکر نه کوم چې یو واحد سړی شتون لري چې د وینډوز سره یې کار کړی وي چې د RPC پورې اړوند غلطی یې نه وي لیدلی. د مشهور غلط مفکورې سره سره، دا یو واحد پروتوکول نه دی، مګر د پیرودونکي سرور پروتوکول چې یو شمیر پیرامیټونه پوره کوي. په هرصورت، که زموږ په لاګونو کې د RPC تېروتنه وي، د وخت 90٪ دا به د مایکروسافټ RPC څخه یوه تېروتنه وي، کوم چې د DCOM (توزیع شوي اجزاو ماډل) برخه ده. تاسو کولی شئ په شبکه کې د دې موضوع په اړه خورا لوی اسناد ومومئ، مګر د هغې لویه برخه خورا زوړ ده. مګر که چیرې د موضوع مطالعې لپاره شدیده لیوالتیا وي، نو زه کولی شم د مقالو وړاندیز وکړم RPC څه شی دی؟, څه ډول RPC کارونه او اوږد لیست د RPC تېروتنې.

زموږ په لاګونو کې د RPC تېروتنې اصلي لاملونه د VBR اجزاوو (سرور> پراکسي، د مثال په توګه) او ډیری وختونه د مخابراتو ستونزو له امله د اړیکو ناکامه هڅې دي.

د ټولو سرونو په مینځ کې پورتنۍ برخه تېروتنه ده د RPC سرور شتون نلري (1722). په ساده شرایطو کې، پیرودونکي نشي کولی د سرور سره اړیکه جوړه کړي. څنګه او ولې - هیڅ یو ځواب شتون نلري، مګر معمولا دا د تصدیق کولو یا 135 پورټ ته د شبکې لاسرسي سره ستونزه ده. وروستی د متحرک بندر دندې سره د زیربناوو لپاره معمول دی. په دې موضوع کې، حتی شتون لري جلا HF. او مایکروسافټ لري لوی لارښود د ناکامۍ لامل موندلو لپاره.

دویمه خورا مشهوره تېروتنه: د پای ټکي نقشه کونکي (1753) څخه نور پای ټکي شتون نلري. د RPC مراجع یا سرور ځان ته د پورټ په ټاکلو کې پاتې راغلی. معمولا واقع کیږي کله چې سرور (زموږ په قضیه کې د میلمه ماشین) تنظیم شوی ترڅو په متحرک ډول د محدود حد څخه بندرونه تخصیص کړي چې پای ته رسیدلی وي. او که تاسو د پیرودونکي اړخ څخه لاګ ان شئ (زموږ په قضیه کې ، د VBR سرور) ، د دې معنی دا ده چې زموږ VeeamVssAgent یا پیل نه و یا د RPC انٹرفیس په توګه راجستر شوی نه و. په دې موضوع کې هم شتون لري جلا HF.

ښه ، د غوره 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 کې د یو څه فشار سره جلا مقاله جوړه کړم ، مګر د اوس لپاره تاسو کولی شئ د لوستلو هڅه وکړئ دا تفصیل. یوازې محتاط اوسئ، ځکه. په فلش کې د VSS د پوهیدو هڅه کولی شي د دماغ ټپي کیدو لامل شي.

په دې کې، شاید، موږ ودروو. زه د بشپړ شوي لومړني شیانو تشریح کولو دنده په پام کې نیسم، نو په راتلونکي فصل کې به موږ دمخه لاګونه وګورو. مګر که تاسو کومه پوښتنه لرئ، په تبصرو کې د هغوی څخه پوښتنه وکړئ.

سرچینه: www.habr.com

Add a comment