ໄມ້ທ່ອນມາຈາກໃສ? Veeam Log Diving

ພວກເຮົາສືບຕໍ່ immersion ຂອງພວກເຮົາເຂົ້າໄປໃນໂລກ fascinating ຂອງການຄາດເດົາ ... ການແກ້ໄຂບັນຫາໂດຍບັນທຶກ. IN ບົດຄວາມທີ່ຜ່ານມາ ພວກ​ເຮົາ​ໄດ້​ເຫັນ​ດີ​ກັບ​ຄວາມ​ຫມາຍ​ຂອງ​ຂໍ້​ກໍາ​ນົດ​ພື້ນ​ຖານ​ແລະ​ເບິ່ງ​ໂຄງ​ປະ​ກອບ​ການ​ໂດຍ​ລວມ​ຂອງ Veeam ເປັນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ດຽວ​ກັບ​ຕາ​ດຽວ. ວຽກງານສໍາລັບອັນນີ້ແມ່ນເພື່ອຄິດອອກວິທີການບັນທຶກໄຟລ໌ຖືກສ້າງຕັ້ງຂຶ້ນ, ປະເພດຂອງຂໍ້ມູນໃດທີ່ຖືກສະແດງຢູ່ໃນພວກມັນແລະເປັນຫຍັງພວກມັນເບິ່ງວິທີການເບິ່ງ.

ເຈົ້າຄິດວ່າ "ບັນທຶກ" ເຫຼົ່ານີ້ແມ່ນແນວໃດ? ອີງຕາມການຫຼາຍທີ່ສຸດ, ບັນທຶກຂອງຄໍາຮ້ອງສະຫມັກໃດຫນຶ່ງຄວນໄດ້ຮັບການມອບຫມາຍພາລະບົດບາດຂອງປະເພດຂອງ omnipotent ຫນ່ວຍງານທີ່ເກືອບທຸກເວລາ vegetates somewhere ໃນ backyard ໄດ້, ແຕ່ວ່າໃນປັດຈຸບັນສິດທິໃນການປະກົດວ່າບໍ່ມີບ່ອນໃດເກາະເຫຼື້ອມແລະຊ່ວຍປະຢັດທຸກຄົນ. ນັ້ນແມ່ນ, ພວກເຂົາຄວນຈະມີທຸກສິ່ງທຸກຢ່າງ, ຈາກຄວາມຜິດພາດເລັກນ້ອຍໃນແຕ່ລະອົງປະກອບໄປສູ່ການເຮັດທຸລະກໍາຖານຂໍ້ມູນສ່ວນບຸກຄົນ. ແລະດັ່ງນັ້ນ, ຫຼັງຈາກຄວາມຜິດພາດ, ມັນໄດ້ຖືກຂຽນທັນທີວ່າວິທີການອື່ນທີ່ຈະແກ້ໄຂມັນ. ແລະທັງຫມົດນີ້ຄວນຈະເຫມາະໃນສອງສາມ megabytes, ບໍ່ມີອີກ. ມັນເປັນພຽງແຕ່ຂໍ້ຄວາມ! ໄຟລ໌ຂໍ້ຄວາມບໍ່ສາມາດໃຊ້ເວລາຫຼາຍສິບ gigabytes, ຂ້ອຍໄດ້ຍິນມັນຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ!

ດັ່ງນັ້ນໄມ້ທ່ອນ

