מזהי אירועים ופתרונות לגיבויים שמנוהלים על ידי מכשיר

מסוף הניהול של מכשיר Backup and DR יוצר אירועים גם למשימות שהצליחו וגם למשימות שנכשלו. בדף הזה מפורטים מזהי האירועים והודעות השגיאה.

בטבלה הבאה מפורטים מזהי אירועים חשובים של Backup and DR, הודעות על אירועים ושלבים לפתרון הבעיות:

מזהה אירוע הודעת אירוע מה לעשות?
5022 ‫Actifio Connector: הכנת קבוצת ה-VSS snapshot נכשלה הבעיה הזו מתרחשת אם מערכת Windows לא מצליחה ליצור קובץ snapshot של VSS. כדי לפתור את הבעיה:

  • בדיקת UDSAgent.log
  • בודקים את המקום בכונן באמצעי האחסון המוגנים. יכול להיות ש-300MB לא יספיקו.
  • בודקים אם יש שגיאות שקשורות ל-VSS ביומני האירועים של Windows.
  • יכול להיות ש-vssadmin list writers יציג כותבים במצב לא תקין.

בדרך כלל השגיאות האלה מלוות בשגיאות VSS שמדווחות ביומנים, כמו: VSS_E_VOLUME_NOT_SUPPORTED_BY_PROVIDER, VSS_E_UNEXPECTED_PROVIDER_ERROR.

קודם צריך לבדוק אם כל כותבי ה-VSS במצב יציב. כדי לעשות את זה, עוברים לשורת הפקודה ומזינים את הפקודה הבאה: # vssadmin list writers.

בודקים את הפלט כדי לוודא שכל הכותבים במצב יציב. מפעילים מחדש את שירות VSS ובודקים אם ה-writers יציבים. אם לא, יכול להיות שתצטרכו להפעיל מחדש את המכונה.
5024 ‫Actifio Connector: לא הצלחנו ליצור תמונת מצב של VSS לגיבוי. אין מספיק נפח אחסון פנוי כדי ליצור את קובץ האחסון של עותק הצללים או נתונים אחרים של עותק הצללים הבעיה הזו מתרחשת אם אין מספיק מקום בכונן כדי לעבד קובץ Snapshot.

  1. מוודאים שהאחסון של הנתונים שמגבים לא מלא.
  2. בודקים אם כל כותבי ה-VSS במצב יציב. משורת הפקודה של Windows, מריצים את הפקודות: vssadmin list providers, vssadmin list writers.
  3. אם השירותים האלה לא פועלים, צריך להפעיל אותם ולהריץ מחדש את המשימה. אם המצב של הכותב הוא Not Stable, צריך להפעיל מחדש את שירות ה-VSS. אם הבעיה נמשכת אחרי שמפעילים מחדש את השירות, מפעילים מחדש את המארח.

לפעמים ההודעה מופיעה כשמתרחשות שגיאות VSS פנימיות. בודקים אם יש שגיאות שקשורות ל-VSS ביומני האירועים של Windows. אם השגיאות קשורות ל-VSS, חפשו תיקונים קשורים של מיקרוסופט. פרטים נוספים על פתרון בעיות ב-VSS זמינים ב-Microsoft TechNet.

מיקרוסופט ממליצה על לפחות 320MB במכשירים שצוינו לשמירת תמונת המצב של VSS שנוצרה, בתוספת נתוני השינוי שמאוחסנים שם.

Actifio ממליצה להגדיר את שטח האחסון של עותק הצללים כלא מוגבל (unlimited) באמצעות הפקודות הבאות: vssadmin list shadowstorage, vssadmin Resize ShadowStorage /On=[drive]: /For=[drive]: / Maxsize=[size].

כדי לשנות את גודל שטח האחסון בממשק המשתמש של Windows, אפשר לעיין במאמר הגדרת Volume Shadow Copy ב-Windows Server 2008. מפעילים מחדש את הגיבוי אחרי שמצב ה-VSS יציב ונפח האחסון של עותק הצל מוגדר כלא מוגבל.
5046 ה-LUN של שלב הגיבוי לא גלוי ל-Actifio Connector הבעיה הזו מתרחשת אם ה-LUN של ה-staging לא גלוי ל-UDSAgent במארח של האפליקציה, והמארח לא יכול לזהות את ה-LUN של ה-staging ממכשיר הגיבוי/השחזור.
5049 ‫Actifio Connector: זיהוי הנפח הלוגי ב-LUN של שלב הגיבוי נכשל ‫Actifio Connector לא הצליח לראות את ה-LUN של ה-staging. הסיבה לכך יכולה להיות חיבור לא תקין או בעיה ב-LUN.

צריך לוודא שהקישוריות של FC/iSCSI תקינה, ואז לוודא שהיא פועלת על ידי מיפוי ה-VDisk, חלוקה שלו למחיצות, עיצוב שלו והעתקת קבצים אליו. השלבים לחלוקה למחיצות ולפרמוט הם ספציפיים למערכת ההפעלה.
5078 ‫Actifio Connector: דיסק ה-staging מלא המשימות נכשלות אם קובץ ששונה בדיסק המקור מועתק לדיסק ה-staging, אבל הקובץ גדול יותר מהשטח הפנוי שזמין בדיסק ה-staging. כדי לפתור את הבעיה בדיסק ה-staging המלא, צריך להגדיל את דיסק ה-staging. מציינים את גודל הדיסק הזמני בהגדרות המתקדמות של האפליקציה. מגדירים את הערך של גודל הדיסק הזמני כך שיהיה גדול יותר מסכום הגודל של דיסק המקור והגודל של הקובץ הכי גדול.
הערה: שינוי הדיסק הזמני בהגדרות המתקדמות גורם לגיבוי מלא.
5087 ‫Actifio Connector: כתיבת הקבצים נכשלה במהלך הגיבוי (קובץ מקור) יכול להיות שתוכנות אנטי-וירוס או מנהלי התקנים של צד שלישי הפעילו נעילות קבצים שאי אפשר לעקוף.

