บันทึกมาจากไหน วีม ล็อก ไดวิ่ง

เราดำดิ่งสู่โลกแห่งการคาดเดาที่น่าหลงใหล ... การแก้ปัญหาด้วยบันทึก ใน บทความก่อนหน้านี้ เราตกลงเกี่ยวกับความหมายของคำศัพท์พื้นฐานและดูโครงสร้างโดยรวมของ Veeam เป็นแอปพลิเคชั่นเดียวด้วยตาข้างเดียว งานของสิ่งนี้คือการค้นหาว่าไฟล์บันทึกถูกสร้างขึ้นอย่างไร ข้อมูลประเภทใดที่แสดงในไฟล์เหล่านั้น และเหตุใดไฟล์จึงมีลักษณะเช่นนี้

คุณคิดว่า "บันทึก" เหล่านี้คืออะไร? ตามข้อมูลส่วนใหญ่ บันทึกของแอปพลิเคชันใด ๆ ควรถูกกำหนดให้มีบทบาทเป็นสิ่งมีชีวิตที่มีอำนาจทุกอย่าง ซึ่งส่วนใหญ่มักจะเติบโตที่ไหนสักแห่งในสวนหลังบ้าน แต่ในเวลาที่เหมาะสมก็ปรากฏตัวขึ้นในชุดเกราะส่องแสงและช่วยชีวิตทุกคน นั่นคือควรมีทุกอย่างตั้งแต่ข้อผิดพลาดเพียงเล็กน้อยในแต่ละส่วนประกอบไปจนถึงธุรกรรมฐานข้อมูลแต่ละรายการ และหลังจากเกิดข้อผิดพลาดก็มีการเขียนทันทีว่าจะแก้ไขอย่างไร และทั้งหมดนี้ควรพอดีกับสองสามเมกะไบต์ไม่มากไปกว่านี้ มันเป็นเพียงข้อความ! ไฟล์ข้อความไม่สามารถกินได้หลายสิบกิกะไบต์ ฉันเคยได้ยินที่ไหนสักแห่ง!

ดังนั้นบันทึก

ในโลกแห่งความเป็นจริง บันทึกเป็นเพียงข้อมูลที่เก็บถาวรเพื่อการวินิจฉัยเท่านั้น และจะเก็บอะไรไว้ที่นั่น จะรับข้อมูลสำหรับการจัดเก็บได้จากที่ใด และควรมีรายละเอียดมากน้อยเพียงใดนั้นขึ้นอยู่กับการตัดสินใจของนักพัฒนาเอง บางคนเดินตามเส้นทางของความเรียบง่ายโดยเก็บบันทึกระดับเปิด / ปิด และบางคนขยันหมั่นเพียรเสาะหาทุกสิ่งที่พวกเขาสามารถเข้าถึงได้ แม้ว่าจะมีตัวเลือกระดับกลางที่สามารถเลือกระดับการบันทึกที่เรียกว่าเมื่อคุณระบุรายละเอียดที่คุณต้องการจัดเก็บและพื้นที่ว่างในดิสก์เพิ่มเติม =) VBR มีหกระดับดังกล่าว และเชื่อฉันเถอะว่าคุณไม่ต้องการเห็นสิ่งที่เกิดขึ้นกับการบันทึกที่ละเอียดที่สุดพร้อมพื้นที่ว่างบนดิสก์ของคุณ