ໃນໂລກທີ່ແທ້ຈິງ, ບັນທຶກແມ່ນພຽງແຕ່ເກັບຂໍ້ມູນການວິນິດໄສ. ແລະສິ່ງທີ່ຈະເກັບຮັກສາໄວ້ບ່ອນນັ້ນ, ບ່ອນທີ່ໄດ້ຮັບຂໍ້ມູນສໍາລັບການເກັບຮັກສາແລະລາຍລະອຽດທີ່ມັນຄວນຈະເປັນ, ແມ່ນຂຶ້ນກັບນັກພັດທະນາເອງທີ່ຈະຕັດສິນໃຈ. ບາງຄົນປະຕິບັດຕາມເສັ້ນທາງຂອງ minimalism ໂດຍການຮັກສາບັນທຶກຂອງລະດັບ ON / OFF, ແລະບາງຄົນທີ່ດຸຫມັ່ນ rakes ທຸກສິ່ງທຸກຢ່າງທີ່ເຂົາເຈົ້າສາມາດບັນລຸ. ເຖິງແມ່ນວ່າຍັງມີທາງເລືອກລະດັບກາງທີ່ມີຄວາມສາມາດໃນການເລືອກອັນທີ່ເອີ້ນວ່າລະດັບການເຂົ້າສູ່ລະບົບ, ເມື່ອທ່ານສະແດງຂໍ້ມູນລາຍລະອຽດທີ່ທ່ານຕ້ອງການເກັບຮັກສາແລະຈໍານວນພື້ນທີ່ດິດພິເສດທີ່ທ່ານມີ =) VBR ມີຫົກລະດັບດັ່ງກ່າວ, ໂດຍວິທີທາງການ. ແລະ, ເຊື່ອຂ້ອຍ, ເຈົ້າບໍ່ຕ້ອງການທີ່ຈະເຫັນສິ່ງທີ່ເກີດຂື້ນກັບບັນທຶກລາຍລະອຽດທີ່ສຸດທີ່ມີພື້ນທີ່ຫວ່າງໃນແຜ່ນຂອງທ່ານ.

ດີ. ພວກເຮົາເຂົ້າໃຈປະມານສິ່ງທີ່ພວກເຮົາຕ້ອງການປະຫຍັດ, ແຕ່ຄໍາຖາມທີ່ຖືກຕ້ອງເກີດຂື້ນ: ເອົາຂໍ້ມູນນີ້ມາຈາກໃສ? ແນ່ນອນ, ພວກເຮົາປະກອບເປັນສ່ວນຫນຶ່ງຂອງເຫດການສໍາລັບການບັນທຶກຕົວເອງໂດຍຂະບວນການພາຍໃນຂອງພວກເຮົາ. ແຕ່ສິ່ງທີ່ຕ້ອງເຮັດເມື່ອມີປະຕິສໍາພັນກັບສະພາບແວດລ້ອມພາຍນອກ? ໃນຄໍາສັ່ງທີ່ຈະບໍ່ເລື່ອນເຂົ້າໄປໃນ hell ຂອງ crutches ແລະລົດຖີບ, Veeam ມັກຈະບໍ່ປະດິດ inventions ທີ່ໄດ້ invented ແລ້ວ. ເມື່ອໃດກໍ່ຕາມທີ່ມີ API ພ້ອມທີ່ຈະເຮັດ, ຟັງຊັນໃນຕົວ, ຫ້ອງສະຫມຸດ, ແລະອື່ນໆ, ພວກເຮົາຈະໃຫ້ຄວາມຕ້ອງການກັບທາງເລືອກທີ່ກຽມພ້ອມກ່ອນທີ່ຈະເລີ່ມຕົ້ນຮົ້ວ contraptions ຂອງພວກເຮົາ. ເຖິງແມ່ນວ່າສຸດທ້າຍກໍ່ພຽງພໍ. ດັ່ງນັ້ນ, ໃນເວລາທີ່ການວິເຄາະບັນທຶກ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າສ່ວນແບ່ງຂອງຄວາມຜິດພາດຂອງຊ້າງຕົກຢູ່ໃນຂໍ້ຄວາມຈາກ APIs ພາກສ່ວນທີສາມ, ການໂທລະບົບແລະຫ້ອງສະຫມຸດອື່ນໆ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, ພາ​ລະ​ບົດ​ບາດ​ຂອງ VBR ມາ​ລົງ​ໃນ​ການ​ສົ່ງ​ຕໍ່​ຄວາມ​ຜິດ​ພາດ​ເຫຼົ່າ​ນີ້​ກັບ​ໄຟລ​໌​ບັນ​ທຶກ​ເປັນ​. ແລະວຽກງານຕົ້ນຕໍຂອງຜູ້ໃຊ້ແມ່ນເພື່ອຮຽນຮູ້ທີ່ຈະເຂົ້າໃຈວ່າສາຍແມ່ນມາຈາກໃຜ, ແລະ "ໃຜ" ນີ້ຮັບຜິດຊອບແມ່ນຫຍັງ. ດັ່ງນັ້ນຖ້າລະຫັດຂໍ້ຜິດພາດຈາກບັນທຶກ VBR ພາທ່ານໄປຫາຫນ້າ MSDN, ນັ້ນກໍ່ດີແລະຖືກຕ້ອງ.

