ದಾಖಲೆಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ? ವೀಮ್ ಲಾಗ್ ಡೈವಿಂಗ್

ಲಾಗ್‌ಗಳ ಮೂಲಕ ಊಹೆಯ ... ದೋಷನಿವಾರಣೆಯ ಆಕರ್ಷಕ ಜಗತ್ತಿನಲ್ಲಿ ನಮ್ಮ ಮುಳುಗುವಿಕೆಯನ್ನು ನಾವು ಮುಂದುವರಿಸುತ್ತೇವೆ. IN ಹಿಂದಿನ ಲೇಖನ ನಾವು ಮೂಲ ಪದಗಳ ಅರ್ಥವನ್ನು ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ವೀಮ್‌ನ ಒಟ್ಟಾರೆ ರಚನೆಯನ್ನು ಒಂದೇ ಕಣ್ಣಿನಲ್ಲಿ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನಂತೆ ನೋಡಿದ್ದೇವೆ. ಲಾಗ್ ಫೈಲ್‌ಗಳು ಹೇಗೆ ರಚನೆಯಾಗುತ್ತವೆ, ಅವುಗಳಲ್ಲಿ ಯಾವ ರೀತಿಯ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅವು ಏಕೆ ಕಾಣುತ್ತವೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಇದರ ಕಾರ್ಯವಾಗಿದೆ.

ಈ "ಲಾಗ್‌ಗಳು" ಏನು ಎಂದು ನೀವು ಯೋಚಿಸುತ್ತೀರಿ? ಹೆಚ್ಚಿನವರ ಪ್ರಕಾರ, ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಲಾಗ್‌ಗಳಿಗೆ ಒಂದು ರೀತಿಯ ಸರ್ವಶಕ್ತ ಘಟಕದ ಪಾತ್ರವನ್ನು ನಿಗದಿಪಡಿಸಬೇಕು, ಅದು ಹೆಚ್ಚಿನ ಸಮಯ ಹಿತ್ತಲಿನಲ್ಲಿ ಎಲ್ಲೋ ಸಸ್ಯಗಳಾಗಿರುತ್ತವೆ, ಆದರೆ ಸರಿಯಾದ ಕ್ಷಣದಲ್ಲಿ ರಕ್ಷಾಕವಚವನ್ನು ಹೊಳೆಯುವಲ್ಲಿ ಎಲ್ಲಿಂದಲಾದರೂ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಎಲ್ಲರನ್ನೂ ಉಳಿಸುತ್ತದೆ. ಅಂದರೆ, ಪ್ರತಿ ಘಟಕದಲ್ಲಿನ ಸಣ್ಣದೊಂದು ದೋಷಗಳಿಂದ ಹಿಡಿದು ವೈಯಕ್ತಿಕ ಡೇಟಾಬೇಸ್ ವಹಿವಾಟುಗಳವರೆಗೆ ಎಲ್ಲವನ್ನೂ ಅವು ಒಳಗೊಂಡಿರಬೇಕು. ಮತ್ತು ಆದ್ದರಿಂದ ದೋಷದ ನಂತರ ಅದನ್ನು ಬೇರೆ ಹೇಗೆ ಸರಿಪಡಿಸಬೇಕು ಎಂದು ತಕ್ಷಣ ಬರೆಯಲಾಗಿದೆ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಒಂದೆರಡು ಮೆಗಾಬೈಟ್‌ಗಳಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳಬೇಕು, ಇನ್ನು ಮುಂದೆ ಇಲ್ಲ. ಇದು ಕೇವಲ ಪಠ್ಯವಾಗಿದೆ! ಪಠ್ಯ ಫೈಲ್‌ಗಳು ಹತ್ತಾರು ಗಿಗಾಬೈಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ನಾನು ಅದನ್ನು ಎಲ್ಲೋ ಕೇಳಿದೆ!

