‫Backup and DR ל-Microsoft SQL Server במכשיר לגיבוי או לשחזור

תיעוד נתונים של SQL Server

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

  • מכונות

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

  • קבוצות של מסדי נתונים עקביים

  • מסדי נתונים נפרדים

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

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

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

השירות "Backup and DR" מעביר ומנהל את הנתונים של Microsoft SQL Server בנפרד מהמקום שבו Microsoft SQL Server כותב את האחסון הראשי שלו.

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

הכנה לגיבוי של נתוני Microsoft SQL Server

ההכנה לגיבוי נתונים של Microsoft SQL Server כוללת ארבעה שלבים:

  1. מוסיפים שרתים שמארחים מסדי נתונים של Microsoft SQL Server.

  2. לזהות מכונות וירטואליות ומסדי נתונים של Microsoft SQL Server.

  3. הגדירו תבניות מדיניות ופרופילי משאבים של Backup and DR בהתאם ל-RPO ול-RTO שלכם.

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

  4. להקצות תבניות מדיניות ופרופילי משאבים של Backup and DR למסדי נתונים של Microsoft SQL Server.

תיעוד נתונים

כשמתעדים נתונים, חשוב לשים לב לדברים הבאים:

  • דיסק זמני נוצר באופן אוטומטי ומותקן בשרת.

  • עותק מלא ראשוני נוצר בדיסק ה-staging. העותקים הבאים מכילים רק בלוקים שהשתנו.

  • הדיסק הזמני מנותק מהשרת.

  • נוצר קובץ snapshot של דיסק ה-staging במכשיר הגיבוי/השחזור.

תיעוד יומנים של מסדי נתונים ב-SQL Server

הגדרת תיעוד היומן של מסד הנתונים נמצאת בקטע Details & Settings של מדיניות תמונת המצב. היא מאפשרת למדיניות אחת של תמונת מצב לתעד יומנים של מסדי נתונים של Microsoft SQL Server וקבוצות של אפליקציות עקביות שמכילות מסדי נתונים של Microsoft SQL Server.

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

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

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

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

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

שינוי הגודל של דיסק ה-staging של יומן מסד הנתונים

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

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

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

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

  • Estimated Change Rate: השינוי היומי (באחוזים), שמאפשר למכשיר הגיבוי/השחזור לחשב בצורה טובה יותר את הגודל של דיסק ה-staging שנדרש כדי להכיל את היומנים.

  • ‫Compress Database Log Backup: הנחיה למסד הנתונים של המקור לדחוס את היומנים שלו לפני שהם נשמרים במכשיר הגיבוי/השחזור. שרת מסד הנתונים מבצע דחיסת יומנים במהלך גיבוי היומנים (ברירת המחדל היא Enabled).

אפשרויות לתיעוד נתונים ב-SQL Server

בקטעים הבאים מפורטות האפשרויות לתיעוד נתונים ב-SQL Server.

תיעוד של מופעים, מסדי נתונים ספציפיים וקבוצות של מסדי נתונים

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

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

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

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

תיעוד של קבוצות אפליקציות עקביות

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

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

קבוצת אפליקציות עקביות יכולה להיות מורכבת מהפריטים הבאים:

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

  • מסד נתונים אחד או יותר של משתמשים

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

  • אפס מערכות קבצים או יותר (אותיות כונן או נקודות טעינה)

אפשר לגשת לאפליקציות ספציפיות בקבוצת אפליקציות עקביות באמצעות פעולות טעינה, שכפול, LiveClone ושחזור.

צריך לגלות מסדי נתונים במופע של יתירות כשל באשכול מהצומת הפעיל. אחרי ההגנה, GO עוקב אחרי צומת ה-SQL הפעיל באשכול. משימות ההגנה ממשיכות לפעול גם במצב של יתירות כשל. בנוסף לביצוע מהיר של פעולות תיעוד וגישה, קבוצות של אפליקציות עקביות צורכות פחות משאבי מערכת (VDisks) מאשר הגנה על מסדי נתונים בנפרד.

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

תיעוד מסדי הנתונים ונפח האתחול של VM

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

שכפול נתונים של SQL Server

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

  • מפחית את השימוש הכולל ברשת.

  • מבטל את הצורך במאיץ או בכלי אופטימיזציה ייעודיים של WAN.

  • הצפנת נתונים באמצעות תקן ההצפנה AES-256. האימות בין מכשירי הגיבוי/השחזור מתבצע באמצעות אישורים של 1,024 ביט.

הרפליקציה נשלטת על ידי כללי המדיניות של תבנית המדיניות של Backup and DR:

  • בכללי המדיניות של Production to Mirror יש כמה אפשרויות לשכפול נתונים למכשיר גיבוי/שחזור שני.

  • בכללי המדיניות Production to OnVault נעשה שימוש במנוע קנייני של Backup and DR כדי להעביר נתונים למאגר אובייקטים.

שכפול יומנים

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

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

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

גישה לנתוני SQL Server

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

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

לא משנה באיזה מודל שחזור של Microsoft SQL Server משתמשים, אפשר לגשת לנתונים של Microsoft SQL Server באמצעות ממשק iSCSI. אם אתם משתמשים ב-VMware‏ (GCVE), אפשר לגשת לנתונים גם באמצעות מאגר נתונים של NFS שמוצג למארח ESXi.

בקרת גישה המבוססת על תפקידים (RBAC)

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

תושבות

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

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

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

LiveClones

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

קלונס

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

שחזורים

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

כדי לשחזר מסד נתונים ואז להחיל יומנים, מסד הנתונים המשוחזר צריך להיות במצב שחזור. אפשר לשחזר את מסד הנתונים ב-Restoring Mode ואז להריץ את היומנים קדימה לנקודת זמן ספציפית. אם משחזרים את מסד הנתונים בלי לציין את האפשרות Restore with no Recovery, מסד הנתונים ישוחזר ויועבר למצב אונליין בלי להחיל יומנים. במאמר שחזור מסדי נתונים של SQL Server מוסבר איך משחזרים. כדי לשחזר עם זמן השבתה כמעט אפסי, קודם צריך לטעון את הנתונים כמו שמוסבר במאמר טעינה והעברה של נתוני SQL.

תהליכי עבודה לאוטומציה של הגישה לנתונים ב-SQL Server

תהליכי עבודה מאפשרים גישה אוטומטית לנתונים שנאספו מ-Microsoft SQL Server. תהליכי עבודה יכולים להציג נתונים כטעינה ישירה או כ-LiveClone:

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

  • ‫LiveClone הוא עותק של נתוני הייצור של Microsoft SQL Server, שאפשר לעדכן באופן ידני או על בסיס מתוזמן. אתם יכולים להסתיר נתונים רגישים ב-LiveClone לפני שאתם מאפשרים למשתמשים לגשת אליהם.

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

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

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

  • הפיכת נתוני Microsoft SQL Server שצולמו לזמינים כ-LiveClone או כטעינה ישירה.

  • עדכון הנתונים של LiveClone או של Microsoft SQL Server שניתן לטעינה, לפי לוח זמנים או על פי דרישה

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

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

איך Backup and DR פועל עם מוצרי גיבוי קיימים

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

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

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

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

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

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

מסמכי תיעוד אחרים של Backup and DR ל-Microsoft SQL Server

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

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

הכנת מסדי נתונים של SQL Server ל-Backup and DR.