ດັ່ງທີ່ພວກເຮົາໄດ້ຕົກລົງກັນກ່ອນຫນ້ານີ້: Veeam ແມ່ນອັນທີ່ເອີ້ນວ່າຄໍາຮ້ອງສະຫມັກທີ່ໃຊ້ SQL. ນີ້ຫມາຍຄວາມວ່າການຕັ້ງຄ່າທັງຫມົດ, ຂໍ້ມູນທັງຫມົດແລະໂດຍທົ່ວໄປແລ້ວທຸກສິ່ງທຸກຢ່າງທີ່ຈໍາເປັນພຽງແຕ່ສໍາລັບການເຮັດວຽກປົກກະຕິ - ທຸກສິ່ງທຸກຢ່າງຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນຂອງມັນ. ເພາະສະນັ້ນຄວາມຈິງທີ່ງ່າຍດາຍ: ສິ່ງທີ່ບໍ່ຢູ່ໃນບັນທຶກແມ່ນສ່ວນຫຼາຍແມ່ນຢູ່ໃນຖານຂໍ້ມູນ. ແຕ່ນີ້ບໍ່ແມ່ນລູກປືນເງິນທັງ: ບາງສິ່ງທີ່ບໍ່ໄດ້ຢູ່ໃນບັນທຶກທ້ອງຖິ່ນຂອງອົງປະກອບ Veeam, ຫຼືຢູ່ໃນຖານຂໍ້ມູນຂອງມັນ. ດັ່ງນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຮຽນຮູ້ວິທີການສຶກສາບັນທຶກຂອງເຈົ້າພາບ, ບັນທຶກຂອງເຄື່ອງຈັກໃນທ້ອງຖິ່ນແລະບັນທຶກຂອງທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບຂະບວນການສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູ. ແລະມັນຍັງເກີດຂື້ນວ່າຂໍ້ມູນທີ່ຈໍາເປັນແມ່ນບໍ່ມີຢູ່ທຸກບ່ອນ. ນັ້ນແມ່ນວິທີການ. 

ບາງຕົວຢ່າງຂອງ APIs ດັ່ງກ່າວ

ບັນຊີລາຍຊື່ນີ້ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອໃຫ້ສົມບູນແບບພິເສດ, ດັ່ງນັ້ນບໍ່ຈໍາເປັນຕ້ອງຊອກຫາຄວາມຈິງສູງສຸດໃນມັນ. ຈຸດປະສົງຂອງມັນແມ່ນພຽງແຕ່ສະແດງໃຫ້ເຫັນ APIs ພາກສ່ວນທີສາມທົ່ວໄປທີ່ສຸດແລະເຕັກໂນໂລຢີທີ່ໃຊ້ໃນຜະລິດຕະພັນຂອງພວກເຮົາ.

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍ VMware. 

ຫນ້າທໍາອິດໃນບັນຊີລາຍຊື່ຈະເປັນ vSphere API. ໃຊ້ສໍາລັບການກວດສອບຄວາມຖືກຕ້ອງ, ການອ່ານລໍາດັບຊັ້ນ, ການສ້າງແລະການລຶບພາບຖ່າຍ, ການຮ້ອງຂໍຂໍ້ມູນກ່ຽວກັບເຄື່ອງຈັກ, ແລະຫຼາຍ (ຫຼາຍ) ຫຼາຍ. ການເຮັດວຽກຂອງການແກ້ໄຂແມ່ນກວ້າງຫຼາຍ, ດັ່ງນັ້ນຂ້ອຍສາມາດແນະນໍາ VMware vSphere API Reference ສໍາລັບສະບັບ. 5.5 и 6.0. ສໍາລັບສະບັບປະຈຸບັນເພີ່ມເຕີມ, ທຸກສິ່ງທຸກຢ່າງແມ່ນພຽງແຕ່ googled.