ಆದ್ದರಿಂದ ದಾಖಲೆಗಳು

ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ, ಲಾಗ್‌ಗಳು ಕೇವಲ ರೋಗನಿರ್ಣಯದ ಮಾಹಿತಿಯ ಆರ್ಕೈವ್ ಆಗಿದೆ. ಮತ್ತು ಅಲ್ಲಿ ಏನು ಸಂಗ್ರಹಿಸಬೇಕು, ಶೇಖರಣೆಗಾಗಿ ಮಾಹಿತಿಯನ್ನು ಎಲ್ಲಿ ಪಡೆಯಬೇಕು ಮತ್ತು ಅದು ಎಷ್ಟು ವಿವರವಾಗಿರಬೇಕು, ಡೆವಲಪರ್‌ಗಳು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಆನ್ / ಆಫ್ ಮಟ್ಟದ ದಾಖಲೆಗಳನ್ನು ಇಟ್ಟುಕೊಂಡು ಯಾರಾದರೂ ಕನಿಷ್ಠೀಯತಾವಾದದ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುತ್ತಾರೆ ಮತ್ತು ಯಾರಾದರೂ ಅವರು ತಲುಪಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಶ್ರದ್ಧೆಯಿಂದ ಕಸಿದುಕೊಳ್ಳುತ್ತಾರೆ. ಲಾಗಿಂಗ್ ಲೆವೆಲ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಮಧ್ಯಂತರ ಆಯ್ಕೆಯೂ ಸಹ ಇದ್ದರೂ, ನೀವು ಎಷ್ಟು ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಎಷ್ಟು ಹೆಚ್ಚುವರಿ ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ನೀವೇ ಸೂಚಿಸಿದಾಗ =) VBR ಅಂತಹ ಆರು ಹಂತಗಳನ್ನು ಹೊಂದಿದೆ. ಮತ್ತು, ನನ್ನನ್ನು ನಂಬಿರಿ, ನಿಮ್ಮ ಡಿಸ್ಕ್ನಲ್ಲಿ ಮುಕ್ತ ಸ್ಥಳದೊಂದಿಗೆ ಹೆಚ್ಚು ವಿವರವಾದ ಲಾಗಿಂಗ್ನೊಂದಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ.

ಫೈನ್. ನಾವು ಏನನ್ನು ಉಳಿಸಬೇಕೆಂದು ನಾವು ಸ್ಥೂಲವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ಕಾನೂನುಬದ್ಧ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಈ ಮಾಹಿತಿಯನ್ನು ಎಲ್ಲಿಂದ ಪಡೆಯಬೇಕು? ಸಹಜವಾಗಿ, ನಮ್ಮ ಆಂತರಿಕ ಪ್ರಕ್ರಿಯೆಗಳಿಂದ ನಾವೇ ಲಾಗಿಂಗ್ ಮಾಡಲು ನಾವು ಈವೆಂಟ್‌ಗಳ ಭಾಗವನ್ನು ರೂಪಿಸುತ್ತೇವೆ. ಆದರೆ ಬಾಹ್ಯ ಪರಿಸರದೊಂದಿಗೆ ಸಂವಹನ ಇದ್ದಾಗ ಏನು ಮಾಡಬೇಕು? ಊರುಗೋಲುಗಳು ಮತ್ತು ಬೈಸಿಕಲ್‌ಗಳ ಪಿಚ್ ಹೆಲ್‌ಗೆ ಜಾರದಿರಲು, ವೀಮ್ ಈಗಾಗಲೇ ಕಂಡುಹಿಡಿದ ಆವಿಷ್ಕಾರಗಳನ್ನು ಆವಿಷ್ಕರಿಸುವುದಿಲ್ಲ. ಸಿದ್ಧ-ತಯಾರಿಸಿದ API, ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯ, ಲೈಬ್ರರಿ, ಇತ್ಯಾದಿಗಳಿದ್ದಾಗ, ನಮ್ಮ ಕಾಂಟ್ರಾಪ್ಟ್‌ಗಳನ್ನು ಬೇಲಿ ಹಾಕಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ನಾವು ಸಿದ್ಧ ಆಯ್ಕೆಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡುತ್ತೇವೆ. ಎರಡನೆಯದು ಕೂಡ ಸಾಕು. ಆದ್ದರಿಂದ, ಲಾಗ್‌ಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವಾಗ, ದೋಷಗಳ ಸಿಂಹ ಪಾಲು ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳು, ಸಿಸ್ಟಮ್ ಕರೆಗಳು ಮತ್ತು ಇತರ ಲೈಬ್ರರಿಗಳ ಸಂದೇಶಗಳ ಮೇಲೆ ಬೀಳುತ್ತದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, VBR ನ ಪಾತ್ರವು ಈ ದೋಷಗಳನ್ನು ಲಾಗ್ ಫೈಲ್‌ಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬರುತ್ತದೆ. ಮತ್ತು ಬಳಕೆದಾರರ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ಯಾವ ಸಾಲು ಯಾರಿಂದ ಬಂದಿದೆ ಮತ್ತು ಈ “ಯಾರು” ಏನು ಜವಾಬ್ದಾರರು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಲಿಯುವುದು. ಆದ್ದರಿಂದ VBR ಲಾಗ್‌ನಿಂದ ದೋಷ ಕೋಡ್ ನಿಮ್ಮನ್ನು MSDN ಪುಟಕ್ಕೆ ಕರೆದೊಯ್ಯಿದರೆ, ಅದು ಉತ್ತಮ ಮತ್ತು ಸರಿಯಾಗಿದೆ.

