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

גיבוי SQL Server למערכת ERP, בלי לגלות ביום השחזור שהוא לא עובד

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

בקצרה
גיבוי נכון של SQL Server למערכת ERP נשען על שלושה דברים: מודל שחזור שמתאים לכמה עבודה מותר לאבד (Full, עם גיבוי יומן תנועות כל כמה דקות, כשאסור לאבד יותר מזה), גיבוי שנעשה דרך SQL Server עצמו או דרך כלי שמכיר את VSS ולא העתקה של קובצי MDF, ושחזור מבחן קבוע לשרת נפרד עם בדיקת DBCC CHECKDB. RESTORE VERIFYONLY בודק שהקובץ קריא, לא שבסיס הנתונים תקין.

איזה מודל שחזור מתאים למערכת ERP?

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

יומן התנועות

Simple
מתרוקן אוטומטית
Full
נשמר עד שמגבים אותו

לאן אפשר לחזור

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

אובדן מקסימלי

Simple
כל מה שמאז הגיבוי האחרון
Full
כל מה שמאז גיבוי היומן האחרון

מה חייב לרוץ

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

מתאים ל

Simple
בסיסי נתונים לבדיקות ודוחות
Full
בסיס הנתונים החי של ה-ERP

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

אילו גיבויים צריכים לרוץ, ובאיזו תדירות?

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

מלא (Full)

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

דיפרנציאלי

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

יומן תנועות (Log)

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

מה ההבדל בין גיבוי של SQL Server להעתקה של הקבצים?

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

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

גיבוי עקבי נעשה באחת הדרכים

  • פקודת BACKUP DATABASE, ידנית או דרך Maintenance Plan או SQL Agent
  • כלי גיבוי שמכיר את SQL Server ומתאם צילום דרך VSS
  • גיבוי של המכונה כולה בכלי שמפעיל VSS בתוך Windows, עם בדיקה שה-SQL Writer תקין
שני כלים שמגבים את אותו בסיס נתונים
אם גם Maintenance Plan וגם כלי הגיבוי של המכונה מגבים את היומן, השרשרת מתפצלת בין שני מקומות, ושחזור מכל אחד מהם לבד ייכשל. מחליטים על כלי אחד שאחראי על גיבויי היומן.

איך יודעים שהגיבוי באמת נפתח?

משחזרים אותו. RESTORE VERIFYONLY בודק שהקובץ קריא, DBCC CHECKDB אחרי שחזור לשרת נפרד בודק שבסיס הנתונים תקין, ופתיחה של ה-ERP מעליו בודקת שהעסק יכול לעבוד.

הודעת הצלחה בכלי הגיבוי

מה היא מוכיחה
שהתהליך הסתיים
מה היא לא מוכיחה
שהקובץ שלם או שאפשר לשחזר ממנו

RESTORE VERIFYONLY

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

שחזור + DBCC CHECKDB

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

שחזור + פתיחת ה-ERP

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

    בוחרים שרת נפרד

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

  2. 2

    משחזרים את השרשרת

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

  3. 3

    מריצים DBCC CHECKDB

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

  4. 4

    פותחים את המערכת

    המיישם או משתמש מפתח מוודא שהדוחות והתנועות האחרונות קיימים.

  5. 5

    רושמים

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

איפה שומרים את קובצי הגיבוי?

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

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

ל-ERP עצמו יש מדריכים נפרדים: שרת פריוריטי, SAP Business One וחשבשבת. ולשרת עצמו, ראו שרת SQL Server מנוהל.

שאלות נפוצות

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

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

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

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

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

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

מקורות ובדיקה אחרונה

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

נבדק לאחרונה:

מדריכים קשורים

לא בטוחים שהגיבוי של בסיס הנתונים נפתח?

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

052-3373912