VIX API. magic ສີດໍາຂອງ 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 (ຊຸດການພັດທະນາ Virtual Disk). ຫໍສະຫມຸດ, ເຊິ່ງໄດ້ຖືກປຶກສາຫາລືບາງສ່ວນໃນເລື່ອງນີ້ ບົດຄວາມ. ໃຊ້ເພື່ອອ່ານແຜ່ນ virtual. ຄັ້ງຫນຶ່ງມັນເປັນສ່ວນຫນຶ່ງຂອງ VIX, ແຕ່ເມື່ອເວລາຜ່ານໄປ, ມັນໄດ້ຖືກຍ້າຍເຂົ້າໄປໃນຜະລິດຕະພັນແຍກຕ່າງຫາກ. ແຕ່ໃນຖານະເປັນມໍລະດົກ, ມັນໃຊ້ລະຫັດຄວາມຜິດພາດດຽວກັນກັບ VIX. ແຕ່ສໍາລັບບາງເຫດຜົນ, ບໍ່ມີຄໍາອະທິບາຍກ່ຽວກັບຄວາມຜິດພາດເຫຼົ່ານີ້ຢູ່ໃນ SDK ຕົວຂອງມັນເອງ. ດັ່ງນັ້ນ, ມັນໄດ້ຖືກພົບເຫັນຢ່າງຈະແຈ້ງວ່າຄວາມຜິດພາດ VDDK ກັບລະຫັດອື່ນໆແມ່ນພຽງແຕ່ການແປພາສາຈາກສອງຫາລະຫັດທົດສະນິຍົມ. ມັນປະກອບດ້ວຍສອງສ່ວນ - ເຄິ່ງທໍາອິດແມ່ນບໍ່ມີເອກະສານກ່ຽວກັບສະພາບການ, ແລະສ່ວນທີສອງແມ່ນຄວາມຜິດພາດ VIX / VDDK ແບບດັ້ງເດີມ. ຕົວຢ່າງ, ຖ້າພວກເຮົາເຫັນ:

VDDK error: 21036749815809.Unknown error

ຫຼັງຈາກນັ້ນ, ພວກເຮົາຢ່າງກ້າຫານແປງນີ້ເປັນ hex ແລະໄດ້ຮັບ 132200000001. ພວກເຮົາພຽງແຕ່ຍົກເລີກການເລີ່ມຕົ້ນທີ່ບໍ່ມີຂໍ້ມູນຂອງ 132200, ແລະສ່ວນທີ່ເຫຼືອຈະເປັນລະຫັດຄວາມຜິດພາດຂອງພວກເຮົາ (VDDK 1: ຄວາມຜິດພາດທີ່ບໍ່ຮູ້ຈັກ). ກ່ຽວກັບຄວາມຜິດພາດ VDDK ເລື້ອຍໆທີ່ສຸດ, ມີພຽງແຕ່ບໍ່ດົນມານີ້ແຍກຕ່າງຫາກ ບົດຄວາມ.

ບັດນີ້ໃຫ້ເຮົາເບິ່ງ ວິນໂດ.

ທີ່ນີ້, ທຸກສິ່ງທຸກຢ່າງທີ່ຈໍາເປັນແລະສໍາຄັນທີ່ສຸດສໍາລັບພວກເຮົາສາມາດໄດ້ຮັບການພົບເຫັນຢູ່ໃນມາດຕະຖານ Event Viewer. ແຕ່ມີການຈັບຫນຶ່ງ: ຕາມປະເພນີທີ່ຍາວນານ, Windows ບໍ່ໄດ້ບັນທຶກຂໍ້ຄວາມເຕັມຂອງຄວາມຜິດພາດ, ແຕ່ວ່າພຽງແຕ່ຕົວເລກຂອງມັນ. ຕົວຢ່າງ, ຂໍ້ຜິດພາດ 5 ແມ່ນ "ປະຕິເສດການເຂົ້າເຖິງ", ແລະ 1722 ແມ່ນ "ເຄື່ອງແມ່ຂ່າຍ RPC ບໍ່ສາມາດໃຊ້ໄດ້", ແລະ 10060 ແມ່ນ "ການເຊື່ອມຕໍ່ຫມົດເວລາ". ແນ່ນອນ, ມັນດີຫຼາຍຖ້າທ່ານຈື່ຈໍາສິ່ງທີ່ມີຊື່ສຽງທີ່ສຸດ, ແຕ່ສິ່ງທີ່ບໍ່ເຄີຍເຫັນມາກ່ອນ? 