ดี. เราเข้าใจอย่างคร่าว ๆ ว่าเราต้องการบันทึกอะไร แต่มีคำถามที่ถูกต้องเกิดขึ้น: จะรับข้อมูลนี้จากที่ใด แน่นอน เราเป็นส่วนหนึ่งของกิจกรรมเพื่อเข้าสู่ตัวเองโดยกระบวนการภายในของเรา แต่จะทำอย่างไรเมื่อมีปฏิสัมพันธ์กับสิ่งแวดล้อมภายนอก? เพื่อไม่ให้ลื่นไถลไปกับไม้ค้ำและจักรยาน Veeam มีแนวโน้มที่จะไม่ประดิษฐ์สิ่งประดิษฐ์ที่ได้รับการประดิษฐ์ขึ้นแล้ว เมื่อใดก็ตามที่มี API สำเร็จรูป ฟังก์ชันในตัว ไลบรารี ฯลฯ เราจะให้ความสำคัญกับตัวเลือกสำเร็จรูปก่อนที่จะเริ่มปิดกั้นอุปกรณ์ของเรา แม้ว่าอย่างหลังก็เพียงพอแล้ว ดังนั้น เมื่อวิเคราะห์บันทึก สิ่งสำคัญคือต้องเข้าใจว่าข้อผิดพลาดส่วนใหญ่ตกอยู่กับข้อความจาก API ของบุคคลที่สาม การเรียกระบบ และไลบรารีอื่นๆ ในกรณีนี้ บทบาทของ VBR คือการส่งต่อข้อผิดพลาดเหล่านี้ไปยังไฟล์บันทึกตามที่เป็น และงานหลักของผู้ใช้คือการเรียนรู้เพื่อทำความเข้าใจว่าบรรทัดใดมาจากใครและ "ใคร" นี้มีหน้าที่รับผิดชอบอะไร ดังนั้น หากรหัสข้อผิดพลาดจากบันทึก VBR นำคุณไปยังหน้า MSDN ก็ไม่เป็นไรและถูกต้อง

ตามที่เราตกลงกันไว้ก่อนหน้านี้: Veeam เป็นแอปพลิเคชันที่ใช้ SQL ที่เรียกว่า ซึ่งหมายความว่าการตั้งค่าทั้งหมด ข้อมูลทั้งหมด และโดยทั่วไปทุกอย่างที่จำเป็นสำหรับการทำงานปกติเท่านั้น ทุกอย่างจะถูกจัดเก็บไว้ในฐานข้อมูล ดังนั้นความจริงง่ายๆ: สิ่งที่ไม่ได้อยู่ในบันทึกมักจะอยู่ในฐานข้อมูล แต่นี่ไม่ใช่สัญลักษณ์แสดงหัวข้อย่อย: บางสิ่งไม่ได้อยู่ในบันทึกในเครื่องของส่วนประกอบ Veeam หรือในฐานข้อมูล ดังนั้นคุณต้องเรียนรู้วิธีศึกษาบันทึกโฮสต์ บันทึกของเครื่องโลคัล และบันทึกของทุกสิ่งที่เกี่ยวข้องกับกระบวนการสำรองและกู้คืน และมันก็เกิดขึ้นว่าไม่มีข้อมูลที่จำเป็นในทุกที่ นั่นคือวิธีการ 

ตัวอย่างบางส่วนของ API ดังกล่าว

รายการนี้ไม่ได้มุ่งหมายให้สมบูรณ์เป็นพิเศษ ดังนั้นจึงไม่จำเป็นต้องมองหาความจริงสูงสุดในนั้น จุดประสงค์คือเพื่อแสดง API และเทคโนโลยีของบุคคลที่สามทั่วไปที่ใช้ในผลิตภัณฑ์ของเราเท่านั้น

เริ่มกันเลย VMware. 

อันดับแรกในรายการจะเป็น วีสเฟียร์ API. ใช้สำหรับการพิสูจน์ตัวตน อ่านลำดับชั้น สร้างและลบสแน็ปช็อต ขอข้อมูลเกี่ยวกับเครื่อง และอื่นๆ อีกมาก (มาก) ฟังก์ชันการทำงานของโซลูชันนั้นกว้างมาก ดังนั้นฉันจึงสามารถแนะนำการอ้างอิง API ของ VMware vSphere สำหรับเวอร์ชันนี้ได้ 5.5 и 6.0. สำหรับเวอร์ชันล่าสุด ทุกอย่างเป็นเพียง googled