ನಾವು ಮೊದಲೇ ಒಪ್ಪಿಕೊಂಡಂತೆ: Veeam ಎಂಬುದು SQL-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್ ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತದೆ. ಇದರರ್ಥ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಎಲ್ಲಾ ಮಾಹಿತಿ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಮಾನ್ಯ ಕಾರ್ಯಚಟುವಟಿಕೆಗೆ ಮಾತ್ರ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವೂ - ಎಲ್ಲವನ್ನೂ ಅದರ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ ಸರಳ ಸತ್ಯ: ಲಾಗ್‌ಗಳಲ್ಲಿ ಇಲ್ಲದಿರುವುದು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಇರುತ್ತದೆ. ಆದರೆ ಇದು ಬೆಳ್ಳಿ ಬುಲೆಟ್ ಅಲ್ಲ: ಕೆಲವು ವಿಷಯಗಳು ವೀಮ್ ಘಟಕಗಳ ಸ್ಥಳೀಯ ಲಾಗ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಅದರ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ಹೋಸ್ಟ್ ಲಾಗ್‌ಗಳು, ಸ್ಥಳೀಯ ಯಂತ್ರದ ಲಾಗ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕ್‌ಅಪ್ ಮತ್ತು ಮರುಸ್ಥಾಪನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಎಲ್ಲದರ ಲಾಗ್‌ಗಳನ್ನು ಹೇಗೆ ಅಧ್ಯಯನ ಮಾಡುವುದು ಎಂಬುದನ್ನು ನೀವು ಕಲಿಯಬೇಕು. ಮತ್ತು ಅಗತ್ಯ ಮಾಹಿತಿಯು ಎಲ್ಲಿಯೂ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಅದು ಸಂಭವಿಸುತ್ತದೆ. ಅದುವೇ ದಾರಿ. 

ಅಂತಹ API ಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳು

ಈ ಪಟ್ಟಿಯು ಅಸಾಧಾರಣವಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವ ಗುರಿಯನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದರಲ್ಲಿ ಅಂತಿಮ ಸತ್ಯವನ್ನು ಹುಡುಕುವ ಅಗತ್ಯವಿಲ್ಲ. ನಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಸಾಮಾನ್ಯ ಮೂರನೇ ವ್ಯಕ್ತಿಯ API ಗಳು ಮತ್ತು ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ತೋರಿಸುವುದು ಮಾತ್ರ ಇದರ ಉದ್ದೇಶವಾಗಿದೆ.

ಇದರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ ವರೆ. 

ಪಟ್ಟಿಯಲ್ಲಿ ಮೊದಲನೆಯದು ಇರುತ್ತದೆ vSphere API. ದೃಢೀಕರಣಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಕ್ರಮಾನುಗತವನ್ನು ಓದುವುದು, ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಅಳಿಸುವುದು, ಯಂತ್ರಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ವಿನಂತಿಸುವುದು, ಮತ್ತು ಹೆಚ್ಚು (ಬಹಳ ಹೆಚ್ಚು) ಹೆಚ್ಚು. ಪರಿಹಾರದ ಕಾರ್ಯವು ತುಂಬಾ ವಿಸ್ತಾರವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಾನು ಆವೃತ್ತಿಗಾಗಿ VMware vSphere API ಉಲ್ಲೇಖವನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು 5.5 и 6.0. ಹೆಚ್ಚು ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳಿಗಾಗಿ, ಎಲ್ಲವನ್ನೂ ಗೂಗಲ್ ಮಾಡಲಾಗಿದೆ.

