យើងបន្តការជ្រមុជរបស់យើងចូលទៅក្នុងពិភពដ៏គួរឱ្យចាប់អារម្មណ៍នៃការទស្សន៍ទាយ ... ការដោះស្រាយបញ្ហាដោយកំណត់ហេតុ។ IN យើងបានយល់ស្របលើអត្ថន័យនៃពាក្យជាមូលដ្ឋាន ហើយមើលទៅលើរចនាសម្ព័ន្ធទាំងមូលរបស់ Veeam ជាកម្មវិធីតែមួយដោយភ្នែកម្ខាង។ ភារកិច្ចសម្រាប់ឯកសារនេះគឺដើម្បីស្វែងយល់ពីរបៀបដែលឯកសារកំណត់ហេតុត្រូវបានបង្កើតឡើង តើព័ត៌មានប្រភេទណាដែលត្រូវបានបង្ហាញនៅក្នុងពួកវា និងមូលហេតុដែលពួកគេមើលទៅតាមរបៀបដែលពួកគេមើលទៅ។
តើអ្នកគិតថា "កំណត់ហេតុ" ទាំងនេះជាអ្វី? យោងទៅតាមភាគច្រើន កំណត់ហេតុនៃកម្មវិធីណាមួយគួរតែត្រូវបានផ្តល់តួនាទីជាប្រភេទនៃអង្គភាពដ៏មានអំណាច ដែលភាគច្រើនមានបន្លែនៅកន្លែងណាមួយនៅក្នុងទីធ្លាខាងក្រោយផ្ទះ ប៉ុន្តែនៅពេលដ៏ត្រឹមត្រូវលេចចេញជារូបរាងចេញពីកន្លែងណាដែលមានពាសដែកភ្លឺចាំង និងជួយសង្គ្រោះមនុស្សគ្រប់គ្នា។ នោះគឺពួកគេគួរតែមានអ្វីគ្រប់យ៉ាងចាប់ពីកំហុសតិចតួចបំផុតនៅក្នុងសមាសធាតុនីមួយៗរហូតដល់ប្រតិបត្តិការមូលដ្ឋានទិន្នន័យនីមួយៗ។ ហើយដូច្នេះបន្ទាប់ពីកំហុសវាត្រូវបានសរសេរភ្លាមៗពីរបៀបផ្សេងទៀតដើម្បីជួសជុលវា។ ហើយទាំងអស់នេះគួរតែសមនឹងពីរបីមេកាបៃ, មិនមានទៀតទេ។ វាគ្រាន់តែជាអត្ថបទ! ឯកសារអត្ថបទមិនអាចយករាប់សិបជីហ្គាបៃបានទេ ខ្ញុំបានឮវានៅកន្លែងណាមួយ!
ដូច្នេះកំណត់ហេតុ
នៅក្នុងពិភពពិត កំណត់ហេតុគ្រាន់តែជាបណ្ណសារនៃព័ត៌មានរោគវិនិច្ឆ័យប៉ុណ្ណោះ។ ហើយអ្វីដែលត្រូវរក្សាទុកនៅទីនោះ កន្លែងដែលត្រូវយកព័ត៌មានសម្រាប់ការផ្ទុក និងថាតើវាត្រូវលម្អិតយ៉ាងណានោះ គឺអាស្រ័យលើអ្នកអភិវឌ្ឍន៍ខ្លួនឯងជាអ្នកសម្រេចចិត្ត។ មាននរណាម្នាក់ដើរតាមគន្លងនៃភាពតិចតួចបំផុតដោយរក្សាកំណត់ត្រានៃកម្រិត ON/OFF ហើយនរណាម្នាក់ឧស្សាហ៍ចាប់យកអ្វីគ្រប់យ៉ាងដែលពួកគេអាចទៅដល់បាន។ ទោះបីជាមានជម្រើសកម្រិតមធ្យមជាមួយនឹងសមត្ថភាពក្នុងការជ្រើសរើសអ្វីដែលគេហៅថាកម្រិតកំណត់ហេតុក៏ដោយ នៅពេលដែលអ្នកខ្លួនអ្នកបង្ហាញពីរបៀបដែលព័ត៌មានលំអិតដែលអ្នកចង់រក្សាទុក និងទំហំថាសបន្ថែមដែលអ្នកមាន =) VBR មានប្រាំមួយកម្រិត។ ហើយជឿខ្ញុំ អ្នកមិនចង់ឃើញអ្វីដែលកើតឡើងជាមួយនឹងការកត់ត្រាលម្អិតបំផុតជាមួយនឹងទំហំទំនេរនៅលើថាសរបស់អ្នកទេ។
ល្អ យើងបានយល់យ៉ាងច្បាស់អំពីអ្វីដែលយើងចង់រក្សាទុក ប៉ុន្តែសំណួរស្របច្បាប់កើតឡើង៖ តើត្រូវយកព័ត៌មាននេះមកពីណា? ជាការពិតណាស់ យើងបង្កើតជាផ្នែកនៃព្រឹត្តិការណ៍សម្រាប់កត់ត្រាខ្លួនយើងដោយដំណើរការផ្ទៃក្នុងរបស់យើង។ ប៉ុន្តែអ្វីដែលត្រូវធ្វើនៅពេលដែលមានអន្តរកម្មជាមួយបរិយាកាសខាងក្រៅ? ដើម្បីកុំឱ្យធ្លាក់ចូលទៅក្នុងឋាននរកនៃឈើច្រត់ និងកង់ Veeam មានទំនោរមិនបង្កើតការច្នៃប្រឌិតដែលបានបង្កើតរួចហើយ។ នៅពេលណាដែលមាន API ដែលត្រៀមរួចជាស្រេច មុខងារដែលភ្ជាប់មកជាមួយ បណ្ណាល័យ ជាដើម យើងនឹងផ្តល់ចំណូលចិត្តដល់ជម្រើសដែលត្រៀមរួចជាស្រេច មុនពេលចាប់ផ្តើមធ្វើរបងការពាររបស់យើង។ ទោះបីក្រោយក៏គ្រប់គ្រាន់ដែរ។ ដូច្នេះនៅពេលវិភាគកំណត់ហេតុ វាជាការសំខាន់ដែលត្រូវយល់ថាចំណែកនៃកំហុសរបស់សត្វតោធ្លាក់លើសារពី APIs ភាគីទីបី ការហៅប្រព័ន្ធ និងបណ្ណាល័យផ្សេងទៀត។ ក្នុងករណីនេះ តួនាទីរបស់ VBR មកដល់ការបញ្ជូនបន្តកំហុសទាំងនេះទៅកាន់ឯកសារកំណត់ហេតុ។ ហើយភារកិច្ចចម្បងរបស់អ្នកប្រើគឺត្រូវរៀនយល់ថាបន្ទាត់មួយណាមកពីអ្នកណា ហើយអ្វីដែលអ្នកប្រើនេះត្រូវទទួលខុសត្រូវ។ ដូច្នេះប្រសិនបើលេខកូដកំហុសពីកំណត់ហេតុ VBR នាំអ្នកទៅកាន់ទំព័រ MSDN នោះជាការល្អ និងត្រឹមត្រូវ។
ដូចដែលយើងបានព្រមព្រៀងគ្នាពីមុន៖ Veeam គឺជាកម្មវិធីដែលគេហៅថា SQL-based ។ នេះមានន័យថាការកំណត់ទាំងអស់ ព័ត៌មានទាំងអស់ និងជាទូទៅអ្វីគ្រប់យ៉ាងដែលចាំបាច់សម្រាប់ដំណើរការធម្មតាប៉ុណ្ណោះ - អ្វីគ្រប់យ៉ាងត្រូវបានរក្សាទុកនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់វា។ ដូច្នេះការពិតសាមញ្ញ៖ អ្វីដែលមិនមាននៅក្នុងកំណត់ហេតុគឺទំនងជានៅក្នុងមូលដ្ឋានទិន្នន័យ។ ប៉ុន្តែនេះមិនមែនជាគ្រាប់កាំភ្លើងទេ៖ របស់ខ្លះមិនមាននៅក្នុងកំណត់ហេតុមូលដ្ឋាននៃសមាសធាតុ Veeam ហើយក៏មិននៅក្នុងមូលដ្ឋានទិន្នន័យរបស់វាដែរ។ ដូច្នេះ អ្នកត្រូវរៀនពីរបៀបដើម្បីសិក្សាកំណត់ហេតុម៉ាស៊ីន កំណត់ហេតុនៃម៉ាស៊ីនមូលដ្ឋាន និងកំណត់ហេតុនៃអ្វីគ្រប់យ៉ាងដែលពាក់ព័ន្ធនឹងដំណើរការបម្រុងទុក និងស្ដារ។ ហើយវាក៏កើតឡើងផងដែរដែលព័ត៌មានចាំបាច់គឺមិនមាននៅគ្រប់ទីកន្លែងទាល់តែសោះ។ នោះគឺជាវិធី។
ឧទាហរណ៍មួយចំនួននៃ APIs បែបនេះ
បញ្ជីនេះមិនមានគោលបំណងពេញលេញនោះទេ ដូច្នេះមិនចាំបាច់ស្វែងរកការពិតចុងក្រោយនៅក្នុងវាទេ។ គោលបំណងរបស់វាគឺដើម្បីបង្ហាញតែ APIs និងបច្ចេកវិទ្យាភាគីទីបីទូទៅបំផុតដែលប្រើនៅក្នុងផលិតផលរបស់យើង។
ចូរចាប់ផ្តើមជាមួយ VMware.
ទីមួយនៅក្នុងបញ្ជីនឹងមាន vSphere API. ប្រើសម្រាប់ការផ្ទៀងផ្ទាត់ អានឋានានុក្រម បង្កើត និងលុបរូបថត ស្នើសុំព័ត៌មានអំពីម៉ាស៊ីន និងច្រើនទៀត (ច្រើនណាស់)។ មុខងារនៃដំណោះស្រាយគឺធំទូលាយណាស់ ដូច្នេះខ្ញុំអាចណែនាំ VMware vSphere API Reference សម្រាប់កំណែ и . សម្រាប់កំណែបច្ចុប្បន្នច្រើនទៀត អ្វីគ្រប់យ៉ាងគឺគ្រាន់តែ googled ប៉ុណ្ណោះ។
VIX API. វេទមន្តខ្មៅនៃ hypervisor សម្រាប់ការដែលមានដាច់ដោយឡែកមួយ។ . VMware API សម្រាប់ធ្វើការជាមួយឯកសារនៅលើម៉ាស៊ីនដោយមិនភ្ជាប់ទៅពួកវាតាមបណ្តាញ។ ជម្រើសចុងក្រោយនៅពេលដែលអ្នកត្រូវការដាក់ឯកសារនៅក្នុងម៉ាស៊ីនដែលមិនមានបណ្តាញទំនាក់ទំនងល្អជាង។ វាជាការឈឺចាប់ និងឈឺចាប់ ប្រសិនបើឯកសារមានទំហំធំ ហើយម៉ាស៊ីនត្រូវបានផ្ទុក។ ប៉ុន្តែនៅទីនេះច្បាប់ដំណើរការដែលសូម្បីតែ 56,6 Kb / s គឺល្អជាង 0 Kb / s ។ នៅក្នុង Hyper-V រឿងនេះត្រូវបានគេហៅថា PowerShell Direct ។ ប៉ុន្តែនោះគឺមានតែមុន
vSpehere Web Services API ចាប់ផ្តើមពី vSphere 6.0 (ប្រហែលចាប់តាំងពី API នេះត្រូវបានណែនាំជាលើកដំបូងនៅលើកំណែ 5.5) វាត្រូវបានប្រើដើម្បីធ្វើការជាមួយម៉ាស៊ីនភ្ញៀវ និងបានជំនួស VIX ស្ទើរតែគ្រប់ទីកន្លែង។ តាមពិតនេះគឺជា API មួយផ្សេងទៀតសម្រាប់គ្រប់គ្រង vSphere ។ សម្រាប់អ្នកដែលចាប់អារម្មណ៍ខ្ញុំសូមណែនាំឱ្យសិក្សា ហត្ថកម្ម។
VDDK (កញ្ចប់អភិវឌ្ឍន៍ថាសនិម្មិត)។ បណ្ណាល័យដែលត្រូវបានពិភាក្សាដោយផ្នែកនៅក្នុងនេះ។ . ប្រើដើម្បីអានថាសនិម្មិត។ នៅពេលមួយវាជាផ្នែកមួយនៃ VIX ប៉ុន្តែយូរ ៗ ទៅវាត្រូវបានផ្លាស់ប្តូរទៅជាផលិតផលដាច់ដោយឡែក។ ប៉ុន្តែក្នុងនាមជាអ្នកស្នងមរតក វាប្រើកូដកំហុសដូចគ្នានឹង VIX ដែរ។ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួន មិនមានការពិពណ៌នាអំពីកំហុសទាំងនេះនៅក្នុង SDK ខ្លួនឯងទេ។ ដូច្នេះវាត្រូវបានគេរកឃើញជាក់ស្តែងថាកំហុស VDDK ជាមួយលេខកូដផ្សេងទៀតគ្រាន់តែជាការបកប្រែពីលេខគោលពីរទៅលេខកូដទសភាគប៉ុណ្ណោះ។ វាមានពីរផ្នែក - ពាក់កណ្តាលទីមួយគឺជាព័ត៌មានដែលមិនមានឯកសារអំពីបរិបទ ហើយផ្នែកទីពីរគឺជាកំហុស VIX / VDDK ប្រពៃណី។ ឧទាហរណ៍ប្រសិនបើយើងឃើញ៖
VDDK error: 21036749815809.Unknown error
បន្ទាប់មកយើងបម្លែងវាទៅជាគោលដប់ប្រាំមួយយ៉ាងក្លាហាន ហើយទទួលបាន 132200000001។ យើងគ្រាន់តែបោះបង់ការចាប់ផ្តើមដែលមិនមានព័ត៌មាននៃ 132200 ហើយនៅសល់នឹងជាលេខកូដកំហុសរបស់យើង (VDDK 1: Unknown error)។ អំពីកំហុស VDDK ញឹកញាប់បំផុត ទើបតែថ្មីៗនេះមានការដាច់ដោយឡែក .
ឥឡូវនេះសូមក្រឡេកមើល វីនដិន.
នៅទីនេះអ្វីគ្រប់យ៉ាងដែលចាំបាច់និងសំខាន់បំផុតសម្រាប់យើងអាចរកបាននៅក្នុងស្តង់ដារ កម្មវិធីមើលព្រឹត្តិការណ៍ប៉ុន្តែមានចំណុចមួយ៖ យោងតាមប្រពៃណីដ៏យូរអង្វែងមួយ Windows វាមិនកត់ត្រាអត្ថបទកំហុសពេញលេញទេ ប៉ុន្តែកត់ត្រាតែលេខរបស់វាប៉ុណ្ណោះ។ ឧទាហរណ៍ កំហុស 5 មានន័យថា "ការចូលប្រើត្រូវបានបដិសេធ" 1722 មានន័យថា "ម៉ាស៊ីនមេ RPC មិនអាចប្រើបាន" និង 10060 មានន័យថា "ការតភ្ជាប់អស់ពេល"។ ជាការពិតណាស់ វាពិតជាអស្ចារ្យណាស់ ប្រសិនបើអ្នកចងចាំកំហុសទូទៅបំផុត ប៉ុន្តែចុះយ៉ាងណាចំពោះកំហុសដែលអ្នកមិនធ្លាប់ឃើញពីមុនមក?
ដូច្នេះហើយ ជីវិតហាក់ដូចជាមិនដូចទឹកឃ្មុំទាល់តែសោះ កំហុសក៏ត្រូវបានរក្សាទុកក្នុងទម្រង់គោលដប់ប្រាំមួយ ដោយមានបុព្វបទ 0x8007 ។ ឧទាហរណ៍ 0x8007000e គឺពិតជា 14 ក្រៅសតិ។ ហេតុអ្វីបានជានិងអ្នកណាដែលការនេះត្រូវបានធ្វើគឺជាអាថ៌កំបាំងដែលលាក់ក្នុងភាពងងឹត។ ទោះយ៉ាងណាក៏ដោយ បញ្ជីពេញលេញនៃកំហុសអាចត្រូវបានទាញយកដោយឥតគិតថ្លៃ និងដោយគ្មានសារ SMS ពី .
និយាយអញ្ចឹង ជួនកាលមានបុព្វបទផ្សេងទៀត មិនមែនត្រឹមតែ 0x8007 ទេ។ ក្នុងស្ថានភាពដ៏ក្រៀមក្រំបែបនេះ ដើម្បីស្វែងយល់ពី HRESULT ("លទ្ធផលដោះស្រាយ") អ្នកត្រូវស្វែងយល់ឱ្យកាន់តែស៊ីជម្រៅថែមទៀត។ សម្រាប់អ្នកអភិវឌ្ឍន៍។ ក្នុងជីវិតធម្មតា ខ្ញុំមិនណែនាំអ្នកឱ្យធ្វើបែបនេះទេ ប៉ុន្តែប្រសិនបើអ្នកស្រាប់តែចុចប្រឆាំងនឹងជញ្ជាំង ឬគ្រាន់តែចង់ដឹងចង់ឃើញ ពេលនេះអ្នកដឹងពីអ្វីដែលត្រូវធ្វើ។
ប៉ុន្តែសមមិត្តនៅ Microsoft បានអាណិតយើងបន្តិចហើយបង្ហាញពិភពលោកនូវឧបករណ៍ប្រើប្រាស់ . នេះគឺជាផ្នែកតូចមួយនៃសុភមង្គលកុងសូលដែលអាចបកប្រែលេខកូដកំហុសទៅជាមនុស្សដោយមិនប្រើ 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 ពិសេសសម្រាប់រឿងនេះ។ ប៉ុន្តែដូចដែលបានបញ្ជាក់រួចមកហើយ អ្វីគ្រប់យ៉ាងដែលមករកយើងក្នុងការឆ្លើយតបនឹងចូលទៅក្នុងកំណត់ហេតុរបស់យើង។ ហើយនៅទីនេះ ដើម្បីឌិគ្រីបវា មនុស្សម្នាក់នឹងត្រូវត្រួតពិនិត្យជានិច្ចនូវស្ទ្រីមនៃស្មារតីនេះ ទាញបំណែកដែលមានកំហុសវីនដូចេញពីវា ឌិគ្រីបពួកវា ហើយបិទភ្ជាប់វាមកវិញ។ ចូរនិយាយដោយស្មោះត្រង់ មិនមែនជាសកម្មភាពដ៏រំភើបបំផុតនោះទេ។
Windows API គ្រប់គ្រងឯកសារ ប្រើក្នុងគ្រប់មធ្យោបាយដែលអាចធ្វើទៅបាន នៅពេលធ្វើការជាមួយឯកសារ។ ការបង្កើតឯកសារ លុប បើកសម្រាប់សរសេរ ធ្វើការជាមួយគុណលក្ខណៈ និងអ្វីៗផ្សេងៗទៀត។ល។
បានរៀបរាប់ខាងលើ PowerShell ផ្ទាល់ ជា analogue នៃ VIX API នៅក្នុងពិភព Hyper-V ។ ជាអកុសល មិនមានភាពបត់បែនទេ៖ ការរឹតបន្តឹងជាច្រើនលើមុខងារ វាមិនដំណើរការជាមួយគ្រប់កំណែរបស់ម៉ាស៊ីន និងមិនមែនជាមួយភ្ញៀវទាំងអស់។
RPC (ការហៅតាមនីតិវិធីពីចម្ងាយ) ខ្ញុំមិនគិតថាមានមនុស្សតែម្នាក់ដែលបានធ្វើការជាមួយ WIndows ដែលមិនបានឃើញកំហុសដែលទាក់ទងនឹង RPC នោះទេ។ ទោះបីជាមានការយល់ខុសដ៏ពេញនិយមក៏ដោយ នេះមិនមែនជាពិធីការតែមួយទេ ប៉ុន្តែពិធីការម៉ាស៊ីនភ្ញៀវ-ម៉ាស៊ីនមេណាមួយដែលបំពេញនូវប៉ារ៉ាម៉ែត្រមួយចំនួន។ ទោះយ៉ាងណាក៏ដោយប្រសិនបើមានកំហុស RPC នៅក្នុងកំណត់ហេតុរបស់យើង 90% នៃពេលវេលាវានឹងជាកំហុសពី Microsoft RPC ដែលជាផ្នែកមួយនៃ DCOM (Distributed Component Object Model) ។ អ្នកអាចស្វែងរកឯកសារយ៉ាងច្រើនអំពីប្រធានបទនេះនៅលើបណ្តាញ ប៉ុន្តែចំណែករបស់សត្វតោគឺហួសសម័យហើយ។ ប៉ុន្តែប្រសិនបើមានបំណងប្រាថ្នាស្រួចស្រាវដើម្បីសិក្សាប្រធានបទនោះខ្ញុំអាចណែនាំអត្ថបទ , និងបញ្ជីវែង .
មូលហេតុចម្បងនៃកំហុស RPC នៅក្នុងកំណត់ហេតុរបស់យើងគឺបរាជ័យក្នុងការព្យាយាមទំនាក់ទំនងរវាងសមាសធាតុ VBR (ឧទាហរណ៍ម៉ាស៊ីនមេ > ប្រូកស៊ី) ហើយភាគច្រើនជាញឹកញាប់ដោយសារបញ្ហាទំនាក់ទំនង។
កំពូលកំពូលក្នុងចំណោមកំពូលទាំងអស់គឺកំហុស ម៉ាស៊ីនមេ RPC មិនអាចប្រើបានទេ (1722)។ ក្នុងន័យសាមញ្ញ អតិថិជនមិនអាចបង្កើតការតភ្ជាប់ជាមួយម៉ាស៊ីនមេបានទេ។ របៀប និងមូលហេតុ - មិនមានចម្លើយតែមួយទេ ប៉ុន្តែជាធម្មតាវាមានបញ្ហាជាមួយនឹងការផ្ទៀងផ្ទាត់ ឬជាមួយការចូលប្រើបណ្តាញទៅកាន់ច្រក 135។ ក្រោយមកទៀតគឺជាតួយ៉ាងសម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធដែលមានការកំណត់ច្រកថាមវន្ត។ នៅលើប្រធានបទនេះមានសូម្បីតែ . ហើយ Microsoft មាន ដើម្បីស្វែងរកមូលហេតុនៃការបរាជ័យ។
កំហុសដែលពេញនិយមបំផុតទីពីរ៖ មិនមានចំណុចបញ្ចប់ទៀតទេដែលអាចរកបានពីកម្មវិធីផែនទីចំណុចបញ្ចប់ (1753) ។ ម៉ាស៊ីនភ្ញៀវ RPC ឬម៉ាស៊ីនមេបានបរាជ័យក្នុងការកំណត់ច្រកដោយខ្លួនឯង។ ជាធម្មតាកើតឡើងនៅពេលដែលម៉ាស៊ីនមេ (ក្នុងករណីរបស់យើង ម៉ាស៊ីនភ្ញៀវ) ត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីបែងចែកច្រកដោយថាមវន្តពីជួរតូចចង្អៀតដែលបានបញ្ចប់។ ហើយប្រសិនបើអ្នកចូលពីខាងអតិថិជន (ក្នុងករណីរបស់យើង ម៉ាស៊ីនមេ VBR) នេះមានន័យថា VeeamVssAgent របស់យើងមិនបានចាប់ផ្តើម ឬមិនត្រូវបានចុះឈ្មោះជាចំណុចប្រទាក់ RPC ទេ។ ក៏មានលើប្រធានបទនេះដែរ។ .
ជាការប្រសើរណាស់ ដើម្បីបញ្ចប់កំហុស RPC កំពូលទាំង 3 សូមចាំថាការហៅមុខងារ RPC បានបរាជ័យ (1726) ។ លេចឡើងប្រសិនបើការតភ្ជាប់ត្រូវបានបង្កើតឡើង ប៉ុន្តែសំណើ RPC មិនត្រូវបានដំណើរការទេ។ ជាឧទាហរណ៍ យើងស្នើសុំព័ត៌មានអំពីស្ថានភាពរបស់ VSS (ភ្លាមៗនៅពេលនេះ អណ្តូងរ៉ែស្រមោលមួយកំពុងត្រូវបានបង្កើតឡើងនៅទីនោះ ហើយយើងកំពុងព្យាយាមឡើង) ហើយឆ្លើយតបនឹងពួកយើង សូមបិទមាត់មិនអើពើ។
Windows API បម្រុងទុកកាសែត ត្រូវការដើម្បីធ្វើការជាមួយបណ្ណាល័យកាសែតឬដ្រាយ។ ដូចដែលខ្ញុំបាននិយាយនៅដើមដំបូង: យើងមិនសប្បាយចិត្តក្នុងការសរសេរកម្មវិធីបញ្ជារបស់យើងទេហើយបន្ទាប់មករងទុក្ខជាមួយនឹងការគាំទ្រនៃឧបករណ៍នីមួយៗ។ ដូច្នេះ vim មិនមានកម្មវិធីបញ្ជាផ្ទាល់ខ្លួនទេ។ ទាំងអស់តាមរយៈ API ស្តង់ដារ ការគាំទ្រដែលត្រូវបានអនុវត្តដោយអ្នកលក់ផ្នែករឹងខ្លួនឯង។ ឡូជីខលច្រើនណាស់មែនទេ?
អេសប៊ីប៊ី / ស៊ីអាយអេស។ មនុស្សគ្រប់គ្នាសរសេរវាជាមួយគ្នាតាមទម្លាប់ ទោះបីជាមិនមែនគ្រប់គ្នាចងចាំថា CIFS (Common Internet File System) គ្រាន់តែជាកំណែផ្តាច់មុខរបស់ SMB (Server Message Block) ក៏ដោយ។ ដូច្នេះមិនមានអ្វីខុសជាមួយការធ្វើឱ្យគោលគំនិតទាំងនេះមានលក្ខណៈទូទៅនោះទេ។ ម្យ៉ាងវិញទៀត Samba គឺ... Linuxវាជាការអនុវត្ត Unix ហើយវាមានលក្ខណៈប្លែករបស់វា ប៉ុន្តែខ្ញុំនិយាយវែងឆ្ងាយជាងនេះ។ អ្វីដែលសំខាន់នៅទីនេះគឺថា នៅពេលដែល Veeam ស្នើសុំសរសេរអ្វីមួយទៅកាន់ផ្លូវ UNC (ថតម៉ាស៊ីនមេ) ម៉ាស៊ីនមេប្រើឋានានុក្រមនៃកម្មវិធីបញ្ជាប្រព័ន្ធឯកសារ រួមទាំង mup និង mrxsmb ដើម្បីសរសេរទៅកាន់ដ្រាយដែលបានចែករំលែក។ ជាលទ្ធផល កម្មវិធីបញ្ជាទាំងនេះក៏នឹងបង្កើតកំហុសផងដែរ។
មិនអាចធ្វើបានដោយគ្មាន Winsock APIប្រសិនបើមានអ្វីមួយត្រូវធ្វើនៅលើបណ្តាញ VBR ដំណើរការតាមរយៈ Windows Socket API ដែលត្រូវបានគេស្គាល់ជាទូទៅថា Winsock។ ដូច្នេះប្រសិនបើយើងឃើញការតភ្ជាប់ IP:Port នៅក្នុងកំណត់ហេតុ នោះហើយគឺជាវា។ ឯកសារផ្លូវការមានបញ្ជីល្អនៃអ្វីដែលអាចធ្វើទៅបាន .
បានរៀបរាប់ខាងលើ WMI (Windows ឧបករណ៍គ្រប់គ្រងគឺជាប្រភេទ API ដ៏មានអានុភាពសម្រាប់គ្រប់គ្រងអ្វីៗគ្រប់យ៉ាង និងមនុស្សគ្រប់គ្នានៅក្នុងពិភពលោក។ Windowsឧទាហរណ៍ នៅពេលធ្វើការជាមួយ Hyper-V សំណើស្ទើរតែទាំងអស់ទៅកាន់ម៉ាស៊ីនមេត្រូវបានដំណើរការតាមរយៈវា។ សរុបមក វាពិតជាមិនអាចខ្វះបាន និងមានអានុភាពខ្លាំង។ ឧបករណ៍ WBEMtest.exe ដែលភ្ជាប់មកជាមួយមានប្រយោជន៍ខ្លាំងណាស់ នៅពេលព្យាយាមរកមើលអ្វីដែលខូច។
ហើយចុងក្រោយនៅក្នុងបញ្ជី ប៉ុន្តែមិនមានន័យយ៉ាងហោចណាស់នៅក្នុងសារៈសំខាន់ - VSS (ទំហំផ្ទុកស្រមោល) ។ ប្រធានបទគឺដូចជាមិនចេះអស់ និងអាថ៌កំបាំង ដូចដែលឯកសារជាច្រើនត្រូវបានសរសេរនៅលើវា។ Shadow Copy ត្រូវបានគេយល់យ៉ាងសាមញ្ញបំផុតថាជាប្រភេទរូបថតពិសេសមួយ ដែលនៅក្នុងខ្លឹមសាររបស់វាគឺ។ សូមអរគុណដល់គាត់ អ្នកអាចធ្វើការបម្រុងទុកកម្មវិធីដែលស្របគ្នានឹងកម្មវិធីនៅក្នុង VMware និងស្ទើរតែទាំងអស់នៅក្នុង Hyper-V ។ ខ្ញុំមានគម្រោងបង្កើតអត្ថបទដោយឡែកមួយដោយមានការច្របាច់ខ្លះលើ VSS ប៉ុន្តែសម្រាប់ពេលនេះអ្នកអាចព្យាយាមអាន . ប្រយ័ត្នព្រោះ។ ការព្យាយាមយល់ពី VSS នៅក្នុងពន្លឺអាចនាំឱ្យមានរបួសខួរក្បាល។
នៅលើនេះ ប្រហែលជាយើងអាចបញ្ឈប់បាន។ ខ្ញុំពិចារណាលើភារកិច្ចនៃការពន្យល់អំពីអ្វីដែលជាមូលដ្ឋានបំផុតដែលបានបញ្ចប់ ដូច្នេះនៅក្នុងជំពូកបន្ទាប់ យើងនឹងពិនិត្យមើលកំណត់ហេតុរួចហើយ។ ប៉ុន្តែប្រសិនបើអ្នកមានសំណួរណាមួយ សូមសួរពួកគេក្នុងមតិយោបល់។
ប្រភព: www.habr.com