VIX API. มนต์ดำของไฮเปอร์ไวเซอร์ซึ่งมีแยกต่างหาก รายการข้อผิดพลาด. VMware API สำหรับการทำงานกับไฟล์บนโฮสต์โดยไม่ต้องเชื่อมต่อกับไฟล์ผ่านเครือข่าย ตัวเลือกสุดท้ายเมื่อคุณต้องการใส่ไฟล์ลงในเครื่องที่ไม่มีช่องทางการสื่อสารที่ดีกว่า ความเจ็บปวดและความทุกข์ทรมานหากไฟล์มีขนาดใหญ่และมีการโหลดโฮสต์ แต่ที่นี่กฎใช้งานได้ว่าแม้แต่ 56,6 Kb / s ก็ยังดีกว่า 0 Kb / s ใน Hyper-V สิ่งนี้เรียกว่า PowerShell Direct แต่นั่นเป็นเพียงก่อนหน้านี้

vSphere Web Services API เริ่มจาก vSphere 6.0 (โดยประมาณ เนื่องจาก API นี้เปิดตัวครั้งแรกในเวอร์ชัน 5.5) มันถูกใช้เพื่อทำงานกับเครื่องแขก และแทนที่ VIX เกือบทุกที่ อันที่จริง นี่เป็นอีก API สำหรับจัดการ vSphere สำหรับคนที่สนใจแนะนำให้ศึกษาครับ отличный คู่มือ. 

วี.ดี.ดี.เค (ชุดพัฒนาดิสก์เสมือน). ห้องสมุดซึ่งได้กล่าวถึงบางส่วนในครั้งนี้ статье. ใช้เพื่ออ่านดิสก์เสมือน กาลครั้งหนึ่งมันเป็นส่วนหนึ่งของ VIX แต่เมื่อเวลาผ่านไปมันก็ถูกย้ายไปยังผลิตภัณฑ์อื่น แต่ในฐานะทายาท จะใช้รหัสข้อผิดพลาดเดียวกันกับ VIX แต่ด้วยเหตุผลบางอย่าง ไม่มีคำอธิบายข้อผิดพลาดเหล่านี้ใน SDK เอง ดังนั้นจึงพบว่าข้อผิดพลาด VDDK กับรหัสอื่นเป็นเพียงการแปลจากรหัสไบนารีเป็นรหัสทศนิยม ประกอบด้วยสองส่วน - ครึ่งแรกเป็นข้อมูลที่ไม่มีเอกสารเกี่ยวกับบริบท และส่วนที่สองคือข้อผิดพลาด VIX / VDDK แบบดั้งเดิม ตัวอย่างเช่น ถ้าเราเห็น:

VDDK error: 21036749815809.Unknown error

จากนั้นเราแปลงเป็นเลขฐานสิบหกอย่างกล้าหาญและรับ 132200000001 เราเพียงแค่ละทิ้งจุดเริ่มต้นที่ไม่เป็นข้อมูลของ 132200 และส่วนที่เหลือจะเป็นรหัสข้อผิดพลาดของเรา (VDDK 1: ข้อผิดพลาดที่ไม่รู้จัก) เกี่ยวกับข้อผิดพลาด VDDK ที่พบบ่อยที่สุดเพิ่งแยกออกมา บทความ.

ทีนี้มาดูที่ หน้าต่างWI.

ที่นี่ทุกสิ่งที่จำเป็นและสำคัญที่สุดสำหรับเราสามารถพบได้ในมาตรฐาน แสดงเหตุการณ์. แต่มีสิ่งหนึ่งที่จับได้: ตามประเพณีอันยาวนาน Windows จะไม่บันทึกข้อความทั้งหมดของข้อผิดพลาด แต่บันทึกเฉพาะหมายเลขเท่านั้น ตัวอย่างเช่น ข้อผิดพลาด 5 คือ "การเข้าถึงถูกปฏิเสธ" และ 1722 คือ "เซิร์ฟเวอร์ RPC ไม่พร้อมใช้งาน" และ 10060 คือ "การเชื่อมต่อหมดเวลา" แน่นอนว่าเป็นเรื่องดีถ้าคุณจำคนดังๆ ได้ แต่คนที่ยังไม่เคยเห็นมาก่อนล่ะ? 