VIX API. ಹೈಪರ್ವೈಸರ್ನ ಕಪ್ಪು ಮ್ಯಾಜಿಕ್, ಇದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕವಿದೆ ದೋಷ ಪಟ್ಟಿ. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಫೈಲ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸದೆ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು VMware API. ಉತ್ತಮ ಸಂವಹನ ಚಾನೆಲ್ ಇಲ್ಲದ ಯಂತ್ರದಲ್ಲಿ ನೀವು ಫೈಲ್ ಅನ್ನು ಹಾಕಬೇಕಾದಾಗ ಕೊನೆಯ ಉಪಾಯದ ರೂಪಾಂತರ. ಫೈಲ್ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಮತ್ತು ಹೋಸ್ಟ್ ಲೋಡ್ ಆಗಿದ್ದರೆ ಅದು ನೋವು ಮತ್ತು ಸಂಕಟವಾಗಿದೆ. ಆದರೆ ಇಲ್ಲಿ ನಿಯಮವು 56,6 Kb / s ಸಹ 0 Kb / s ಗಿಂತ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಹೈಪರ್-ವಿಯಲ್ಲಿ, ಈ ವಿಷಯವನ್ನು ಪವರ್‌ಶೆಲ್ ಡೈರೆಕ್ಟ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಆದರೆ ಅದು ಮೊದಲು ಮಾತ್ರ

vSpehere ವೆಬ್ ಸೇವೆಗಳ API vSphere 6.0 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ (ಅಂದಾಜು, ಈ API ಅನ್ನು ಮೊದಲು ಆವೃತ್ತಿ 5.5 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾಯಿತು) ಇದನ್ನು ಅತಿಥಿ ಯಂತ್ರಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು VIX ಅನ್ನು ಬಹುತೇಕ ಎಲ್ಲೆಡೆ ಬದಲಾಯಿಸಲಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ಇದು vSphere ಅನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತೊಂದು API ಆಗಿದೆ. ಆಸಕ್ತಿ ಹೊಂದಿರುವವರಿಗೆ, ನಾನು ಅಧ್ಯಯನ ಮಾಡಲು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ವಿರಳ ಕೈಪಿಡಿ. 

ವಿಡಿಡಿಕೆ (ವರ್ಚುವಲ್ ಡಿಸ್ಕ್ ಡೆವಲಪ್ಮೆಂಟ್ ಕಿಟ್). ಇದರಲ್ಲಿ ಭಾಗಶಃ ಚರ್ಚಿಸಿದ ಗ್ರಂಥಾಲಯ ಲೇಖನ. ವರ್ಚುವಲ್ ಡಿಸ್ಕ್ಗಳನ್ನು ಓದಲು ಬಳಸಲಾಗುತ್ತದೆ. ಒಂದು ಕಾಲದಲ್ಲಿ ಇದು VIX ನ ಭಾಗವಾಗಿತ್ತು, ಆದರೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನಕ್ಕೆ ಸ್ಥಳಾಂತರಿಸಲಾಯಿತು. ಆದರೆ ಉತ್ತರಾಧಿಕಾರಿಯಾಗಿ, ಇದು VIX ನಂತೆಯೇ ಅದೇ ದೋಷ ಸಂಕೇತಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಆದರೆ ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ, SDK ನಲ್ಲಿಯೇ ಈ ದೋಷಗಳ ಯಾವುದೇ ವಿವರಣೆಯಿಲ್ಲ. ಆದ್ದರಿಂದ, ಇತರ ಕೋಡ್‌ಗಳೊಂದಿಗೆ VDDK ದೋಷಗಳು ಬೈನರಿಯಿಂದ ದಶಮಾಂಶ ಕೋಡ್‌ಗೆ ಅನುವಾದವಾಗಿದೆ ಎಂದು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ಇದು ಎರಡು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ - ಮೊದಲಾರ್ಧವು ಸಂದರ್ಭದ ಬಗ್ಗೆ ದಾಖಲೆರಹಿತ ಮಾಹಿತಿಯಾಗಿದೆ, ಮತ್ತು ಎರಡನೇ ಭಾಗವು ಸಾಂಪ್ರದಾಯಿಕ VIX / VDDK ದೋಷಗಳು. ಉದಾಹರಣೆಗೆ, ನಾವು ನೋಡಿದರೆ:

VDDK error: 21036749815809.Unknown error

ನಂತರ ನಾವು ಇದನ್ನು ಧೈರ್ಯದಿಂದ ಹೆಕ್ಸ್‌ಗೆ ಪರಿವರ್ತಿಸುತ್ತೇವೆ ಮತ್ತು 132200000001 ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ. ನಾವು 132200 ರ ಮಾಹಿತಿಯಿಲ್ಲದ ಆರಂಭವನ್ನು ಸರಳವಾಗಿ ತಿರಸ್ಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಉಳಿದವು ನಮ್ಮ ದೋಷ ಕೋಡ್ ಆಗಿರುತ್ತದೆ (VDDK 1: ಅಜ್ಞಾತ ದೋಷ). ಪದೇ ಪದೇ VDDK ದೋಷಗಳ ಬಗ್ಗೆ, ಇತ್ತೀಚೆಗೆ ಪ್ರತ್ಯೇಕವಾಗಿದೆ ಲೇಖನ.

ಈಗ ನೋಡೋಣ ವಿಂಡೋಸ್.

ಇಲ್ಲಿ, ನಮಗೆ ಅತ್ಯಂತ ಅಗತ್ಯವಾದ ಮತ್ತು ಮುಖ್ಯವಾದ ಎಲ್ಲವನ್ನೂ ಮಾನದಂಡದಲ್ಲಿ ಕಾಣಬಹುದು ಈವೆಂಟ್ ವೀಕ್ಷಕ. ಆದರೆ ಒಂದು ಕ್ಯಾಚ್ ಇದೆ: ಸುದೀರ್ಘ ಸಂಪ್ರದಾಯದ ಪ್ರಕಾರ, ವಿಂಡೋಸ್ ದೋಷದ ಪೂರ್ಣ ಪಠ್ಯವನ್ನು ಲಾಗ್ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ಅದರ ಸಂಖ್ಯೆ ಮಾತ್ರ. ಉದಾಹರಣೆಗೆ, ದೋಷ 5 "ಪ್ರವೇಶ ನಿರಾಕರಿಸಲಾಗಿದೆ", ಮತ್ತು 1722 "RPC ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲ", ಮತ್ತು 10060 "ಸಂಪರ್ಕ ಸಮಯ ಮೀರಿದೆ". ಸಹಜವಾಗಿ, ನೀವು ಅತ್ಯಂತ ಪ್ರಸಿದ್ಧವಾದವುಗಳನ್ನು ನೆನಪಿಸಿಕೊಂಡರೆ ಅದು ಅದ್ಭುತವಾಗಿದೆ, ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ನೋಡದಿರುವವುಗಳ ಬಗ್ಗೆ ಏನು? 

ಮತ್ತು ಜೀವನವು ಜೇನುತುಪ್ಪದಂತೆ ತೋರುವುದಿಲ್ಲ, ದೋಷಗಳನ್ನು ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ರೂಪದಲ್ಲಿ 0x8007 ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, 0x8007000e ವಾಸ್ತವವಾಗಿ 14 ಆಗಿದೆ, ಮೆಮೊರಿಯಿಂದ ಹೊರಗಿದೆ. ಇದನ್ನು ಏಕೆ ಮತ್ತು ಯಾರಿಗಾಗಿ ಮಾಡಲಾಗಿದೆ ಎಂಬುದು ಕತ್ತಲೆಯಲ್ಲಿ ಆವರಿಸಿರುವ ನಿಗೂಢವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ದೋಷಗಳ ಸಂಪೂರ್ಣ ಪಟ್ಟಿಯನ್ನು ಉಚಿತವಾಗಿ ಮತ್ತು SMS ಇಲ್ಲದೆ ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದು devcenter.