צריך לבדוק את UDSAgent.log כדי לראות לאיזה קובץ לא הייתה גישה. נסו לגלות איזה תהליך נועל את הקובץ באמצעות lsof ב-Unix או ב-Linux, או באמצעות fltmc ב-Windows. צריך להחריג את הקובץ מהאנטי-וירוס או ממשימת הצילום ולנסות שוב לצלם.

התהליכים הנוכחיים שמוכרים למיקרוסופט מפורטים בכתובת: Allocated filter altitudes.

השגיאות האלה מופיעות לעיתים רחוקות ב-Unix או ב-Linux, אבל יכול להיות שתהליך כמו תחזוקת מסד נתונים או התקנה או עדכון של תיקון יצר נעילה בלעדית בקובץ. צריך להתקין את הגרסה האחרונה של Actifio Connector.

מערכת ההפעלה המארחת זיהתה מגבלה או חוסר עקביות במערכת הקבצים. מריצים את מאחה הדיסק של Windows בדיסק ה-staging.

תפוקת קלט/פלט נמוכה מהדיסקים של המארחים או מאמצעי התחבורה, iSCSI או FC. מוודאים שאין בעיות קלט/פלט בדיסקים או באמצעי ההעברה של המארח. אמצעי התחבורה יהיה iSCSI או Fibre Channel, בהתאם להגדרה מחוץ לפס. במקרה הצורך, אפשר להתייעץ עם מנהלי האחסון ומנהלי הרשת.
‫5131 – שגיאה 3041 בדוח של יומני SQL גיבויים של יומני SQL במכונה נכשלים עם שגיאה 5131 כדי לפתור את הבעיה, צריך להפעיל את האפשרות "Don't forcefully unload the user registry at user logoff" (לא לפרוק בכוח את רישום המשתמשים בזמן התנתקות המשתמשים). מידע נוסף זמין במאמר User Profile Service functionality (פונקציונליות של שירות פרופיל המשתמש).
‫5131 – ביומני SQL מוצגת שגיאה 43901 במכשירי הגיבוי/השחזור משימות של תמונת מצב נכשלות עם שגיאה 5131, ביומני SQL מוצגת שגיאה 43901 של מכשירי גיבוי/שחזור "משימת תמונת מצב נכשלה" הסיבה לכך היא שההתחברות ל-ODBC של מסד הנתונים נכשלה. כדי לפתור את הבעיה, צריך לתקן את ההתחברות ל-ODBC.
5136 ‫Actifio Connector: אי אפשר לקרוא את אמצעי האחסון הזמני כדי לפתור את הבעיה, צריך לבדוק את הפרטים בקובץ ‎/act/logs/UDSAgent.log ולפנות לתמיכה של Google.
5241 ‫Actifio Connector: לא הצלחנו לטעון/לשכפל אפליקציות מתמונה ממופה (קובץ מקור) שם המשתמש והסיסמה שנותחו מקובץ הבקרה לא תקינים. במקור, בודקים את הקובץ UDSAgent.log כדי לראות אם המקור מוגדר עם שם המשתמש והסיסמה הנכונים בקטע "הגדרות מתקדמות" במאפייני המחבר.
5547 ‫Oracle: הגיבוי של archivelog (קובץ מקור) נכשל הגיבוי של יומן הארכיון באמצעות פקודות הגיבוי של RMAN נכשל ב-Actifio Connector. הסיבות הסבירות לכך הן:

  • המחבר לא הצליח ליצור חיבור למסד הנתונים
  • אפליקציה אחרת מחקה את יומני הארכיון
  • שם השירות של TNS מוגדר באופן שגוי, ולכן פקודת הגיבוי נשלחת לצומת שבו הדיסק הזמני לא מותקן

