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

תקציר מנהלים

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

תוכנית גיבוי נכונה מבוססת על יעדי RPO ו־RTO, משלבת גיבויים מלאים, דיפרנציאליים
וגיבויי Transaction Log,
מגינה על העותקים באמצעות הצפנה והרשאות מצומצמות, ושומרת לפחות עותק אחד
מחוץ לסביבת הייצור.

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

מדוע גיבוי SQL Server הוא צורך עסקי ולא רק משימה טכנית?

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

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

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

1. איזה מידע יש לגבות?

2. באיזו תדירות יש ליצור גיבוי?

3. היכן יישמרו העותקים?

4. כיצד הם יהיו מוגנים?

5. כיצד מוכיחים שניתן לשחזר אותם בזמן הנדרש?

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

מהו גיבוי SQL Server?

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

חשוב להבחין בין שלושה מונחים:

גיבוי
הוא תהליך יצירת העותק.

שחזור
הוא טעינת הנתונים מתוך קובצי הגיבוי.

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

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

הגדירו RPO ו־RTO לפני בחירת
לוח הגיבויים

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

מהו RPO?

RPO, או Recovery Point Objective, מגדיר כמה
מידע הארגון מוכן לאבד במקרה של תקלה.

לדוגמה, אם ה־RPO של מערכת מכירות הוא 15 דקות, מערך הגיבוי צריך לאפשר שחזור
לנקודה שאינה מרוחקת ביותר מ־15 דקות ממועד האירוע. גיבוי מלא שמתבצע פעם
ביום אינו יכול לבדו לעמוד בדרישה זו.

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

מהו RTO?

RTO, או Recovery Time Objective, מגדיר בתוך כמה
זמן יש להחזיר את המערכת לפעילות.

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

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

דוגמה לסיווג מערכות

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

סוגי הגיבויים המרכזיים ב־ Server SQL

גיבוי מלא

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

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

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

גיבוי דיפרנציאלי

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

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

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

גיבוי
Transaction Log

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

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

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

גיבוי Copy-Only

Copy-Only Backup הוא גיבוי
נקודתי שאינו אמור לשבש את רצף הגיבויים הרגיל.

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

Tail-Log
Backup

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

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

גיבוי קבצים
ו־Filegroups

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

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

כיצד לבחור
מודל התאוששות?

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

SQL Server מציע שלושה מודלים
מרכזיים: Simple, Full ו־Bulk-Logged.

Simple Recovery
Model

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

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

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

Full Recovery
Model

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

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

שחזור לנקודת זמן זמין במסדי נתונים המשתמשים
במודל Full, ובתנאים
מסוימים גם במודל Bulk-Logged.

Bulk-Logged
Recovery Model

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

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

דוגמה ללוח
גיבויים ארגוני

למערכת קריטית הפועלת במודל Full ניתן לשקול את המבנה
הבא:

• גיבוי מלא אחת לשבוע.

• גיבוי דיפרנציאלי אחת ליום.

• גיבוי Transaction Log
  בכל 5 עד 15 דקות, בהתאם ל־RPO.

• העתקה של הגיבויים ליעד מרוחק.

• שמירת עותק מוגן מפני שינוי או מחיקה.

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

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

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

היכן כדאי
לשמור את הגיבויים?

אחסון
מקומי

אחסון מקומי יכול לספק שחזור מהיר, במיוחד כאשר מדובר
בתשתית מהירה הקרובה לשרת.

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

אתר
מרוחק

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

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

Azure Blob
Storage

SQL Server תומך בגיבוי ובשחזור
באמצעות URL מול
Azure Blob Storage. גישה זו יכולה
להתאים לסביבות היברידיות, לשמירת עותקים מחוץ לאתר ולשילוב אחסון ענן
בתוכנית ההתאוששות.

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

אחסון אובייקטים
תואם S3

החל מ־SQL Server 2022 קיימת תמיכה בגיבוי ובשחזור ישירות מול אחסון אובייקטים
תואם S3 באמצעות
BACKUP TO URL ו־RESTORE FROM URL. התמיכה אינה זמינה
באותה צורה בגרסאות SQL Server מוקדמות יותר.

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

עותק בלתי ניתן
לשינוי

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

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

כיצד
מאבטחים גיבויי SQL Server?

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

הצפנת גיבויים

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

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

שמירת תעודות
ומפתחות

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

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

TDE וגיבויים

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

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

הרשאות
מצומצמות

יש להגביל את הגישה לתיקיות, ל־Storage Accounts ול־Buckets שבהם נשמרים
הגיבויים.

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

הגנה מפני
כופרה

מערך גיבוי עמיד יותר בפני כופרה כולל:

• עותק מחוץ לסביבת הייצור.

• הרשאות נפרדות ומצומצמות.

• אימות רב־שלבי לחשבונות ניהול.

• שמירה בלתי ניתנת לשינוי כאשר הדבר נתמך
  ומתאים.

• ניטור פעולות מחיקה ושינוי מדיניות.

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

• תיעוד תהליך התאוששות מתקרית סייבר.

דחיסת
גיבויים ושיפור ביצועים

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

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