และเพื่อไม่ให้ชีวิตดูเหมือนน้ำผึ้งเลย ข้อผิดพลาดจะถูกจัดเก็บในรูปแบบเลขฐานสิบหกด้วยคำนำหน้า 0x8007 ตัวอย่างเช่น 0x8007000e คือ 14, หน่วยความจำไม่เพียงพอ ทำไมและใครทำสิ่งนี้เป็นความลึกลับที่ปกคลุมไปด้วยความมืด อย่างไรก็ตามรายการข้อผิดพลาดทั้งหมดสามารถดาวน์โหลดได้ฟรีและไม่ต้องส่ง SMS จาก ศูนย์พัฒนา.

อย่างไรก็ตาม บางครั้งก็มีคำนำหน้าอื่นๆ ไม่ใช่แค่ 0x8007 ในสถานการณ์ที่น่าเศร้าเช่นนี้ เพื่อที่จะเข้าใจ HRESULT (“การจัดการผลลัพธ์”) คุณต้องเจาะลึกลงไปอีก เอกสาร สำหรับนักพัฒนา ในชีวิตปกติ ฉันไม่แนะนำให้คุณทำสิ่งนี้ แต่ถ้าคุณดันติดกำแพงหรือแค่อยากรู้อยากเห็น ตอนนี้คุณรู้แล้วว่าต้องทำอะไร

แต่เพื่อนร่วมงานของ Microsoft รู้สึกสงสารเราเล็กน้อยและแสดงให้โลกเห็นถึงประโยชน์ ERR. นี่คือความสุขเล็กๆ น้อยๆ ของคอนโซลที่สามารถแปลรหัสข้อผิดพลาดให้เป็นภาษามนุษย์ได้โดยไม่ต้องใช้ 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 การจัดการไฟล์ Windows ใช้ในทุกวิถีทางเมื่อทำงานกับไฟล์ การสร้างไฟล์ การลบ การเปิดเพื่อเขียน การทำงานกับแอตทริบิวต์ และอื่นๆ เป็นต้น

ดังกล่าวข้างต้น PowerShell โดยตรง เป็นอะนาล็อกของ VIX API ในโลกของ Hyper-V น่าเสียดายที่ไม่ยืดหยุ่นนัก: มีข้อจำกัดมากมายเกี่ยวกับฟังก์ชันการทำงาน ใช้งานไม่ได้กับโฮสต์ทุกเวอร์ชันและไม่ใช่กับแขกทุกคน

RPC (การเรียกขั้นตอนระยะไกล) ฉันไม่คิดว่าจะมีคนเดียวที่ทำงานกับ WIndows ที่ไม่เห็นข้อผิดพลาดเกี่ยวกับ RPC แม้จะมีความเข้าใจผิดที่เป็นที่นิยม แต่นี่ไม่ใช่โปรโตคอลเดียว แต่เป็นโปรโตคอลไคลเอนต์เซิร์ฟเวอร์ที่ตรงตามพารามิเตอร์จำนวนหนึ่ง อย่างไรก็ตาม หากมีข้อผิดพลาด RPC ในบันทึกของเรา 90% ของเวลาทั้งหมดจะเป็นข้อผิดพลาดจาก Microsoft RPC ซึ่งเป็นส่วนหนึ่งของ DCOM (Distributed Component Object Model) คุณสามารถหาเอกสารจำนวนมากเกี่ยวกับหัวข้อนี้ได้ทางเน็ต แต่ส่วนใหญ่ของเอกสารนี้ค่อนข้างล้าสมัย แต่ถ้ามีความปรารถนาอย่างแรงกล้าที่จะศึกษาหัวข้อนี้ ฉันก็สามารถแนะนำบทความได้ RPC คืออะไร?, สรุป ความน่าเชื่อถือของ Olymp Trade? งาน RPC และรายการยาว ข้อผิดพลาด RPC.

