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