Microsoft מתעדת את היחס בין
חיסכון במקום לבין השפעת הדחיסה על ביצועים ומשאבי CPU.

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

אוטומציה של
מערך הגיבוי

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

SQL Server Agent
Jobs

באמצעות SQL Server
Agent ניתן ליצור משימות נפרדות עבור גיבויים
מלאים, דיפרנציאליים וגיבויי לוג.

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

Maintenance Plans או
סקריפטים

Maintenance Plans מספקים ממשק
גרפי ונוח יחסית לסביבות פשוטות.

סקריפטים ב־T-SQL או PowerShell מציעים בדרך כלל גמישות גבוהה יותר, ניהול גרסאות, התאמה למספר
שרתים ולוגיקה מורכבת של שמירה וניטור.

הבחירה צריכה להתאים לגודל הסביבה, ליכולות הצוות
ולדרישות הבקרה.

מה צריכה
לכלול התראת גיבוי?

התראה יעילה צריכה לציין:

• שם השרת וה־Instance.

• שם מסד הנתונים.

• סוג הגיבוי שנכשל.

• זמן תחילת המשימה.

• הודעת השגיאה.

• היעד שאליו נכתב הגיבוי.

• מועד הגיבוי התקין האחרון.

• מידת החריגה מה־RPO.

• הפעולה הנדרשת ומי אחראי לביצועה.

כיצד
מוודאים שהגיבוי באמת תקין?

הודעת “Backup completed
successfully” מעידה שפעולת הגיבוי הסתיימה, אך
אינה מוכיחה שכל תהליך ההתאוששות הארגוני יעבוד.

שימוש ב־CHECKSUM

האפשרות WITH CHECKSUM
מבקשת מ־SQL Server לבצע בדיקות נוספות במהלך יצירת הגיבוי וליצור Backup Checksum.

כאשר קיים Checksum, פעולות Restore ו־RESTORE VERIFYONLY יכולות להשתמש בו לצורך איתור שגיאות מסוימות.

שימוש
ב־RESTORE VERIFYONLY

הפקודה RESTORE
VERIFYONLY בודקת שהגיבוי שלם ושהמדיה ניתנת
לקריאה, בלי לשחזר בפועל את מסד הנתונים.

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

ביצוע שחזור
ניסוי

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

לאחר השחזור יש לבצע לפחות את הבדיקות
הבאות:

• מסד הנתונים נפתח בהצלחה.

• שרשרת הגיבויים הייתה מלאה.

• לא הופיעו שגיאות במהלך השחזור.

• בדיקות עקביות הושלמו בהתאם למדיניות.

• המשתמשים וההרשאות תואמים לצורך.

• האפליקציה יכולה להתחבר.

• תהליכים קריטיים פועלים.

• זמן השחזור נמדד ותועד.

• התוצאה עומדת ב־RTO
  וב־RPO.

תהליך שחזור SQL Server שלב אחר שלב

זיהוי נקודת
השחזור

תחילה יש לקבוע מה קרה ומתי.

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

איתור שרשרת
הגיבויים

בדרך כלל יש לאתר:

1. את הגיבוי המלא הרלוונטי.

2. את הגיבוי הדיפרנציאלי האחרון שנוצר אחריו, אם
   קיים.

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

4. Tail-Log Backup, כאשר הוא
   אפשרי ונדרש.

הכנת סביבת
השחזור

לפני התחלת השחזור יש לבדוק:

• גרסת SQL Server ותאימות.

• נפח דיסק פנוי.

• נתיבי קובצי הנתונים והלוג.

• הרשאות לחשבון השירות.

• זמינות מפתחות ותעודות.

• זמינות רוחב פס לגיבוי מרוחק.

• בידוד הסביבה במקרה של אירוע סייבר.

ביצוע
השחזור

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

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

אימות לאחר
השחזור

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

יש לבדוק גם Logins
ברמת השרת, SQL Agent
Jobs, קישורים למערכות חיצוניות, תעודות, הרשאות
ותהליכי אינטגרציה.

דוגמאות T-SQL לגיבוי ושחזור

יצירת גיבוי מלא עם דחיסה ו־Checksum

BACKUP DATABASE [SalesDB]
TO DISK = N'E:\SQLBackups\SalesDB_Full.bak'
WITH
COMPRESSION,
CHECKSUM,
STATS = 10;

האפשרות COMPRESSION
מקטינה בדרך כלל את נפח הגיבוי, ו־CHECKSUM מוסיפה בדיקות תקינות במהלך
הפעולה.

יצירת גיבוי
דיפרנציאלי

BACKUP DATABASE [SalesDB]
TO DISK = N'E:\SQLBackups\SalesDB_Diff.bak'
WITH
DIFFERENTIAL,
COMPRESSION,
CHECKSUM,
STATS = 10;

גיבוי זה מתבסס על הגיבוי המלא האחרון
הרלוונטי.

יצירת
גיבוי Transaction Log

BACKUP LOG [SalesDB]
TO DISK = N'E:\SQLBackups\SalesDB_Log.trn'
WITH
COMPRESSION,
CHECKSUM,
STATS = 10;

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