สาเหตุหลักของข้อผิดพลาด RPC ในบันทึกของเราคือความพยายามในการสื่อสารระหว่างคอมโพเนนต์ VBR ล้มเหลว (เช่น เซิร์ฟเวอร์ > พร็อกซี) และส่วนใหญ่มักเกิดจากปัญหาในการสื่อสาร

ด้านบนสุดคือข้อผิดพลาดเซิร์ฟเวอร์ RPC ไม่พร้อมใช้งาน (1722) พูดง่ายๆ ก็คือ ไคลเอนต์ไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ได้ อย่างไรและทำไม - ไม่มีคำตอบเดียว แต่โดยปกติแล้วจะเป็นปัญหากับการรับรองความถูกต้องหรือการเข้าถึงเครือข่ายไปยังพอร์ต 135 ซึ่งเป็นเรื่องปกติสำหรับโครงสร้างพื้นฐานที่มีการกำหนดพอร์ตแบบไดนามิก ในหัวข้อนี้มีแม้กระทั่ง แยก HF. และไมโครซอฟต์มี คู่มือมากมาย เพื่อหาสาเหตุของความล้มเหลว

ข้อผิดพลาดยอดนิยมอันดับสอง: ไม่มีจุดสิ้นสุดที่พร้อมใช้งานจาก endpoint mapper (1753) ไคลเอนต์หรือเซิร์ฟเวอร์ RPC ไม่สามารถกำหนดพอร์ตให้ตัวเองได้ มักจะเกิดขึ้นเมื่อเซิร์ฟเวอร์ (ในกรณีของเราคือเครื่องเกสต์) ได้รับการกำหนดค่าให้จัดสรรพอร์ตแบบไดนามิกจากช่วงแคบที่สิ้นสุด และถ้าคุณเข้าสู่ระบบจากฝั่งไคลเอ็นต์ (ในกรณีของเราคือเซิร์ฟเวอร์ VBR) หมายความว่า VeeamVssAgent ของเราไม่ได้เริ่มทำงานหรือไม่ได้ลงทะเบียนเป็นอินเทอร์เฟซ RPC นอกจากนี้ยังมีในหัวข้อนี้ แยก HF.

เพื่อให้ข้อผิดพลาด RPC 3 อันดับแรกเสร็จสมบูรณ์ โปรดจำไว้ว่าการเรียกใช้ฟังก์ชัน RPC ล้มเหลว (1726) ปรากฏขึ้นหากสร้างการเชื่อมต่อแล้ว แต่คำขอ RPC ไม่ได้รับการประมวลผล ตัวอย่างเช่น เราขอข้อมูลเกี่ยวกับสถานะของ VSS (ทันใดนั้นก็มีการทำเหมืองเงาที่นั่น และเรากำลังพยายามปีนขึ้นไป) และตอบกลับเราโดยเงียบและเพิกเฉย

API การสำรองข้อมูลเทปของ Windows จำเป็นในการทำงานกับไลบรารีเทปหรือไดรฟ์ อย่างที่ฉันได้กล่าวไปในตอนต้น: เราไม่มีความสุขในการเขียนไดรเวอร์ของเราเองและต้องทนทุกข์กับการรองรับของอุปกรณ์แต่ละเครื่อง ดังนั้น vim จึงไม่มีไดรเวอร์เป็นของตัวเอง ทั้งหมดผ่าน API มาตรฐาน การสนับสนุนดำเนินการโดยผู้จำหน่ายฮาร์ดแวร์เอง มีเหตุผลมากกว่านี้ใช่ไหม

