גיבוי של מופעים ומסדי נתונים של Microsoft SQL Server לגיבוי שמנוהל על ידי מכשיר

בעזרת Backup and DR אתם יכולים לגבות את Microsoft SQL Server:

  • מכונות

  • מסד נתונים ראשי של קבוצת זמינות Always On

  • מסדי נתונים במכונות וירטואליות

  • מסדי נתונים של המערכת

  • מסדי נתונים של משתמשים

  • מסדי נתונים וקובצי תמיכה בקבוצת אפליקציות עקביות

  • חברים נפרדים בקבוצת אפליקציות עקביות

לפני שמתחילים

לפני שמגנים על מסדי נתונים של Microsoft SQL Server:

שיטות מומלצות להגנה על מסדי נתונים של Microsoft SQL Server

במסדי נתונים של Microsoft SQL Server שמשתמשים במודל השחזור המלא, כדאי לנצל את היכולת של מכשיר הגיבוי/השחזור לגבות גם את מסד הנתונים וגם את היומנים שלו באמצעות מדיניות אחת. כשהמכשיר מגבה גם את מסד הנתונים וגם את היומנים שלו, הוא יכול לשחזר את מסד הנתונים לנקודת זמן מסוימת על ידי הרצת היומנים קדימה באמצעות ממשק המשתמש של המכשיר. כדי לגבות גם את מסד הנתונים וגם את היומנים שלו, צריך להפעיל את ההגדרות המתקדמות של תבנית המדיניות.

גיבוי מסדי נתונים במכונה לעומת קבוצת אפליקציות עקביות

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

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

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

ניהול מסדי נתונים לעומת ניהול מכונות וירטואליות

שרתי Microsoft SQL מוגנים באופן שונה אם הם מוגנים כאפליקציה (מסד נתונים, מכונה או קבוצת זמינות) או כחלק ממכונה וירטואלית שלמה.