ແລະເພື່ອໃຫ້ຊີວິດເບິ່ງຄືວ່າບໍ່ເປັນນໍ້າເຜິ້ງ, ຄວາມຜິດພາດຍັງຖືກເກັບໄວ້ໃນຮູບແບບເລກຖານສິບຫົກ, ດ້ວຍຄໍານໍາຫນ້າ 0x8007. ຕົວຢ່າງ, 0x8007000e ແມ່ນຕົວຈິງແລ້ວ 14, Out of Memory. ເປັນ​ຫຍັງ​ແລະ​ສໍາ​ລັບ​ໃຜ​ທີ່​ນີ້​ໄດ້​ເຮັດ​ໄດ້​ເປັນ​ຄວາມ​ລຶກ​ລັບ​ທີ່​ປົກ​ຫຸ້ມ​ຢູ່​ໃນ​ຄວາມ​ມືດ. ຢ່າງໃດກໍຕາມ, ບັນຊີລາຍຊື່ເຕັມຂອງຄວາມຜິດພາດສາມາດດາວໂຫຼດໄດ້ຟຣີແລະບໍ່ມີ SMS ຈາກ devcenter.

ໂດຍວິທີທາງການ, ບາງຄັ້ງມີຄໍານໍາຫນ້າອື່ນໆ, ບໍ່ພຽງແຕ່ 0x8007. ໃນສະຖານະການທີ່ໂສກເສົ້າດັ່ງກ່າວ, ເພື່ອເຂົ້າໃຈ HRESULT ("ການຈັດການຜົນໄດ້ຮັບ"), ທ່ານ ຈຳ ເປັນຕ້ອງເຂົ້າໃຈເລິກເຊິ່ງກວ່າ. ເອກະສານ ສໍາລັບນັກພັດທະນາ. ໃນຊີວິດ ທຳ ມະດາ, ຂ້ອຍບໍ່ແນະ ນຳ ເຈົ້າໃຫ້ເຮັດສິ່ງນີ້, ແຕ່ຖ້າທ່ານກົດດັນຢ່າງກະທັນຫັນກັບ ກຳ ແພງຫຼືພຽງແຕ່ຢາກຮູ້ຢາກເຫັນ, ດຽວນີ້ເຈົ້າຮູ້ສິ່ງທີ່ຕ້ອງເຮັດ.

ແຕ່ comrades ຢູ່ Microsoft ໄດ້ pity ພວກເຮົາພຽງເລັກນ້ອຍແລະສະແດງໃຫ້ເຫັນໂລກທີ່ເປັນປະໂຫຍດ ERR. ນີ້ແມ່ນສ່ວນນ້ອຍໆຂອງຄວາມສຸກຂອງ console ທີ່ສາມາດແປລະຫັດຂໍ້ຜິດພາດເຂົ້າໄປໃນມະນຸດໂດຍບໍ່ຕ້ອງໃຊ້ 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 ອອກຈາກມັນ, ຖອດລະຫັດພວກມັນແລະວາງມັນຄືນ. ໃຫ້ມີຄວາມຊື່ສັດ, ບໍ່ແມ່ນກິດຈະກໍາທີ່ຫນ້າຕື່ນເຕັ້ນທີ່ສຸດ.

Windows File Management API ໃຊ້ໃນທຸກວິທີທີ່ເປັນໄປໄດ້ໃນເວລາທີ່ເຮັດວຽກກັບໄຟລ໌. ການສ້າງໄຟລ໌, ລຶບ, ເປີດສໍາລັບການຂຽນ, ເຮັດວຽກກັບຄຸນລັກສະນະ, ແລະອື່ນໆແລະອື່ນໆ.

ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ PowerShell Direct ເປັນການປຽບທຽບຂອງ VIX API ໃນໂລກ Hyper-V. ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍ: ມີຂໍ້ຈໍາກັດຫຼາຍໃນການເຮັດວຽກ, ມັນບໍ່ເຮັດວຽກກັບທຸກສະບັບຂອງເຈົ້າພາບແລະບໍ່ແມ່ນກັບແຂກທັງຫມົດ.

