הסיבות לגיבויים עם נתונים חלקיים במכשירים לגיבוי או לשחזור

מהו גיבוי עם מעט אפקטים?

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

גיבוי עם התזה חלשה הוא סוג מיוחד של משימת גיבוי שמתרחשת כששגיאת מערכת מסוימת במשימת הגיבוי הקודמת גורמת לתמונת מפת סיביות לא אמינה או לחוסר יכולת לקרוא את מפת הסיביות. השירות שקורא את מפת הביטים הוא cbt_server בסביבת Linux ו-AAMService בסביבת Windows.

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

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

  • שדרוגים של מחברים
  • אתחול בלי הפרעה של המערכת
  • הפעלה מחדש של cbt_server או AAMService בהנחה שהשירות עדיין פועל בזמן הגיבוי
  • מעברים אוטומטיים לשירות גיבוי שלא נתקלו בשגיאות שגורמות למפות סיביות לא אמינות.

הגורמים לביטמפים לא אמינים

מפת סיביות לא אמינה נוצרת כשמשהו משבש את עבודת הגיבוי, כולל:

  • כיבוי לא תקין של המארח:
    • כיבוי לא תקין גורם להצגת מסך פתיחה קצר בגלל חוסר אמינות של מפות סיביות. זה כולל ניתוק של מכונה פיזית מהחשמל או כל שיטה אחרת לכיבוי Windows בלי לבצע כיבוי תקין, או שגיאה של מסך כחול. זה נכון גם אם מכונה אחת באשכול נתקלת בשגיאה של מסך כחול שגורמת למעבר לגיבוי, כי מפת הסיביות מהמכונה שנכשלה לא אמינה.
    • אם כל שרתי Windows באשכול שאירחו את מסד הנתונים מאז הגיבוי הקודם לא זמינים ולא מריצים את הסוכן של Backup and DR. אנחנו שולפים מפות סיביות מכל מארח של אשכול שאירח את מסד הנתונים מאז הגיבוי הקודם כדי למצוא שינויים. בלי כל מפות הסיביות, אנחנו צריכים להפעיל low-splash כדי לשמור על תקינות נתונים. הערה: אם מארח של אשכול שאירח מסד נתונים נתקל במסך כחול, יכול להיות שהמפת סיביות תהיה זמינה בגיבוי, אבל עדיין לא אמינה, ולכן נדרש שחזור עם נתונים חלקיים.
  • עדכון כושל של מודול ליבה
  • קריסה או הפעלה מחדש של דמון במצב משתמש
  • שגיאה בטביעת האצבע במהלך הפעלת הגיבוי. ‫(Backup and DR מבצע 'בדיקת טביעת אצבע' בכל משימת גיבוי כדי לבדוק אם יש שגיאות).
  • שגיאה במהלך העברת הנתונים ל-Vault, אם במהלך כיבוי מערכת ההפעלה דיסק האחסון מלא והמערכת לא יכולה לכתוב את כל הנתונים ב-Vault.
  • מעבר אוטומטי לשרת גיבוי של צומת SAP HANA, שגורם להפניה אוטומטית של הגיבוי לצומת אחר.
  • הגיבוי פועל במצב מוגבל בגלל שלא ניתן לטעון את מודול הליבה. בדרך כלל זה קורה אם מערכת ההפעלה היא גרסה לא נתמכת.
  • אם השירות cbt_server או AAMService מופסק במהלך הגיבוי, אי אפשר לאחזר מפות סיביות ועבודת הגיבוי מופעלת במצב low-splash. אם AAMService לא מושבת למשך זמן רב מדי, הפעלת AAMService תגרום לכך שמפות סיביות יהיו זמינות לגיבוי רגיל.
    • אם cbt_server או AAMService מופסקים למשך זמן מספיק ארוך כדי שייווצר תור של כמה גיגה-בייט של אירועים על ידי מנהל ההתקן, אי אפשר יהיה ליצור מחדש את מפות הביטים והגיבוי יהיה במצב low-splash. משך הזמן שנדרש לכך תלוי בכמות הקלט/פלט בדיסק שמתבצעת במסד הנתונים. בדרך כלל נדרשים ימים של השבתה של AAMService.
  • כיבוי לא תקין של cbt_server או AAMService עלול לגרום לכך שמפות סיביות לא יהיו אמינות עבור מפות סיביות שנטענו כרגע. מפות סיביות נטענות אם בוצעו כתיבות לקובץ המעקב ב-15 הדקות האחרונות, כך שבדרך כלל במסד נתונים פעיל זה יגרום לטעינה מהירה.
  • אם אמצעי אחסון שמכיל קובץ במעקב (למשל קובץ ‎.mdf של SQL Server) מבוטל ב-host ואז מופעל מחדש, אי אפשר להסתמך על מפות הביטים כי אין דרך לדעת מה נכתב בקובץ בזמן שהוא היה מושבת.