בדיקת קובץ
גיבוי

RESTORE VERIFYONLY
FROM DISK = N'E:\SQLBackups\SalesDB_Full.bak'
WITH CHECKSUM;

הפקודה אינה מחליפה שחזור מלא לסביבת
בדיקות.

שחזור גיבוי
מלא ודיפרנציאלי

RESTORE DATABASE [SalesDB_RestoreTest]
FROM DISK = N'E:\SQLBackups\SalesDB_Full.bak'
WITH
MOVE N'SalesDB_Data'
TO N'F:\SQLData\SalesDB_RestoreTest.mdf',
MOVE N'SalesDB_Log'
TO N'G:\SQLLogs\SalesDB_RestoreTest.ldf',
NORECOVERY,
CHECKSUM,
STATS = 10;

RESTORE DATABASE [SalesDB_RestoreTest]
FROM DISK = N'E:\SQLBackups\SalesDB_Diff.bak'
WITH
RECOVERY,
CHECKSUM,
STATS = 10;

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

שחזור לנקודת
זמן

RESTORE LOG [SalesDB_RestoreTest]
FROM DISK = N'E:\SQLBackups\SalesDB_Log_20260805_2000.trn'
WITH
STOPAT = '2026-08-05T20:12:00',
RECOVERY,
CHECKSUM,
STATS = 10;

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

אין להריץ דוגמאות אלו ישירות בסביבת ייצור ללא התאמת
שמות, נתיבים, הרשאות, מדיניות שמירה ותהליך בדיקה מאושר.

האם
Always On מחליף
גיבוי?

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

Always On Availability Groups, Failover Cluster
Instances ופתרונות דומים יכולים לצמצם את זמן
ההשבתה במקרה של כשל תשתיתי. הם אינם מספקים בהכרח יכולת לחזור למצב שלפני
מחיקה, שינוי שגוי או פגיעה לוגית.

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

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

גיבוי מסדי
נתונים מערכתיים

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

master מכיל מידע חשוב ברמת
ה־Instance, כגון
Logins והגדרות
מסוימות.

msdb מכיל בין היתר מידע
על SQL Server Agent Jobs והיסטוריית גיבויים.

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

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

מדיניות שמירה
ומחזור חיים

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

על הארגון להביא בחשבון:

• דרישות עסקיות.

• התחייבויות חוזיות.

• מדיניות אבטחת מידע.

• רגולציה החלה על המידע.

• זמני גילוי של טעויות או הונאות.

• עלויות אחסון ושליפה.

• הצורך בשמירת עותקים חודשיים או שנתיים.

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

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

ניטור ומדדי
הצלחה

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

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

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

• מספר מסדי הנתונים שאינם עומדים במדיניות.

• משך הגיבוי הממוצע.

• נפח הגיבויים וקצב הגידול.

• שיעור הצלחת בדיקות השחזור.

• הזמן שנמדד בשחזור האחרון.

• RPO ו־RTO שהושגו בפועל.

• מספר חריגות שלא טופלו בזמן.

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

טעויות
נפוצות בגיבוי SQL Server

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

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

אי־ביצוע בדיקות
שחזור

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

שימוש ב־Full Recovery ללא גיבויי לוג

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

מחיקת חלק משרשרת
הלוג

אובדן של קובץ לוג אחד עשוי למנוע שחזור של כל הנקודות
שאחריו בשרשרת.

הצפנת
גיבויים ללא גיבוי המפתח

ללא התעודה, המפתח הפרטי והסיסמה המתאימה, קובץ גיבוי
תקין עלול להיות בלתי שמיש.

מדיניות זהה לכל
המערכות

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

הסתמכות על High Availability
בלבד

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

התעלמות
מהתלות באפליקציות

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

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

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

• מיפוי כל שרתי SQL
  Server ומסדי הנתונים.

• זיהוי בעלי המערכות ואנשי הקשר.

• סיווג רמת הקריטיות של כל מסד נתונים.

• הגדרת RPO ו־RTO מאושרים.

• בחירת Recovery Model
  מתאים.

• קביעת סוגי הגיבוי והתדירות.

• הגדרת תקופות שמירה.

• בחירת יעדי אחסון מקומיים ומרוחקים.

• הגדרת הצפנה וניהול מפתחות.

• הפרדת הרשאות בין ייצור, גיבוי ואחסון.

• הפעלת CHECKSUM בהתאם למדיניות.

• בניית ניטור והתראות.

• תיעוד Runbook לשחזור.

• גיבוי מסדי הנתונים המערכתיים.

• בדיקת שחזור מלאה בסביבה מבודדת.

• מדידת זמן השחזור בפועל.

• עדכון התוכנית לאחר שינוי תשתית או
  אפליקציה.

סיכום: מערך גיבוי נמדד ביכולת השחזור

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

תוכנית טובה מתחילה בהגדרת RPO ו־RTO, בוחרת את מודל ההתאוששות וסוגי
הגיבוי המתאימים, שומרת עותקים בכמה שכבות ומגינה עליהם מפני גישה בלתי
מורשית, מחיקה וכופרה.

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

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