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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התהליכים הנוכחיים שידועים ל-Microsoft מפורטים במאמר Allocated filter altitudes.

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

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

תפוקת קלט/פלט נמוכה מדיסקים של המארחים או מאמצעי התעבורה, iSCSI או FC. מוודאים שאין בעיות קלט/פלט בדיסקים של המארח או באמצעי ההעברה. אמצעי התעבורה יהיה iSCSI או Fibre Channel, בהתאם להגדרת ה-OOB. אם צריך, מתייעצים עם מנהלי האחסון והרשת.
‫5131 – שגיאה 3041 בדוח של יומני SQL גיבויים של יומני SQL במכונה נכשלים עם שגיאה 5131 כדי לפתור את הבעיה, צריך להפעיל את ההגדרה Don't forcefully unload the user registry at user logoff (אל תבטל את הטעינה של רישום המשתמשים בכוח כשמשתמש מתנתק). מידע נוסף זמין במאמר פונקציונליות של שירות פרופיל המשתמש.
‫5131 – יומני SQL מציגים שגיאה 43901 במכשירי גיבוי או שחזור משימות של תמונת מצב נכשלות עם שגיאה 5131, ביומני SQL מופיע גיבוי/ שחזור של "משימת תמונת מצב שנכשלה" שגיאה 43901 הסיבה לכך היא שהכניסה למסד הנתונים באמצעות ODBC נכשלה. פתרון הבעיה בהתחברות ל-ODBC פותר את הבעיה.
5136 ‫Actifio Connector: אי אפשר לקרוא את עוצמת הקול של האחסון הזמני כדי לקבל פרטים, בודקים את הקובץ ‎ /act/logs/UDSAgent.log ופונים לתמיכה של Google כדי לפתור את הבעיה.
5241 Actifio Connector: Failed to mount/clone applications from mapped image (Source File) שם המשתמש והסיסמה שמועברים מקובץ הבקרה לא תקינים. במקור, בודקים את הקובץ UDSAgent.log כדי לראות אם המקור מוגדר עם שם המשתמש והסיסמה הנכונים בקטע Advanced Settings (הגדרות מתקדמות) במאפייני המחבר.
5547 ‫Oracle: הגיבוי של קובץ הארכיון נכשל (קובץ מקור) הגיבוי של יומן הארכיון נכשל ב-Actifio Connector באמצעות פקודות גיבוי של ארכיון RMAN. הסיבות האפשריות לכשל הזה הן:

  • המחבר לא הצליח ליצור חיבור למסד הנתונים
  • יומני הארכיון נמחקו על ידי אפליקציה אחרת
  • שם שירות 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 המאגר של תמונות המצב חצה את סף רמת האזהרה כדי לצמצם את הצריכה של מאגר התמונות:

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

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

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

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

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

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

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

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

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

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

  1. מפעילים מחדש את שירות הסוכן UDSAgent Backup and DR במארח שצוין.
  2. Telnet to tcp port 5106 (UDSAgent communication port): 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, והוא נגרם בגלל קובצי דלתא שנשארו במאגר הנתונים של המכונה הווירטואלית. בדרך כלל, קובצי הדלתא מוסרים אחרי שמאחדים את תמונת המצב של 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 של המכונה הווירטואלית ולמחוק אותו.
  • בודקים אם אפשר לשחזר את קובץ ה-VMDK מתמונת גיבוי.
43873 השימוש במקום בכונן ב-datastore גדל מעבר לסף הקריטי הבעיה הזו מתרחשת כשהמקום שנותר במאגר הנתונים קטן מהסף הקריטי. אם לא יתפנה בקרוב נפח אחסון נוסף, המשימות יתחילו להיכשל כשהמקום שנותר לא יספיק לאחסון שלהן.

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

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

  • לא צוין שם של מאגר למאגר OnVault.
  • פרטי הכניסה לא תקינים – מזהה הגישה או מפתח הגישה לא צוינו או שהמזהה שגוי עבור מאגר OnVault.
  • מאגר לא תקין במאגר OnVault.
  • בעיות כלליות באימות עבור מאגר OnVault.
  • שרת ה-DNS באשכולות /etc/resolv.conf שונה או שקובצי האזורים של ה-DNS להעברה וה-DNS ההפוך השתנו.