CPR (ການໂທຂັ້ນຕອນໄລຍະໄກ) ຂ້ອຍບໍ່ຄິດວ່າມີຄົນດຽວທີ່ໄດ້ເຮັດວຽກກັບ WIndows ທີ່ບໍ່ເຫັນຂໍ້ຜິດພາດທີ່ກ່ຽວຂ້ອງກັບ RPC. ເຖິງວ່າຈະມີຄວາມເຂົ້າໃຈຜິດທີ່ເປັນທີ່ນິຍົມ, ນີ້ບໍ່ແມ່ນໂປໂຕຄອນດຽວ, ແຕ່ໂປໂຕຄອນລູກຄ້າ - ເຄື່ອງແມ່ຂ່າຍທີ່ພໍໃຈກັບຕົວກໍານົດການຈໍານວນຫນຶ່ງ. ຢ່າງໃດກໍຕາມ, ຖ້າມີຂໍ້ຜິດພາດ RPC ໃນບັນທຶກຂອງພວກເຮົາ, 90% ຂອງເວລາທີ່ມັນຈະເປັນຂໍ້ຜິດພາດຈາກ Microsoft RPC, ເຊິ່ງເປັນສ່ວນຫນຶ່ງຂອງ DCOM (Distributed Component Object Model). ທ່ານສາມາດຊອກຫາເອກະສານຈໍານວນຫຼວງຫຼາຍກ່ຽວກັບຫົວຂໍ້ນີ້ຢູ່ໃນສຸດທິ, ແຕ່ສ່ວນແບ່ງຂອງຊ້າງແມ່ນຂ້ອນຂ້າງລ້າສະໄຫມ. ແຕ່ຖ້າມີຄວາມປາຖະຫນາທີ່ຈະສຶກສາຫົວຂໍ້, ຂ້ອຍສາມາດແນະນໍາບົດຄວາມ RPC ແມ່ນຫຍັງ?, ວິທີການ RPC ເຮັດວຽກ ແລະບັນຊີລາຍຊື່ຍາວ RPC ຜິດພາດ.

ສາເຫດຕົ້ນຕໍຂອງຄວາມຜິດພາດ RPC ໃນບັນທຶກຂອງພວກເຮົາແມ່ນຄວາມລົ້ມເຫລວໃນຄວາມພະຍາຍາມໃນການສື່ສານລະຫວ່າງອົງປະກອບ VBR ​​(ເຄື່ອງແມ່ຂ່າຍ> proxy, ຕົວຢ່າງ) ແລະສ່ວນຫຼາຍແມ່ນຍ້ອນບັນຫາການສື່ສານ.

ດ້ານເທິງຂອງ tops ທັງຫມົດແມ່ນຄວາມຜິດພາດທີ່ເຄື່ອງແມ່ຂ່າຍ RPC ບໍ່ສາມາດໃຊ້ໄດ້ (1722). ໃນຄໍາສັບທີ່ງ່າຍດາຍ, ລູກຄ້າບໍ່ສາມາດສ້າງການເຊື່ອມຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍ. ວິທີການແລະເປັນຫຍັງ - ບໍ່ມີຄໍາຕອບດຽວ, ແຕ່ປົກກະຕິແລ້ວມັນເປັນບັນຫາກັບການກວດສອບຄວາມຖືກຕ້ອງຫຼືມີການເຂົ້າເຖິງເຄືອຂ່າຍກັບພອດ 135. ສຸດທ້າຍແມ່ນປົກກະຕິສໍາລັບໂຄງສ້າງພື້ນຖານທີ່ມີການມອບຫມາຍພອດແບບເຄື່ອນໄຫວ. ກ່ຽວກັບຫົວຂໍ້ນີ້, ມີເຖິງແມ່ນວ່າ HF ແຍກຕ່າງຫາກ. ແລະ Microsoft ມີ ຄູ່ມື voluminous ເພື່ອຊອກຫາສາເຫດຂອງຄວາມລົ້ມເຫຼວ.

ຄວາມຜິດພາດທີ່ສອງທີ່ນິຍົມຫຼາຍທີ່ສຸດ: ບໍ່ມີຈຸດສິ້ນສຸດເພີ່ມເຕີມຈາກແຜນທີ່ຈຸດສິ້ນສຸດ (1753). ລູກຄ້າ ຫຼືເຊີບເວີ RPC ລົ້ມເຫລວໃນການມອບໝາຍພອດໃຫ້ຕົນເອງ. ມັກຈະເກີດຂື້ນໃນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍ (ໃນກໍລະນີຂອງພວກເຮົາ, ເຄື່ອງແຂກ) ໄດ້ຖືກຕັ້ງຄ່າເພື່ອຈັດສັນພອດແບບເຄື່ອນໄຫວຈາກຂອບເຂດແຄບທີ່ສິ້ນສຸດລົງ. ແລະຖ້າທ່ານເຂົ້າສູ່ລະບົບຈາກຝ່າຍລູກຄ້າ (ໃນກໍລະນີຂອງພວກເຮົາ, ເຄື່ອງແມ່ຂ່າຍ VBR), ນີ້ຫມາຍຄວາມວ່າ VeeamVssAgent ຂອງພວກເຮົາບໍ່ໄດ້ເລີ່ມຕົ້ນຫຼືບໍ່ໄດ້ລົງທະບຽນເປັນການໂຕ້ຕອບ RPC. ຍັງມີຢູ່ໃນຫົວຂໍ້ນີ້ HF ແຍກຕ່າງຫາກ.

