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

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

מה זה גיבוי עם מעט התזות?

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

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

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

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

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

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

  הערה: גיבויים עם השפעה נמוכה לא מתרחשים במסדי נתונים של Oracle ב-Linux או ב-Windows.

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

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

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