43929 יצירת ה-snapshot של ה-VM נכשלה. שגיאה: משימת המכונה הווירטואלית נכשלה. קרתה שגיאה בשמירת התמונה: לא הייתה אפשרות להשבית את המכונה הווירטואלית. צילום מצב של מכונה וירטואלית נכשל אם שרת ESX לא מצליח להעביר את המכונה הווירטואלית למצב השהיה – בגלל יותר מדי קלט/פלט או בגלל שכלי VMware לא מצליחים להעביר את האפליקציה למצב השהיה באמצעות VSS בזמן. בודקים את יומני האירועים במארח ואת יומן ה-ESX של המכונה הווירטואלית (vmware.log). התנהגות כזו מתרחשת לעיתים רחוקות יותר בצילום מצב עקבי לקריסה ובגיבויים שמבוססים על מחברים. מידע נוסף זמין במאמרים במאגר הידע של VMware‏: 1018194 ו-1007696.
43933 לא נמצאה מכונה וירטואלית עם BIOS UUID תואם הבעיה הזו מתרחשת אם ה-UUID של ה-VM משתנה. כדי לפתור את הבעיה, צריך לגלות מחדש את ה-VM ולבדוק אם הוא זוהה כמזהה UUID חדש. כדי לוודא זאת, משווים במסוף ניהול המכשיר את ה-UUID של המכונה הווירטואלית החדשה ל-UUID של המכונה הווירטואלית הקודמת. אם מספרי ה-UUID לא זהים, יכול להיות שהמכונה הווירטואלית שוכפלה. יכול להיות שהשגיאה הזו תוצג גם אם מספר גדול של מכונות וירטואליות מנוהלות של Backup and DR יוסרו מ-vCenter.
43948 מספר התמונות שלא פג תוקפן וממתינות לעיבוד נוסף הוא (x) תמונות ((x) תמונות מצב, (x) תמונות בכספת) מ-(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 נמצאו מסדי נתונים שהיו אופליין ולא ניתן היה לגבות אותם. המצב הזה קורה בדרך כלל כשמסד הנתונים נמחק בצד השרת, אבל עדיין נכלל בצד הגיבוי או ההתאוששות מאסון. הודעת השגיאה מכילה את השמות של מסדי הנתונים במצב אופליין שצריך לבדוק.
43972 העלאת המטא-נתונים לדלי נכשלה. הכתיבה של מטא-נתונים לקטגוריית OnVault נכשלה. דוגמאות לבעיות אפשריות: לחשבון השירות שבו נעשה שימוש יש תפקיד שגוי. לחשבון השירות אין הרשאה לכתוב לקטגוריה. הקטגוריה של Cloud Storage כבר לא קיימת.
43973 ‫udppm started Successfully זהו אירוע פנימי ואפשר להתעלם ממנו.
43999 אזהרה: המכונה הווירטואלית פועלת במארח שפועלת בו גרסה מיושנת של ESXi , שלא נתמכת על ידי Google. כדי לקבל את התוצאות הטובות ביותר, מומלץ לשדרג לגרסה נתמכת (‎>=‎). כדי לקבל את התוצאות הכי טובות, כדאי לשדרג את המכונה הווירטואלית לגרסה נתמכת (‎>=‎).
44003 האימות הושלם בהצלחה Job_xx-xx-xx עבור האפליקציה application ID במארח host, sltname: template, slpname: profile. זהו אירוע סטטוס מוצלח ואפשר להתעלם ממנו.
62001 הדמון Streamsnapd הופעל בהצלחה זהו אירוע פנימי ואפשר להתעלם ממנו.
90003 יש עדכון חדש (גרסה X) למכשיר הגיבוי יש עדכון חדש. חשוב לעדכן את המכשירים לגיבוי ולשחזור בהקדם האפשרי.
90004 עדכון חדש מתוזמן להתקנה אוטומטית ב-Backup Appliance לא נדרשת פעולה כי זהו הודעה אינפורמטיבית על כך שעדכון חדש מתוזמן להתקנה אוטומטית ב-Backup Appliance. העדכון הזה לא דורש הפעלה מחדש.

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