מחפשים שגיאות ORA-‎ או RMAN-‎ ביומן RMAN. זו השגיאה שהתקבלה מ-Oracle. צריך להשתמש במשאב המועדף של Oracle, כי אלה לא תנאים של Backup and DR, ולכן אי אפשר לפתור אותם ב-Backup and DR.

  • יומני Actifio Connector:‏ /var/act/log/UDSAgent.log
  • יומני Oracle RMAN:‏ /var/act/log/********_rman.log
10022 כשל בחיבור זו שגיאה לשימוש כללי שמציינת שלא ניתן היה ליצור חיבור לרשת לשירות או למארח.
יכולות להיות לכך כמה סיבות, כמו: כתובת IP או הגדרת יציאה שגויות, חומת אש שחוסמת את החיבור או שהשירות המרוחק מושבת או לא נגיש. כדי לאבחן ולפתור את הבעיה:
  • בודקים את סטטוס המכשיר במסוף הניהול של המכשיר.
  • בודקים את החיבור הבסיסי לרשת.
  • בודקים את כתובת ה-IP.
  • בודקים את חומת האש ואת היציאות.
  • אם אף אחת מהפעולות האלה לא פותרת את הבעיה, פנו לתמיכה.
10032 מאגר תמונות המצב חרג מרמת האזהרה כדי לצמצם את הצריכה של מאגר קובצי ה-snapshot:

  • העברת מכונות וירטואליות של VMware מתמונת מצב לתוכנית גיבוי Direct-to-OnVault. לאחר מכן, צריך להגדיר את כל קובצי ה-snapshot כלא תקפים כדי לפנות את המקום שבו משתמשים הדיסקים של ה-staging וקובץ ה-snapshot האחרון. האפשרות הזו פועלת רק במכונות וירטואליות של VMware. סוגי אפליקציות אחרים עדיין משתמשים בחלק מהשטח של מאגר תמונות המצב אם הם מוגנים על ידי מדיניות Direct-to-OnVault.
  • כדי להקטין את מספר חבילות ה-snap שנשמרות לאפליקציה, צריך לשנות את תבנית המדיניות. אפליקציות עם שיעורי שינוי גבוהים יוצרות קובצי snapshot גדולים יותר, ולכן היתרון הזה משמעותי יותר לאפליקציות עם שיעורי שינוי גבוהים. זה לא בהכרח מוביל ל-RPO שונה, אפשר ליצור תמונות OnVault של כל תמונת מצב לפני שהתוקף שלהן פג.
  • אם אין צורך בנקודות טעינה, בשיבוטים ובשיבוטים פעילים, אפשר למחוק אותם.
10038 עומדת להיות חריגה ממגבלת האזהרה של VDisk כדי להפחית באופן מיידי את צריכת ה-VDisk, מבצעים את הפעולות הבאות:

  • מוודאים שתאריכי התפוגה מופעלים, גם ברמה הגלובלית וגם ברמת האפליקציה הספציפית.
  • קיבוץ מסדי נתונים ממארח אחד לקבוצת אפליקציות עקביות. לדוגמה, אם למארח יש 9 מסדי נתונים, יוצרים קבוצת אפליקציות עקביות אחת לכל 9 מסדי הנתונים, ואז מגנים על קבוצת האפליקציות העקביות הזו במקום על מסדי הנתונים הנפרדים.
  • כדי להפחית את מספר תמונות המצב שנשמרות לאפליקציה, משנים את תבנית המדיניות שמשמשת את תוכנית הגיבוי.
  • מוחקים תמונות לא רצויות של נקודות טעינה, שיבוטים ושיבוטים פעילים.
  • העברת מכונות וירטואליות של VMware מתמונת מצב לתוכנית גיבוי של Direct-OnVault. כדי לשחרר את הדיסקים הווירטואליים שמשמשים את הדיסקים של ה-staging, צריך להגדיר את כל תמונות המצב כלא בתוקף. הפעולה הזו רק מקטינה את מספר הדיסקים הווירטואליים של המכונות הווירטואליות של VMware, ועדיין משתמשת בדיסקים וירטואליים כשהם מוגנים על ידי מדיניות ישירה ל-OnVault.
  • משנים את קובצי ה-VMDK של VMware שלא צריך להגן עליהם למצב עצמאי, כי אי אפשר להגן עליהם באמצעות קובצי snapshot של VMware.

אם ההתראה הזו חוזרת על עצמה מדי יום אבל המכשיר לא מגיע למספר המקסימלי של דיסקים וירטואליים, צריך לשנות את כללי המדיניות כדי להפחית את מספר הדיסקים הווירטואליים שבשימוש, או להגדיל את סף ההתראה. במהלך חלון הזמן של תמונת המצב היומית, מספר הדיסקים הווירטואליים יכול להשתנות בזמן שנוצרים דיסקים וירטואליים חדשים לתמונות מצב, לפני שהדיסקים הווירטואליים הישנים מוסרים כחלק מתפוגת תמונות המצב. התנודות היומיות משתנות בהתאם למספר האפליקציות המוגנות.
10039 שגיאה בחיבור לרשת בהגעה להתקן האחסון פינג של פעימת לב לאחסון במעקב נכשל בגלל תקלה בחומרה או בעיה ברשת. כדי לפתור את הבעיה, צריך לבדוק את הרשת.
10043 זוהתה הפרה של תוכנית הגיבוי כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשפר את כללי המדיניות. אלה סיבות נפוצות להפרות של תוכנית הגיבוי.

  • מתזמן המשימות לא מופעל. איך מפעילים את התזמון
  • המשימות הראשונות של אפליקציות חדשות יכולות להימשך הרבה זמן: זמני משימות ארוכים יכולים להתרחש במהלך המשימה הראשונה של תמונת המצב או ביטול הכפילויות של אפליקציה. אפשר להשתמש בהגדרות של On-ramp כדי למנוע ממשימות הטמעה לנעול משבצות ולנעול אפליקציות מוטמעות. הגדרת סדרי עדיפויות לאפליקציות החדשות הראשונות
  • אין גישה לאפליקציות בגלל בעיות ברשת.
  • חלונות המדיניות קטנים מדי או שזמני ההרצה של המשימות ארוכים מדי: אתם לא יכולים לשלוט במשך הזמן שלוקח לכל משימה לפעול, אבל אתם יכולים לשלוט בזמן התזמון של האפליקציות שפועלות. משימות שפועלות במשך שעות רבות תופסות משבצות של משימות שיכולות לשמש אפליקציות אחרות. כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשנות את כללי המדיניות בהתאם.
  • תהליך השכפול שולח את הנתונים למכשיר גיבוי או שחזור מרוחק. מוודאים שרוחב הפס והניצול של קישור הרפליקציה לא רוויים.
10046 מאגר נתוני הביצועים חרג מהסף הבטוח כדי לצמצם את הצריכה של מאגר קובצי ה-snapshot:

  • העברת מכונות וירטואליות של VMware מתמונת מצב לתוכנית גיבוי Direct-to-OnVault. לאחר מכן, צריך להגדיר את כל קובצי ה-snapshot כלא תקפים כדי לפנות את המקום שבו משתמשים הדיסקים של ה-staging וקובץ ה-snapshot האחרון. האפשרות הזו פועלת רק במכונות וירטואליות של VMware. סוגי אפליקציות אחרים עדיין משתמשים בחלק מהשטח של מאגר תמונות המצב אם הם מוגנים על ידי מדיניות Direct-to-OnVault.
  • כדי להקטין את מספר חבילות ה-snap שנשמרות לאפליקציה, צריך לשנות את תבנית המדיניות. אפליקציות עם שיעורי שינוי גבוהים יוצרות קובצי snapshot גדולים יותר, ולכן היתרון הזה משמעותי יותר לאפליקציות עם שיעורי שינוי גבוהים. זה לא בהכרח מוביל ל-RPO שונה, אפשר ליצור תמונות OnVault של כל תמונת מצב לפני שהתוקף שלהן פג.
  • אם אין צורך בנקודות טעינה, בשיבוטים ובשיבוטים פעילים, אפשר למחוק אותם.
10055 אי אפשר לבדוק את ההגנה מרחוק כל מכשיר גיבוי/שחזור בודק את המכשיר המרוחק מדי שעה כדי לאתר בעיות אפשריות בהגנה מרחוק. התקשורת של המכשיר נכשלת בגלל הבעיות הבאות:

  • שגיאה בחיבור לרשת (זמנית או קבועה). שגיאה זמנית בחיבור לרשת לא גורמת למשימה להיכשל. המערכת מנסה להפעיל את המשימות שוב, אבל הבדיקה השעתית לא מתעדכנת.

  • שגיאת אישור. כדי לתקן את השגיאה באישור, צריך להחליף את האישור מחדש.
10070 התזמון של Udppm מושבת למשך יותר מ-30 דקות. התזמון מושבת. יכול להיות שהסיבה לכך היא תחזוקה. אם עבודות התחזוקה הסתיימו, אפשר להפעיל מחדש את המתזמן. כאן מוסבר איך עושים את זה.
10084 התראה לגבי האפליקציה (שם האפליקציה) והמדיניות (שם המדיניות): המשימה לא הופעלה מסיבה לא ידועה כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשפר את כללי המדיניות. אלה סיבות נפוצות להפרות של תוכנית הגיבוי.

  • מתזמן המשימות לא מופעל. איך מפעילים את התזמון
  • המשימות הראשונות של אפליקציות חדשות יכולות להימשך הרבה זמן: זמני משימות ארוכים יכולים להתרחש במהלך המשימה הראשונה של תמונת המצב או ביטול הכפילויות של אפליקציה. אפשר להשתמש בהגדרות של On-ramp כדי למנוע ממשימות הטמעה לנעול משבצות ולנעול אפליקציות מוטמעות. הגדרת סדרי עדיפויות לאפליקציות החדשות הראשונות
  • אי אפשר לגשת לאפליקציות בגלל בעיות ברשת.
  • חלונות המדיניות קטנים מדי או שזמני ההרצה של המשימות ארוכים מדי: אתם לא יכולים לשלוט במשך הזמן שלוקח לכל משימה לפעול, אבל אתם יכולים לשלוט בזמן התזמון של האפליקציות שפועלות. משימות שפועלות במשך שעות רבות תופסות משבצות של משימות שיכולות לשמש אפליקציות אחרות. כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשנות את כללי המדיניות בהתאם.
  • תהליך השכפול שולח את הנתונים למכשיר גיבוי או שחזור מרוחק. מוודאים שרוחב הפס והניצול של קישור הרפליקציה לא רוויים.
10085 הפרה של תוכנית הגיבוי באפליקציה (שם האפליקציה) במארח (שם המארח) ובמדיניות (שם המדיניות). המשימה לא הופעלה מסיבה לא ידועה. כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשפר את כללי המדיניות. אלה סיבות נפוצות להפרות של תוכנית הגיבוי.

  • מתזמן המשימות לא מופעל. איך מפעילים את התזמון
  • המשימות הראשונות של אפליקציות חדשות יכולות להימשך הרבה זמן: זמני משימות ארוכים יכולים להתרחש במהלך המשימה הראשונה של תמונת המצב או ביטול הכפילויות של אפליקציה. אפשר להשתמש בהגדרות של On-ramp כדי למנוע ממשימות הטמעה לנעול משבצות ולנעול אפליקציות מוטמעות. הגדרת סדרי עדיפויות לאפליקציות החדשות הראשונות
  • אין גישה לאפליקציות בגלל בעיות ברשת.
  • חלונות המדיניות קטנים מדי או שזמני ההרצה של המשימות ארוכים מדי: אתם לא יכולים לשלוט במשך הזמן שלוקח לכל משימה לפעול, אבל אתם יכולים לשלוט בזמן התזמון של האפליקציות שפועלות. משימות שפועלות במשך שעות רבות תופסות משבצות של משימות שיכולות לשמש אפליקציות אחרות. כדאי לעיין בשיטות המומלצות לתוכנית גיבוי ולשנות את כללי המדיניות בהתאם.
  • תהליך השכפול שולח את הנתונים למכשיר גיבוי או שחזור מרוחק. מוודאים שרוחב הפס והניצול של קישור הרפליקציה לא רוויים.
10120 ‫Psrv הופעל בהצלחה זהו אירוע פנימי ואפשר להתעלם ממנו.
10220 שירות NTP לא פועל או לא מסונכרן. שירות ה-NTP במכשיר הגיבוי לא פועל. שירות ה-NTP נדרש כדי לוודא שמכשיר הגיבוי משתמש בחותמות הזמן הנכונות. מכשיר Compute Engine צריך להשתמש ב-metadata.google.internal. פועלים לפי ההוראות להגדרת שרת NTP בשיטת DNS ו-NTP.
10225 נמצאו קובצי ליבה של UDP, שם הקובץ udpengine.(file name) תהליכים פנימיים מתעדים קובצי שגיאות באופן לא צפוי. כדי לפתור את הבעיה, פנו לתמיכה של Google.
10229 חריגה ממכסת האחסון, שם המערכת: (שם המכשיר) זהו אירוע פנימי ובדרך כלל אפשר להתעלם ממנו.
10237 המשימה X פועלת כבר יותר מ-3 שעות. יש הרבה סיבות לכך שמשימה נמשכת יותר מ-3 שעות.
11001 תוקף האישור של מכשיר הגיבוי יפוג בעוד X ימים. כדי לחדש את הרישיון, צריך להפעיל את המכשיר למשך 24 שעות או לפנות לתמיכה. האישור של מכשיר הגיבוי או השחזור עודכן לפני יותר מ-15 ימים. אם מכשיר הגיבוי או השחזור מושבת, צריך להפעיל אותו.
11004 רכיבי המערכת מושבתים. אם הגיבויים מושפעים, צריך לפנות לתמיכה. פנייה לתמיכה.
11006 לא ניתן לסנכרן עם מארח X, נדרש סנכרון רגיל עם המארח כדי למנוע אובדן תקשורת קבוע בין מכשיר הגיבוי למארח. האישור במארח לא עודכן במשך יותר מ-7 ימים. כדאי להפעיל מחדש את המכשיר ולהתחבר שוב למארח.
20019 אין מספיק מעבד (CPU) או זיכרון. מספר הליבות המינימלי הנדרש: (ליבות) ליבות בפועל : (ליבות). גודל הזיכרון המינימלי הנדרש (GB): (זיכרון) הזיכרון בפועל : (זיכרון) מכשיר הגיבוי/השחזור השתנה והוא לא בגודל המומלץ. כדי לפתור את הבעיה, פנו לתמיכה של Google.
20025 חריגה מהשימוש בזיכרון הווירטואלי (swap) הבעיה הזו מתרחשת כשהשימוש ב-swap חורג מהמגבלה שנקבעה למכשיר הגיבוי/השחזור. כדי לפתור את הבעיה, פנו לתמיכה של Google.
20030 tomcat stopped successfully זהו אירוע פנימי ואפשר להתעלם ממנו.
20031 tomcat started successfully זהו אירוע פנימי ואפשר להתעלם ממנו.
22001 ‫OMD הופעל בהצלחה, sltname: , slpname: . זהו אירוע פנימי ואפשר להתעלם ממנו.
42356 זוהו שינויים בקבצים, לא זוהו קבצים שנמחקו, זוהו קבצים חדשים. זהו אירוע פנימי ואפשר להתעלם ממנו.
43151 לא ניתן להוסיף מיפויים של מכשירים גולמיים למכונה וירטואלית (VM). שגיאה: המשימה של המכונה הווירטואלית נכשלה. אירעה שגיאת מערכת כללית: המערכת החזירה שגיאה. הוספת מיפוי של מכשיר גולמי למכונה וירטואלית "מקפיאה" את המכונה הווירטואלית עד ש-ESX מוסיף את המשאב החדש. כדי להבין למה לא ניתן להוסיף את מיפוי המכשיר הגולמי, צריך לעיין ביומני ה-ESX של המכונה הווירטואלית הרלוונטית (vmware.log).

אפשר להיעזר במסמכי התיעוד ובמאגר הידע של VMware כדי לבדוק את הודעות השגיאה ביומנים. בנוסף, כדאי לקרוא את המאמר של VMware בנושא איסוף יומנים של VMware.
43155 שגיאה: המשימה של המכונה הווירטואלית נכשלה. אירעה שגיאה במהלך שמירת קובץ ה-snapshot: לא ניתן היה להשעות את המכונה הווירטואלית. זו בעיה ב-VMware. למידע נוסף, אפשר לעיין במאמר 1015180 במאגר הידע של VMware. בעיות בהשהיית מכונות וירטואליות תלויות בסוג מערכת ההפעלה. כדי לפתור את הבעיה, צריך לבצע בדיקה נוספת, לחפש עוד במאמרי העזרה של VMware או לפנות לתמיכה של VMware.
43155 - a שגיאה: המשימה של המכונה הווירטואלית נכשלה. לא ניתן היה להוסיף את המכשיר scsi3 בזמן פעולה. בדרך כלל זה אומר שמכונה וירטואלית אחרת כבר משתמשת בהתקן ה-SCSI שאתם מנסים להוסיף למכונה הווירטואלית.
43155 - b שגיאה: המשימה של המכונה הווירטואלית נכשלה. הדיסק הווירטואלי פגום או שהפורמט שלו לא נתמך. הבעיה הזו מתרחשת אם קובצי ה-CTK של ה-VM נעולים, לא קריאים או נמצאים בתהליך של ביצוע שינויים. כדי לפתור את הבעיה, צריך להסיר את קובצי ה-CTK האלה וליצור אותם מחדש. מידע נוסף זמין במאמר 2013520 במאגר הידע.
43155 - c שגיאה: המשימה של המכונה הווירטואלית נכשלה. אי אפשר לבצע את הפעולה במצב הנוכחי של מאגר הנתונים. progress ="11" status="running"‎ יש שתי אפשרויות לפורמט של מאגר נתונים ב-VMware: ‏NFS ו-VMFS. ל-NFS יש כמה מגבלות, כמו חוסר היכולת לבצע RDM (מיפוי דיסק גולמי). כלומר, אי אפשר לטעון ממכשיר הגיבוי/השחזור למאגר נתונים של NFS. מידע נוסף זמין במאמר הזה במאגר הידע – 1001856.
43175 החיבור של שקע UDSAgent נותק באופן חריג בזמן ההמתנה לתגובה מהסוכן ה-Actifio Connector מפסיק להגיב בין המכשיר לבין מארח שמותקן בו סוכן Backup and DR.

  1. מפעילים מחדש את שירות הסוכן UDSAgent Backup and DR במארח שצוין.
  2. ‫Telnet ליציאת TCP‏ 5106 (יציאת התקשורת של UDSAgent):‏ Trying 10.50.100.67... Connected to dresx2.accu.local. Escape character is '^]'. Connection closed by foreign host.
  3. מוודאים שהחיבור לרשת בין המכשיר למארח לא מתנתק. אם הבעיה נמשכת, צריך לבצע ניתוח של הרשת.
43604 אימות טביעת האצבע נכשל זה קורה כשיש חוסר עקביות בין נתוני המקור לנתוני היעד. כדי לפתור את הבעיה, פנו לתמיכה של Google.
43690 למארח אין יציאות SAN או iSCSI מוגדרות. הבעיה הזו מתרחשת אם מכשיר הגיבוי/השחזור לא מוגדר עם חיבור iSCSI למארח היעד. מוודאים שיציאות הרשת פתוחות ל-iSCSI ושהמארח המטורגט גילה את מכשירי הגיבוי/השחזור.
43698 אין גישה למארח ESX להעברת נתונים במצב NBD מכשיר הגיבוי/השחזור לא מצליח להגיע למארח ה-ESX דרך הרשת או לזהות את שם המארח של ה-ESX באמצעות DNS. כדי לפתור את הבעיה, פנו לתמיכה של Google.
43702 הגיבוי בוטל כי יש יותר מדי קבצים נוספים בספריית הבית של המכונה הווירטואלית זהו תנאי התראה שנוצר על ידי Backup and DR, והוא נגרם על ידי קובצי דלתא שנותרו במאגר הנתונים של ה-VM. בדרך כלל, קובצי הדלתא מוסרים אחרי שמאחדים את קובץ ה-snapshot של Backup and DR. במקרים מסוימים, יכול להיות שהם יישארו אחרי האיחוד של VMware, והמערכת של Backup and DR תתחיל להכשיל משימות כדי למנוע את החמרת הבעיה. הבעיה הזו נגרמת על ידי VMware, אפשר לעיין במאמר 1002310 במאגר הידע.
43755 לא ניתן לפתוח את אמצעי האחסון של VMDK. צריך לבדוק את הקישוריות לשרת ESX. זה קורה כשהבקר לא מצליח להגיע לשרת ה-ESX, בדרך כלל בגלל בעיה בחיבור הפיזי או ב-DNS. כדי לפתור את הבעיה:

  • מוודאים שיציאה 902 פתוחה בין מכשיר הגיבוי/השחזור לבין מארח ה-ESX.
  • בודקים את שרת ה-DNS הנוכחי ומוודאים שהוא עדכני ותקין.
  • אם ה-vCenter וירטואלי, נסו לבצע גיבוי אחרי העברת ה-vCenter למארח ESX אחר.
  • מוודאים שהאפשרות "נדרש SSL" מוגדרת כ-True במארח ה-ESX בהגדרות המתקדמות.
43844 זוהה גודל לא תקין של vmdk במכונה הווירטואלית יש שני פתרונות אפשריים למצב הזה:

  • אם נדרש איחוד של דיסקים מסוימים במכונה הווירטואלית, הגודל מדווח כאפס. כדי לפתור את הבעיה, צריך ליצור ולמחוק קובץ snapshot של ה-VM.
  • בודקים אם אפשר לשחזר את ה-VMDK מתמונת גיבוי.
43873 השימוש במקום בכונן במאגר הנתונים חרג מהסף הקריטי הבעיה הזו מתרחשת כשהמקום שנותר במאגר הנתונים קטן מהסף הקריטי. אם לא יתפנה בקרוב עוד נפח אחסון, המשימות יתחילו להיכשל כשלא יהיה מספיק מקום פנוי לאחסן אותן.

ההתראה הזו נוצרה כדי לעזור לך לפעול כדי למנוע ממאגרי הנתונים של ESX להתמלא בנתוני קובצי snapshot. כדי להגדיל את השטח הפנוי, אפשר להרחיב את מאגר הנתונים, להעביר חלק מהמכונות הווירטואליות או למחוק נתונים ישנים במאגר הנתונים. התמונות של המצב הנוכחי גדלות ככל שמוסיפים עוד נתוני שינויים. אם מאגר נתונים מתמלא בגלל תמונת מצב שגדלה, יכול להיות ש-VMware תעביר מכונות וירטואליות למצב אופליין באופן אוטומטי כדי להגן על הנתונים.
43900 ניסיון חוזר של OnVault (יומן) (שם המשימה) בהמתנה לאפליקציה (שם האפליקציה) במארח (שם המארח) שגיאה: (מזהה השגיאה) (תיאור השגיאה) יש הרבה שגיאות שיכולות לגרום לניסיונות חוזרים של משימות. כל הודעת אירוע 43900 כוללת קוד שגיאה והודעת שגיאה.
43901 כשל במשימה יש הרבה שגיאות שיכולות לגרום לכשלים במשימות. כל הודעת אירוע 43901 כוללת קוד שגיאה והודעת שגיאה.
43903 המשימה של פקיעת התוקף נכשלה הבעיה הזו מתרחשת כשהתמונה נמצאת בשימוש בזמן שהתוקף שלה פג. יכול להיות שהסיבה לכך היא שהתמונה נמצאת בשימוש בתהליך או בפעולה אחרים, כמו טעינה, שכפול או שחזור. סביר להניח שמשימת התפוגה הושלמה בהצלחה בניסיון השני. Backup and DR לא מדווח על השלמת הניסיון השני בהצלחה. אם קיבלתם רק שגיאה אחת לגבי תמונה, אפשר להסיק שהניסיון השני להסיר את התמונה הצליח. אם יש סיבה לגיטימית לכך שלא ניתן להגדיר תפוגה לתמונה הזו, יוצגו כמה שגיאות שקשורות לתמונה. אם מופיעה יותר משגיאה אחת, פנו לתמיכה של Google.
43905 משימת הטעינה נכשלה יש הרבה סיבות שבגללן פעולת טעינה יכולה להיכשל. קוד השגיאה שמופיע לצד האירוע עוזר לזהות את שורש הבעיה.
43908 משימת השחזור נכשלה יש הרבה שגיאות שיכולות לגרום לכשלים במשימות. כל הודעת אירוע 43908 כוללת קוד שגיאה והודעת שגיאה.
43915 לא ניתן להתחבר למארח הגיבוי. צריך לוודא שסוכן Backup and DR פועל ב-(host) ושיציאת הרשת (port) פתוחה כדי להתחיל את הגיבוי, צריך שתהיה גישה לשירות Actifio Connector ממכשיר הגיבוי/השחזור. הבעיה הזו מתרחשת כשהיציאות הנדרשות לא פתוחות, כשכתובת ה-IP של המארח לא מוגדרת נכון, כששירות הסוכן של Backup and DR לא פועל או כשבמארח אין מספיק משאבים פיזיים. כדי לפתור את הבעיה:

  1. מוודאים שהיציאה שמשמשת את המארח, את מכשיר הגיבוי/השחזור ואת Actifio Connector פתוחה. כברירת מחדל, סוכן Backup and DR משתמש ביציאה 5106 לתקשורת דו-כיוונית ממכשיר הגיבוי/ההתאוששות. חשוב לוודא שחומת האש מאפשרת תקשורת דו-כיוונית דרך היציאה הזו.
  2. מוודאים שכתובת ה-IP הנכונה מוגדרת למארח Manage > Appliance > Configure Appliance Networking.
  3. מוודאים ששירות הסוכן של Backup and DR פועל במארח היעד, ומפעילים מחדש במקרה הצורך.
    • ב-Windows, מאתרים את השירות UDS Host Agent ב-services.msc ולוחצים על הפעלה מחדש.
    • ב-Linux, מריצים את הפקודה /etc/init.d/udsagent restart.
  4. מנסים לגבות שוב.
43941 השימוש במקום בכונן במאגר הנתונים חרג מהסף הקריטי הבעיה הזו מתרחשת כשהמקום שנותר במאגר הנתונים קטן מהסף הקריטי. אם לא יהיה עוד נפח אחסון בקרוב, המשימות יתחילו להיכשל כשהמקום שנותר לא יספיק לאחסון שלהן. ההתראה הזו נוצרה כדי לעזור לכם לפעול כדי למנוע ממאגרי הנתונים של ESX להתמלא בנתוני תמונות מצב. כדי להגדיל את המקום הפנוי, אפשר להרחיב את מאגר הנתונים, להעביר חלק מהמכונות הווירטואליות או למחוק נתונים ישנים במאגר הנתונים. התמונות של המצב הנוכחי גדלות ככל שמוסיפים עוד נתוני שינויים. אם מאגר נתונים מתמלא בגלל תמונת מצב שגדלה, יכול להיות ש-VMware תעביר מכונות וירטואליות למצב אופליין באופן אוטומטי כדי להגן על הנתונים.
43954 משימת OnVault שנכשלה במהלך משימת טעינה, מכשיר הגיבוי/השחזור לא מצליח להתחבר למאגר OnVault. הבעיה הזו יכולה לקרות בגלל אחת מהסיבות הבאות.

  • לא צוין שם קטגוריה למאגר OnVault.
  • פרטי הכניסה לא תקינים: מזהה הגישה או מפתח הגישה לא צוינו, או שהמזהה של מאגר OnVault שגוי.
  • קטגוריה לא חוקית במאגר OnVault.
  • בעיות אימות כלליות במאגר OnVault.
  • שרת ה-DNS באשכולות /etc/resolv.conf שונה, או שקובצי לתיאור תחומי ה-DNS לחיפוש רגיל ותחומי DNS לחיפוש הפוך השתנו.
43929 יצירת קובץ ה-snapshot של ה-VM נכשלה. שגיאה: המשימה של המכונה הווירטואלית נכשלה. קרתה שגיאה בשמירת קובץ ה-snapshot: לא הצלחנו להשעות את המכונה הווירטואלית. תמונת המצב של המכונה הווירטואלית נכשלת אם שרת ה-ESX לא מצליח להשעות את המכונה הווירטואלית – בגלל יותר מדי קלט/פלט, או בגלל שכלי VMware לא מצליחים להשעות את האפליקציה באמצעות VSS בזמן. בודקים את יומני האירועים במארח ואת יומן ה-ESX של המכונה הווירטואלית (vmware.log). ההתנהגות הזו פחות נפוצה בתמונות מצב של גיבוי ללא ריקון מידע ובגיבויים שמבוססים על מחברים. מידע נוסף זמין במאמרים 1018194 ו-1007696 במאגר הידע של VMware.
43933 לא נמצאה מכונה וירטואלית עם UUID תואם של BIOS הבעיה הזו מתרחשת אם ה-UUID של המכונה הווירטואלית משתנה. כדי לפתור את הבעיה, צריך לזהות מחדש את המכונה הווירטואלית ולבדוק אם היא זוהתה כ-UUID חדש. כדי לוודא את זה, אפשר להשוות במסוף הניהול של המכשיר בין ה-UUID של המכונה הווירטואלית החדשה שזוהתה לבין ה-UUID של המכונה הווירטואלית שזוהתה קודם. אם מזהי ה-UUID לא תואמים, יכול להיות שהמכונה הווירטואלית שוכפלה. השגיאה הזו יכולה להופיע גם אם מספר גדול של מכונות וירטואליות שמנוהלות על ידי Backup and DR הוסרו מ-vCenter.
43948 מספר התמונות שלא פג תוקפן וממתינות להמשך עיבוד הוא (x) תמונות ((x) תמונות מצב, (x) OnVault) מ-(x) אפליקציות ייחודיות. ‫(x) תמונות מצב ו-(x) OnVaults נוספו ב-(x) השניות האחרונות ((x) שעות (x) דקות)., sltname: No specific slt, slpname: No specific slp. מזהה האירוע 43948 נוצר כשאפליקציה מתחילה לעצור את התפוגה כחלק משימור התמונה. התכונה "שמירת תמונות" שומרת תמונות של OnVault ותמונות מצב מעבר לתאריכי התפוגה שלהן, כדי לוודא שהתמונות האלה יעובדו כראוי על ידי מכשיר הגיבוי/השחזור. כשאפליקציה חדשה נכנסת למצב שמור, נוצרת התראת אזהרה. הסיבה הנפוצה ביותר לכך היא הפרות של תוכנית הגיבוי, כפי שמתועד במזהה האירוע 10085.
43954 ניסיון חוזר של OnVault צריך לנסות שוב להפעיל משימת OnVault. בעיות אפשריות: לחשבון השירות שבו משתמשים יש תפקיד שגוי. לחשבון השירות אין הרשאה לכתוב בקטגוריה. הקטגוריה של Cloud Storage כבר לא קיימת.
43960 המערכת דילגה על הגיבוי של 6 אפליקציות אופליין של אפליקציית SqlServerWriter. בגיבוי של מכונה של SQL Server נמצאו כמה מסדי נתונים שהיו במצב אופליין ולא היה אפשר לגבות אותם. זה קורה בדרך כלל כשמסד הנתונים נמחק בצד השרת, אבל עדיין נכלל בצד של Backup/DR. הודעת השגיאה מכילה את השמות של מסדי הנתונים במצב אופליין שצריך לבדוק.
43972 העלאת המטא-נתונים לקטגוריה נכשלה. כתיבת המטא-נתונים לקטגוריית OnVault נכשלה. בעיות אפשריות: לחשבון השירות שבו משתמשים יש תפקיד שגוי. לחשבון השירות אין הרשאה לכתוב בקטגוריה. הקטגוריה של Cloud Storage כבר לא קיימת.
43973 ‫udppm הופעל בהצלחה זהו אירוע פנימי ואפשר להתעלם ממנו.
43999 אזהרה: המכונה הווירטואלית פועלת במארח שפועלת בו גרסה מיושנת של ESXi , שלא נתמכת על ידי Google. כדי לקבל את התוצאות הטובות ביותר, צריך לשדרג לגרסה נתמכת (>=). כדי להבטיח את התוצאות הטובות ביותר, צריך לשדרג את המכונה הווירטואלית לגרסה נתמכת (>=).
44003 הפעולה Job_xx-xx-xx בוצעה בהצלחה באפליקציה application ID במארח host, ‏sltname: ‏template, ‏slpname: ‏profile. זהו אירוע סטטוס מוצלח ואפשר להתעלם ממנו.
62001 הדמון Streamsnapd הופעל בהצלחה זהו אירוע פנימי ואפשר להתעלם ממנו.
90003 יש עדכון חדש (גרסה X) למכשיר הגיבוי יש עדכון חדש. עדכנו את מכשירי הגיבוי או השחזור בהקדם האפשרי.
90004 עדכון חדש מתוזמן להתקנה אוטומטית במכשיר הגיבוי לא נדרשת פעולה כי זו הודעה אינפורמטיבית על כך שעדכון חדש מתוזמן להתקנה אוטומטית במכשיר הגיבוי. לא נדרשת הפעלה מחדש בשביל העדכון הזה.

המאמרים הבאים