ಮೂಲಕ, ಕೆಲವೊಮ್ಮೆ ಇತರ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಇವೆ, ಕೇವಲ 0x8007 ಅಲ್ಲ. ಅಂತಹ ದುಃಖದ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, HRESULT ("ಫಲಿತಾಂಶ ಹ್ಯಾಂಡಲ್") ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನೀವು ಇನ್ನೂ ಆಳವಾಗಿ ಅಧ್ಯಯನ ಮಾಡಬೇಕಾಗುತ್ತದೆ ದಸ್ತಾವೇಜನ್ನು ಅಭಿವರ್ಧಕರಿಗೆ. ಸಾಮಾನ್ಯ ಜೀವನದಲ್ಲಿ, ಇದನ್ನು ಮಾಡಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುವುದಿಲ್ಲ, ಆದರೆ ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಗೋಡೆಯ ವಿರುದ್ಧ ಒತ್ತಿದರೆ ಅಥವಾ ಕುತೂಹಲದಿಂದ ಇದ್ದರೆ, ಈಗ ಏನು ಮಾಡಬೇಕೆಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ.

ಆದರೆ ಮೈಕ್ರೋಸಾಫ್ಟ್‌ನ ಒಡನಾಡಿಗಳು ನಮ್ಮ ಮೇಲೆ ಸ್ವಲ್ಪ ಕರುಣೆ ತೋರಿದರು ಮತ್ತು ಜಗತ್ತಿಗೆ ಉಪಯುಕ್ತತೆಯನ್ನು ತೋರಿಸಿದರು ಇಆರ್ಆರ್. ಇದು ಕನ್ಸೋಲ್ ಸಂತೋಷದ ಒಂದು ಸಣ್ಣ ಭಾಗವಾಗಿದ್ದು, 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 ಕರೆ ಕೂಡ ಇದೆ. ಆದರೆ ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಮಾತ್ರ ನಮಗೆ ಬರುವ ಎಲ್ಲವೂ ನಮ್ಮ ಲಾಗ್‌ಗಳಿಗೆ ಸಿಗುತ್ತದೆ. ಮತ್ತು ಇಲ್ಲಿ, ಅದನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು, ಒಬ್ಬರು ಈ ಪ್ರಜ್ಞೆಯ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಅದರಿಂದ ವಿಂಡೋಸ್ ದೋಷಗಳೊಂದಿಗೆ ತುಣುಕುಗಳನ್ನು ಹೊರತೆಗೆಯಿರಿ, ಅವುಗಳನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಮತ್ತೆ ಅಂಟಿಸಿ. ಪ್ರಾಮಾಣಿಕವಾಗಿರಲಿ, ಅತ್ಯಂತ ರೋಮಾಂಚಕಾರಿ ಚಟುವಟಿಕೆಯಲ್ಲ.

ವಿಂಡೋಸ್ ಫೈಲ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ API ಫೈಲ್ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ಸಾಧ್ಯವಿರುವ ಎಲ್ಲ ರೀತಿಯಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಫೈಲ್‌ಗಳನ್ನು ರಚಿಸುವುದು, ಅಳಿಸುವುದು, ಬರೆಯಲು ತೆರೆಯುವುದು, ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಇತ್ಯಾದಿ.

ಮೇಲೆ ಉಲ್ಲೇಖಿಸಿದ ಪವರ್‌ಶೆಲ್ ಡೈರೆಕ್ಟ್ ಹೈಪರ್-ವಿ ಪ್ರಪಂಚದಲ್ಲಿ VIX API ನ ಅನಲಾಗ್ ಆಗಿ. ದುರದೃಷ್ಟವಶಾತ್, ತುಂಬಾ ಮೃದುವಾಗಿಲ್ಲ: ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮೇಲೆ ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಗಳು, ಇದು ಹೋಸ್ಟ್ನ ಪ್ರತಿ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಅತಿಥಿಗಳೊಂದಿಗೆ ಅಲ್ಲ.