מוגן כאפליקציה, לא כ-ESP הגנה כחלק ממכונה וירטואלית (VM)
מכשירי גיבוי/שחזור מגנים רק על קובצי מסד הנתונים. מכונות וירטואליות שלמות של VMware מגובות באמצעות ממשקי API של VMware. אם אתם מנהלים מסדי נתונים של SQL שהם חלק ממכונה וירטואלית מוגנת, קראו את המאמר הגנה ושחזור של מכונות Compute Engine.
סוכן Backup and DR מתאם את קובץ ה-snapshot של VSS ומבצע חיתוך של היומן. ‫VMware API מתאם את קובץ ה-snapshot של VSS. כדי לקטוע את היומן, צריך להתקין את סוכן Backup and DR ב-VM.
סוכן Backup and DR משתמש במעקב אחר שינויים בבלוקים בקבצים בעלי שם – יעיל מאוד לקובצי מסד נתונים גדולים. ה-API של VMware מספק מעקב אחר שינויים בבלוקים.
יומני העסקאות מגובים כשמשימת הגיבוי פועלת, אם בוחרים באפשרות Truncate Log After Backup בקטע Details & Settings (ראו [הגדרת הגדרות מתקדמות לשינוי הגדרות המדיניות](: #SetOverrides) יומני העסקאות לא מגובים.
הלקוח יכול להריץ קדימה עם יומנים. אי אפשר להריץ קדימה במהלך שחזור.

כדי להחיל תוכנית גיבוי להגנה על מסד נתונים של שרת Microsoft SQL, פועלים לפי ההוראות הבאות.

  1. במסוף הניהול של מכשיר Backup and DR, עוברים אל App Manager ‏> Applications. הדף Applications ייפתח.

  2. בוחרים את מסד הנתונים, המכונה, קבוצת הזמינות או קבוצת האפליקציות העקביות של Microsoft SQL Server שרוצים לגבות, ובפינה הימנית התחתונה של הדף לוחצים על Manage Backup Plan.

  3. בחלון Manage Backup Plan, בוחרים Template ו-Profile מהרשימות הנפתחות:

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

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

  4. בחלון Manage Backup Plan Template, מבצעים את השינויים הבאים לפני שמחילים תוכנית גיבוי:

    • הגדרות האפליקציה. הגדרות ספציפיות ל-Microsoft SQL, כמו סוג האפליקציה, שם המארח, כתובת ה-IP של המארח, הנתיב, מערכת ההפעלה, מכשיר הגיבוי/השחזור וכתובת ה-IP של המכשיר.

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

  5. כדי לבחור מסדי נתונים, בקטע Database Inclusion Rule לוחצים על Edit. תיפתח תיבת הדו-שיח ניהול המינוי.

    • בתיבת הדו-שיח Manage Membership, בוחרים את מסדי הנתונים שרוצים לגבות על ידי הקצאת כלל הכללה (All,‏ System Databases,‏ User Databases), ואז בוחרים אם הכלל צריך להיות Include Selected או Exclude Selected.

    • לוחצים על שמירה ותיבת הדו-שיח ניהול המינוי נסגרת.

  6. לוחצים על Apply כדי להחיל את התבנית לגיבוי נתונים ואת פרופיל המשאבים. מופיעה תיבת הודעה על הצלחה.

    בפעם הראשונה שמסד הנתונים שנבחר מתגלה, משימה על פי דרישה פועלת בהקדם האפשרי כדי להגן על הנתונים. לאחר מכן, נתונים חדשים מגובים כשהמשימה המתוזמנת פועלת בהתאם לשעות הפעילות שמוגדרות בתבנית לגיבוי נתונים. לדוגמה, אם בשעה 10:00 (UTC) אתם מקצים תבנית ששעות הפעילות שלה הן מ-02:00 עד 05:00 (UTC), המשימה הראשונה לא תתחיל עד שלמכשיר תהיה משבצת פנויה למשימה אחרי השעה 02:00 (UTC).

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

הגנה על יומן מסד הנתונים במדיניות של תוכנית גיבוי

כשיוצרים מדיניות של קובצי snapshot למסד נתונים, אפשר גם לגבות את קובצי היומן שלו. תדירות הגיבוי של יומני מסד הנתונים מוגדרת בנפרד מתדירות הגיבוי של מסד הנתונים. לדוגמה, אפשר לגבות מסד נתונים כל יום ואת היומנים שלו כל שעה. תדירות הגיבוי של יומן מסד הנתונים מוגדרת בדקות, והתדירות שבה היומנים מגובים לא יכולה להיות גבוהה יותר מהתדירות שבה מסד הנתונים המשויך מגובה. לדוגמה, אם מסד נתונים מגובה כל 24 שעות, תדירות הגיבוי של קובץ היומן צריכה להיות פחות מכל 24 שעות.

התדירות והשמירה מוגדרות בקטע Details & Settings של המדיניות ליצירת תמונות מצב של מסד הנתונים. גיבוי היומן מתבצע בלי קשר למועד הגיבוי של מסד הנתונים המשויך אליו.

מפעילים את Log Protection דרך ההגדרות המתקדמות של Enable Database Log Backup במדיניות של תמונת המצב של תוכנית הגיבוי. התדירות והשמירה מוגדרות בקטע Details & Settings של מדיניות תוכנית הגיבוי.

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

  • תקופת השמירה של גיבוי היומן. משך שמירת היומנים מוגדר בנפרד ממשך השמירה של מדיניות תמונת המצב. תקופת שמירה נפרדת מאפשרת להשתמש ביומנים בשילוב עם עותקים של מסד הנתונים שמאוחסנים במאגר Snapshot, ואם רוצים גם במאגר OnVault. תקופת השמירה של היומנים היא חובה כשגיבוי היומנים מופעל.

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

  • Log Staging Disk Size Growth Size. מגדיר את האחוז שבו דיסק ה-staging שבו נמצאים היומנים יגדל באופן אוטומטי. ההגדרה הזו היא אחוז, והערכים התקינים הם בין 5 ל-100.

  • שיעור השינוי המשוער. מגדירה את השינוי היומי (באחוזים), שמאפשר למכשיר הגיבוי/השחזור לחשב טוב יותר את גודל דיסק ה-staging שנדרש כדי להכיל את היומנים. ההגדרה הזו היא אחוז, והערכים התקינים הם בין 0 ל-100.

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

קביעת הגדרות מתקדמות לשינוי הגדרות המדיניות

לוחצים על Policy Overrides בחלון Manage Backup Plan כדי להציג את תיבת הדו-שיח Policy Settings Override. כאן אפשר לשנות הגדרות מדיניות ספציפיות שמשויכות לתבנית לגיבוי נתונים שנבחרה. כשמסיימים, לוחצים על שמירת השינויים.

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

ברשימה הבאה מפורטים התיאורים של ההגדרות החלופיות של המדיניות, שתקפות למכונות של SQL Server, לקבוצות זמינות (AG), למסדי נתונים ולקבוצות של אפליקציות עקביות.

  • אל תבטלו את המיפוי. Keep staging disks mapped between jobs: בוחרים באפשרות הזו אם רוצים שדיסקים זמניים של אזורי ביניים שממופים למארח, ומשמשים במהלך העברת הנתונים, יישארו ממופים למארח. מספרי ה-LUN ממופים במהלך המשימה הראשונה, ובכל המשימות הבאות נעשה שימוש חוזר באותו LUN ממופה. האפשרות הזו מסומנת כברירת מחדל. ביטול המיפוי של דיסקים זמניים אחרי כל משימה: האפשרות הזו גם מבטלת את הטעינה של הדיסק הזמני ממערכת ההפעלה בסיום כל משימה (הסרת נקודות טעינה או אותיות כונן), וגם מבטלת את המיפוי שלו מהמארח לגמרי. כדי להשתמש באפשרות הזו, המארח צריך לבצע סריקה של מספרי LUN של SCSI בתחילת המשימה הבאה, כי צריך לגלות מחדש את הדיסקים של אזור ה-Staging שמופו מחדש לפני שאפשר יהיה לטעון אותם מחדש.

  • Truncate Log After Backup (חיתוך היומן אחרי הגיבוי). מציינים אם לקצר את היומנים אחרי כל גיבוי. כשהאפשרות הזו מופעלת, יומנים שקשורים לאפליקציה נחתכים עד לגיבוי האחרון או הנוכחי. אם אתם חותכים את היומנים, אתם צריכים גם לגבות את יומן הטרנזקציות כדי לאפשר שחזור של roll forward.

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

    האפשרויות הן:

    • הגיבוי נכשל כשנמצאות אפליקציות אופליין
    • דילוג על אפליקציות אופליין במהלך הגיבוי

  • מיפוי דיסקים זמניים לכל מארחי ה-ESX באשכול. (האפשרות הזו לא רלוונטית כשמשתמשים במאגרי נתונים של NFS). מיפוי דיסק ה-staging למארח ESX ל-VM בלבד. ממפים את דיסק ה-staging לכל מארחי ה-ESX באשכול. ממפים את דיסק ה-staging לשני מארחי ESX באשכול.

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

  • הפעלת גיבוי של יומן מסד הנתונים האפשרות Enable Database Log Backup מאפשרת למדיניות של תוכנית הגיבוי לגבות מסד נתונים של Oracle או של Microsoft SQL Server, ואת כל קובצי יומן העסקאות שמשויכים אליו. היומנים מגובים כשמשימת ה-snapshot של היומנים פועלת. האפשרויות הן כן או לא. כשמגדירים את האפשרות כן, האפשרויות הקשורות מופעלות.

  • RPO. כשהאפשרות Enable Database Log Backup מוגדרת ל-Yes, ה-RPO מגדיר את התדירות של גיבוי יומן מסד הנתונים. התדירות מוגדרת בדקות, והיא לא יכולה להיות גדולה יותר מהמרווח בין הגיבויים של מסד הנתונים. הערך הקטן ביותר שאפשר להגדיר (בדקות) הוא 15.

  • תקופת השמירה של גיבוי היומן. כשהאפשרות Enable Database Log Backup מוגדרת כ-Yes, שמירת היומן מוגדרת בנפרד משמירת המדיניות של תמונת המצב. תקופת שמירה נפרדת מאפשרת להשתמש ביומנים בשילוב עם עותקים של מסד הנתונים שמאוחסנים במאגר תמונות המצב. תקופת השמירה של היומן היא הגדרת חובה.

  • שכפול יומנים. (משתמש בטכנולוגיית StreamSnap) כשההגדרה Enable Database Log Backup מוגדרת ל-Enable, ההגדרה המתקדמת Replicate Logs מאפשרת לשכפל את יומני הטרנזקציות של מסד הנתונים של Microsoft SQL Server למכשיר גיבוי/שחזור מרוחק. כדי להריץ משימת שכפול של יומן, צריך שתהיה בתבנית מדיניות שכפול של StreamSnap, יחד עם פרופיל משאבים שמציין מכשיר גיבוי/שחזור מרוחק, וצריך להשלים לפחות שכפול מוצלח אחד של מסד הנתונים. לאחר מכן, תוכלו להשתמש ביומנים באתר המרוחק לכל תמונת מסד נתונים בטווח השמירה של היומנים המשוכפלים. הפונקציה הזו מופעלת כברירת מחדל.

    שכפול היומנים משתמש בטכנולוגיית StreamSnap כדי לבצע את השכפול בין מכשירי הגיבוי/השחזור המקומיים והמרוחקים. שכפול היומנים עובר ישירות ממאגר קובצי ה-snapshot המקומי למאגר קובצי ה-snapshot במכשיר המרוחק.

  • שליחת יומנים למאגר OnVault. כשהאפשרות Enable Database Log Backup מוגדרת כ-Enable, ההגדרה הזו מאפשרת לשכפל את יומני העסקאות של מסד הנתונים של Microsoft SQL Server למאגר OnVault. כדי להריץ משימה של שכפול יומנים, צריך לכלול בתבנית מדיניות OnVault, יחד עם פרופיל משאבים שמציין מאגר OnVault, ולשלוח קודם לפחות מסד נתונים אחד למאגר. לאחר מכן תוכלו להשתמש ביומנים באתר המרוחק לכל קובץ אימג' של מסד נתונים בטווח השמירה. הפונקציה הזו מופעלת כברירת מחדל.

  • Log Staging Disk Growth Size. כשהאפשרות Enable Database Log Backup מוגדרת כ-Yes, הערך של Log Staging Disk Growth Size מגדיר את קצב הגידול של דיסק ה-staging שבו נמצאים היומנים. ההגדרה הזו היא בין 5% ל-100%.

  • שיעור השינוי המשוער. כשההגדרה Enable Database Log Backup מוגדרת כ-Yes, ההגדרה הזו קובעת את השינוי היומי (באחוזים), שמאפשר למכשיר הגיבוי/השחזור לחשב טוב יותר את גודל דיסק ה-staging שנדרש כדי להכיל את היומנים. ההגדרה הזו היא בין 0 ל-100.

  • דחיסת הגיבוי של יומן מסד הנתונים. כשההגדרה Enable Database Log Backup מוגדרת ל-Yes, היא מורה למסד הנתונים של המקור לדחוס את היומנים שלו לפני שהם מגובים על ידי מסוף הניהול של המכשיר. שרת מסד הנתונים מבצע דחיסה של היומן במהלך הגיבוי שלו. האפשרויות הן Yes או No. כשמגדירים את האפשרות Yes, האפשרות Compress Database Log Backup מופעלת.

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

    • Script Init Timeout. המדיניות הזו מגדירה כמה זמן צריך לחכות לפני שמניחים שהסקריפטים מצד המארח במארח מנוהל אותחלו. ערך ברירת המחדל הוא 120 שניות, והטווח המותר הוא בין שנייה אחת ל-86,400 שניות (24 שעות).
    • זמן קצוב לתפוגה של הקפאת סקריפט. ההגדרה הזו קובעת כמה זמן המדיניות צריכה להמתין לפני שהיא מניחה שהאפליקציה הוקפאה ומוכנה לגיבוי נתונים. ערך ברירת המחדל הוא 60 שניות, והטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    • זמן קצוב לביטול הקפאת הסקריפט. המדיניות הזו קובעת כמה זמן צריך לחכות לפני שהמערכת מניחה שהאפליקציה כבר לא במצב הקפאה. ערך ברירת המחדל הוא 60 שניות, והטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    • הזמן הקצוב לתפוגה של סיום הסקריפט. המדיניות הזו מגדירה כמה זמן המערכת צריכה להמתין עד שגיבוי הנתונים יושלם. ערך ברירת המחדל הוא 60 שניות, והטווח המותר הוא בין שנייה אחת ל-86,400 שניות.
    • Script Post Replication Timeout. מגדירה כמה זמן המדיניות צריכה להמתין עד להשלמת השכפול. ערך ברירת המחדל הוא 60 שניות, והטווח המותר הוא בין שנייה אחת ל-86,400 שניות.

מדריך Backup and DR למנהלי מסדי נתונים של Microsoft SQL Server

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