ດີ, ເພື່ອເຮັດສໍາເລັດ 3 ຂໍ້ຜິດພາດ RPC ເທິງ, ໃຫ້ຈື່ RPC function call failed (1726). ປະກົດວ່າການເຊື່ອມຕໍ່ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, ແຕ່ການຮ້ອງຂໍ RPC ບໍ່ໄດ້ຖືກປະມວນຜົນ. ຕົວຢ່າງ, ພວກເຮົາຮ້ອງຂໍຂໍ້ມູນກ່ຽວກັບສະຖານະພາບຂອງ VSS (ໃນທັນທີທັນໃດມີລະເບີດຝັງດິນເງົາຢູ່ທີ່ນັ້ນ, ແລະພວກເຮົາພະຍາຍາມປີນຂຶ້ນ), ແລະເພື່ອຕອບສະຫນອງພວກເຮົາ, ມິດງຽບແລະບໍ່ສົນໃຈ.

Windows Tape Backup API ຈໍາເປັນຕ້ອງເຮັດວຽກກັບຫ້ອງສະຫມຸດ tape ຫຼືໄດ. ດັ່ງທີ່ຂ້າພະເຈົ້າໄດ້ກ່າວມາໃນຕອນຕົ້ນ: ພວກເຮົາບໍ່ມີຄວາມຍິນດີໃນການຂຽນຕົວຂັບຂີ່ຂອງພວກເຮົາເອງແລະຫຼັງຈາກນັ້ນທຸກທໍລະມານກັບການສະຫນັບສະຫນູນຂອງແຕ່ລະອຸປະກອນ. ເພາະສະນັ້ນ, vim ບໍ່ມີໄດເວີຂອງຕົນເອງ. ທັງຫມົດໂດຍຜ່ານ API ມາດຕະຖານ, ການສະຫນັບສະຫນູນທີ່ຖືກປະຕິບັດໂດຍຜູ້ຂາຍຮາດແວເອງ. ມີເຫດຜົນຫຼາຍ, ບໍ່ແມ່ນບໍ?

SMB / CIFS ອອກຈາກນິໄສ, ທຸກຄົນຂຽນໃຫ້ເຂົາເຈົ້າຂ້າງຄຽງ, ເຖິງແມ່ນວ່າບໍ່ແມ່ນທຸກຄົນຈື່ວ່າ CIFS (ລະບົບໄຟລ໌ອິນເຕີເນັດທົ່ວໄປ) ແມ່ນພຽງແຕ່ສະບັບສ່ວນຕົວຂອງ SMB (Server Message Block). ດັ່ງນັ້ນບໍ່ມີຫຍັງຜິດປົກກະກັບການໂດຍທົ່ວໄປແນວຄວາມຄິດເຫຼົ່ານີ້. Samba ແມ່ນແລ້ວການຈັດຕັ້ງປະຕິບັດ LinuxUnix, ແລະມັນມີຄຸນລັກສະນະຂອງຕົນເອງ, ແຕ່ຂ້ອຍປະຕິເສດ. ສິ່ງທີ່ສໍາຄັນຢູ່ທີ່ນີ້: ເມື່ອ Veeam ຂໍໃຫ້ຂຽນບາງສິ່ງບາງຢ່າງໄປຫາເສັ້ນທາງ UNC (serverdirectory), ເຄື່ອງແມ່ຂ່າຍໃຊ້ລໍາດັບຊັ້ນຂອງໄດເວີລະບົບໄຟລ໌, ລວມທັງ mup ແລະ mrxsmb, ເພື່ອຂຽນໃສ່ບານ. ດັ່ງນັ້ນ, ຄົນຂັບເຫຼົ່ານີ້ຍັງຈະສ້າງຄວາມຜິດພາດ.