ಆರ್ಪಿಸಿ (ರಿಮೋಟ್ ಪ್ರೊಸೀಜರ್ ಕರೆ) RPC-ಸಂಬಂಧಿತ ದೋಷಗಳನ್ನು ನೋಡದಿರುವ ಒಬ್ಬನೇ ಒಬ್ಬ ವ್ಯಕ್ತಿ ವಿಂಡೋಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಜನಪ್ರಿಯ ತಪ್ಪು ಕಲ್ಪನೆಯ ಹೊರತಾಗಿಯೂ, ಇದು ಒಂದೇ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ, ಆದರೆ ಯಾವುದೇ ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಪ್ರೋಟೋಕಾಲ್ ಹಲವಾರು ನಿಯತಾಂಕಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನಮ್ಮ ಲಾಗ್‌ಗಳಲ್ಲಿ RPC ದೋಷವಿದ್ದರೆ, 90% ಸಮಯ ಅದು DCOM (ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಕಾಂಪೊನೆಂಟ್ ಆಬ್ಜೆಕ್ಟ್ ಮಾಡೆಲ್) ನ ಭಾಗವಾಗಿರುವ Microsoft RPC ನಿಂದ ದೋಷವಾಗಿರುತ್ತದೆ. ನಿವ್ವಳದಲ್ಲಿ ಈ ವಿಷಯದ ಕುರಿತು ನೀವು ದೊಡ್ಡ ಪ್ರಮಾಣದ ದಾಖಲಾತಿಗಳನ್ನು ಕಾಣಬಹುದು, ಆದರೆ ಅದರಲ್ಲಿ ಸಿಂಹ ಪಾಲು ಸಾಕಷ್ಟು ಹಳೆಯದು. ಆದರೆ ವಿಷಯವನ್ನು ಅಧ್ಯಯನ ಮಾಡಲು ತೀವ್ರವಾದ ಬಯಕೆ ಇದ್ದರೆ, ನಾನು ಲೇಖನಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡಬಹುದು 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 (ಸರ್ವರ್ ಸಂದೇಶ ಬ್ಲಾಕ್) ಯ ಖಾಸಗಿ ಆವೃತ್ತಿಯಾಗಿದೆ ಎಂದು ನೆನಪಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಈ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ತಪ್ಪಿಲ್ಲ. Samba ಈಗಾಗಲೇ LinuxUnix ಅಳವಡಿಕೆಯಾಗಿದೆ, ಮತ್ತು ಇದು ತನ್ನದೇ ಆದ ವಿಶಿಷ್ಟತೆಗಳನ್ನು ಹೊಂದಿದೆ, ಆದರೆ ನಾನು ವಿಷಯಾಂತರಗೊಳ್ಳುತ್ತೇನೆ. ಇಲ್ಲಿ ಮುಖ್ಯವಾದದ್ದು: UNC ಮಾರ್ಗಕ್ಕೆ (ಸರ್ವರ್ ಡೈರೆಕ್ಟರಿ) ಏನನ್ನಾದರೂ ಬರೆಯಲು Veeam ಕೇಳಿದಾಗ, ಚೆಂಡಿಗೆ ಬರೆಯಲು ಸರ್ವರ್ mup ಮತ್ತು mrxsmb ಸೇರಿದಂತೆ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಡ್ರೈವರ್‌ಗಳ ಶ್ರೇಣಿಯನ್ನು ಬಳಸುತ್ತದೆ. ಅಂತೆಯೇ, ಈ ಚಾಲಕರು ದೋಷಗಳನ್ನು ಸಹ ರಚಿಸುತ್ತಾರೆ.

ಇಲ್ಲದೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ವಿನ್ಸಾಕ್ API. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾದರೆ, ವಿಬಿಆರ್ ವಿಂಡೋಸ್ ಸಾಕೆಟ್ API ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದನ್ನು ಜನಪ್ರಿಯವಾಗಿ ವಿನ್‌ಸಾಕ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ನಾವು ಲಾಗ್‌ನಲ್ಲಿ ಐಪಿ: ಪೋರ್ಟ್‌ನ ಗುಂಪನ್ನು ನೋಡಿದರೆ, ಅದು ಇಲ್ಲಿದೆ. ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು ಸಾಧ್ಯವಿರುವ ಉತ್ತಮ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿದೆ ತಪ್ಪುಗಳು.