SMB / CIFS ตามความเคยชิน ทุกคนเขียนคู่กัน แม้ว่าทุกคนจะจำไม่ได้ว่า CIFS (Common Internet File System) เป็นเพียงเวอร์ชันส่วนตัวของ SMB (Server Message Block) ดังนั้นจึงไม่มีอะไรผิดที่จะสรุปแนวคิดเหล่านี้ Samba ใช้งาน LinuxUnix อยู่แล้วและมีลักษณะเฉพาะของตัวเอง แต่ฉันพูดนอกเรื่อง สิ่งที่สำคัญที่นี่: เมื่อ Veeam ขอให้เขียนบางสิ่งไปยังเส้นทาง UNC (ไดเร็กทอรีเซิร์ฟเวอร์) เซิร์ฟเวอร์จะใช้ลำดับชั้นของไดรเวอร์ระบบไฟล์ รวมถึง mup และ mrxsmb เพื่อเขียนไปยัง ball ดังนั้นไดรเวอร์เหล่านี้จะสร้างข้อผิดพลาดด้วย

ไม่สามารถทำได้ Winsock API. หากจำเป็นต้องทำบางอย่างผ่านเครือข่าย VBR จะทำงานผ่าน Windows Socket API หรือที่รู้จักกันในชื่อ Winsock ดังนั้นหากเราเห็น IP:Port จำนวนมากในบันทึก นี่คือสิ่งนี้ เอกสารอย่างเป็นทางการมีรายการที่เป็นไปได้ ข้อผิดพลาด.

ดังกล่าวข้างต้น WMI (Windows Management Instrumentation) เป็น API ที่ยอดเยี่ยมสำหรับจัดการทุกอย่างและทุกคนในโลกของ Windows ตัวอย่างเช่น เมื่อทำงานกับ Hyper-V คำขอเกือบทั้งหมดที่ส่งไปยังโฮสต์จะผ่านมันไป กล่าวอีกนัยหนึ่งสิ่งนี้ไม่สามารถถูกแทนที่ได้อย่างแน่นอนและมีประสิทธิภาพมากในความสามารถของมัน เครื่องมือ WBEMtest.exe ในตัวจะช่วยได้มากเพื่อช่วยค้นหาตำแหน่งและอะไรเสีย

และสุดท้ายในรายการ แต่ก็ไม่ได้มีความสำคัญน้อยที่สุด - VSS (พื้นที่เก็บข้อมูลเงาระดับเสียง) หัวข้อนี้ไม่รู้จักหมดสิ้นและลึกลับเนื่องจากมีการเขียนเอกสารมากมาย Shadow Copy เข้าใจได้ง่ายที่สุดว่าเป็นสแน็ปช็อตประเภทพิเศษ ซึ่งโดยพื้นฐานแล้วมันก็คือ ต้องขอบคุณเขา คุณสามารถทำการสำรองข้อมูลที่สอดคล้องกับแอปพลิเคชันใน VMware และเกือบทุกอย่างใน Hyper-V ฉันมีแผนที่จะสร้างบทความแยกต่างหากโดยมีการบีบ VSS บางส่วน แต่ตอนนี้คุณสามารถลองอ่านได้ คำอธิบายนี้. แค่ระวังเพราะ การพยายามทำความเข้าใจ VSS ในพริบตาอาจทำให้สมองบาดเจ็บได้

ในเรื่องนี้บางทีเราสามารถหยุดได้ ฉันพิจารณางานของการอธิบายสิ่งพื้นฐานที่สุดให้เสร็จสิ้น ดังนั้นในบทต่อไปเราจะดูที่บันทึกแล้ว แต่ถ้าคุณมีคำถามใด ๆ โปรดถามพวกเขาในความคิดเห็น

ที่มา: will.com