ບໍ່ສາມາດເຮັດໄດ້ໂດຍບໍ່ມີການ Winsock API. ຖ້າບາງສິ່ງບາງຢ່າງຕ້ອງເຮັດຜ່ານເຄືອຂ່າຍ, VBR ເຮັດວຽກຜ່ານ Windows Socket API, ເຊິ່ງເອີ້ນກັນວ່າ Winsock. ດັ່ງນັ້ນຖ້າພວກເຮົາເຫັນ IP:Port ໃນບັນທຶກ, ນີ້ແມ່ນມັນ. ເອກະສານທີ່ເປັນທາງການມີບັນຊີລາຍຊື່ທີ່ດີທີ່ເປັນໄປໄດ້ ຄວາມຜິດພາດ.

ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ WMI (Windows Management Instrumentation) ເປັນ​ປະ​ເພດ​ຂອງ API ທີ່​ມີ​ອໍາ​ນາດ​ສໍາ​ລັບ​ການ​ຄຸ້ມ​ຄອງ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ແລະ​ທຸກ​ຄົນ​ໃນ​ໂລກ Windows​. ຕົວຢ່າງ, ເມື່ອເຮັດວຽກກັບ Hyper-V, ເກືອບທຸກຄໍາຮ້ອງຂໍກັບເຈົ້າພາບຜ່ານມັນ. ໃນຄໍາສັບໃດຫນຶ່ງ, ສິ່ງດັ່ງກ່າວແມ່ນບໍ່ສາມາດທົດແທນໄດ້ຢ່າງແທ້ຈິງແລະມີອໍານາດຫຼາຍໃນຄວາມສາມາດຂອງມັນ. ໃນຄວາມພະຍາຍາມທີ່ຈະຊ່ວຍຊອກຫາບ່ອນໃດແລະສິ່ງທີ່ແຕກຫັກ, ເຄື່ອງມື WBEMtest.exe ທີ່ມີຢູ່ໃນຕົວຊ່ວຍຫຼາຍ.

ແລະສຸດທ້າຍໃນບັນຊີລາຍຊື່, ແຕ່ໂດຍບໍ່ໄດ້ຫມາຍຄວາມວ່າຢ່າງຫນ້ອຍໃນຄວາມສໍາຄັນ - VSS (ປະລິມານການເກັບຮັກສາເງົາ). ຫົວຂໍ້ແມ່ນ inexhaustible ແລະ mysterious ເປັນເອກະສານຫຼາຍໄດ້ຖືກຂຽນກ່ຽວກັບມັນ. Shadow Copy ແມ່ນເຂົ້າໃຈງ່າຍທີ່ສຸດເປັນປະເພດພິເສດຂອງ snapshot, ເຊິ່ງໂດຍເນື້ອແທ້ແລ້ວມັນແມ່ນ. ຂໍຂອບໃຈກັບລາວ, ທ່ານສາມາດເຮັດການສໍາຮອງຂໍ້ມູນທີ່ສອດຄ່ອງຂອງແອັບພລິເຄຊັນໃນ VMware, ແລະເກືອບທຸກຢ່າງໃນ Hyper-V. ຂ້ອຍມີແຜນທີ່ຈະສ້າງບົດຄວາມແຍກຕ່າງຫາກດ້ວຍການບີບບາງກ່ຽວກັບ VSS, ແຕ່ສໍາລັບຕອນນີ້ທ່ານສາມາດລອງອ່ານໄດ້ ລາຍ​ລະ​ອຽດ​ນີ້​. ພຽງແຕ່ຈະລະມັດລະວັງ, ເພາະວ່າ. ການພະຍາຍາມເຂົ້າໃຈ VSS ໃນແຟດສາມາດນໍາໄປສູ່ການບາດເຈັບຂອງສະຫມອງ.

ກ່ຽວກັບເລື່ອງນີ້, ບາງທີ, ພວກເຮົາສາມາດຢຸດເຊົາ. ຂ້າ​ພະ​ເຈົ້າ​ພິ​ຈາ​ລະ​ນາ​ວຽກ​ງານ​ຂອງ​ການ​ອະ​ທິ​ບາຍ​ສິ່ງ​ພື້ນ​ຖານ​ທີ່​ສຸດ​ສໍາ​ເລັດ, ດັ່ງ​ນັ້ນ​ໃນ​ບົດ​ຕໍ່​ໄປ​ພວກ​ເຮົາ​ແລ້ວ​ຈະ​ເບິ່ງ​ບັນ​ທຶກ. ແຕ່ຖ້າທ່ານມີຄໍາຖາມໃດໆ, ກະລຸນາຖາມພວກເຂົາໃນຄໍາເຫັນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com