ಮೇಲೆ ಉಲ್ಲೇಖಿಸಿದ ಡಬ್ಲುಎಂಐ (ವಿಂಡೋಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಇನ್‌ಸ್ಟ್ರುಮೆಂಟೇಶನ್) ಎಂಬುದು ಒಂದು ರೀತಿಯ ಸರ್ವಶಕ್ತ API ಆಗಿದೆ, ಇದು ವಿಂಡೋಸ್ ಪ್ರಪಂಚದಲ್ಲಿ ಎಲ್ಲವನ್ನೂ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರನ್ನು ನಿರ್ವಹಿಸಲು. ಉದಾಹರಣೆಗೆ, ಹೈಪರ್-ವಿ ಜೊತೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಹೋಸ್ಟ್‌ಗೆ ಬಹುತೇಕ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಅದರ ಮೂಲಕ ಹೋಗುತ್ತವೆ. ಒಂದು ಪದದಲ್ಲಿ, ವಿಷಯವು ಸಂಪೂರ್ಣವಾಗಿ ಭರಿಸಲಾಗದ ಮತ್ತು ಅದರ ಸಾಮರ್ಥ್ಯಗಳಲ್ಲಿ ಅತ್ಯಂತ ಶಕ್ತಿಯುತವಾಗಿದೆ. ಎಲ್ಲಿ ಮತ್ತು ಏನು ಮುರಿದಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಹಾಯ ಮಾಡುವ ಪ್ರಯತ್ನದಲ್ಲಿ, ಅಂತರ್ನಿರ್ಮಿತ WBEMtest.exe ಉಪಕರಣವು ಬಹಳಷ್ಟು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಮತ್ತು ಪಟ್ಟಿಯಲ್ಲಿ ಕೊನೆಯದು, ಆದರೆ ಪ್ರಾಮುಖ್ಯತೆಯಲ್ಲಿ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ - VSS (ವಾಲ್ಯೂಮ್ ಶ್ಯಾಡೋ ಸ್ಟೋರೇಜ್). ವಿಷಯವು ಅಕ್ಷಯ ಮತ್ತು ನಿಗೂಢವಾಗಿದೆ, ಅದರ ಮೇಲೆ ಹೆಚ್ಚಿನ ದಾಖಲೆಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ. ನೆರಳು ನಕಲು ವಿಶೇಷ ರೀತಿಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಎಂದು ಸರಳವಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುತ್ತದೆ, ಮೂಲಭೂತವಾಗಿ ಅದು. ಅವರಿಗೆ ಧನ್ಯವಾದಗಳು, ನೀವು VMware ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್-ಸ್ಥಿರವಾದ ಬ್ಯಾಕ್ಅಪ್ಗಳನ್ನು ಮಾಡಬಹುದು ಮತ್ತು ಹೈಪರ್-V ನಲ್ಲಿ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು. ನಾನು VSS ನಲ್ಲಿ ಕೆಲವು ಸ್ಕ್ವೀಝ್ನೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಲೇಖನವನ್ನು ಮಾಡಲು ಯೋಜಿಸಿದೆ, ಆದರೆ ಇದೀಗ ನೀವು ಓದಲು ಪ್ರಯತ್ನಿಸಬಹುದು ಈ ವಿವರಣೆ. ಜಾಗರೂಕರಾಗಿರಿ, ಏಕೆಂದರೆ. ಒಂದು ಫ್ಲಾಶ್‌ನಲ್ಲಿ VSS ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುವುದು ಮೆದುಳಿನ ಗಾಯಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.

ಇದರ ಮೇಲೆ, ಬಹುಶಃ, ನಾವು ನಿಲ್ಲಿಸಬಹುದು. ಪೂರ್ಣಗೊಂಡ ಮೂಲಭೂತ ವಿಷಯಗಳನ್ನು ವಿವರಿಸುವ ಕಾರ್ಯವನ್ನು ನಾನು ಪರಿಗಣಿಸುತ್ತೇನೆ, ಆದ್ದರಿಂದ ಮುಂದಿನ ಅಧ್ಯಾಯದಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಲಾಗ್ಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಆದರೆ ನೀವು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವುಗಳನ್ನು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಕೇಳಲು ಮುಕ್ತವಾಗಿರಿ.

ಮೂಲ: www.habr.com