- הודעת "הגיבוי הסתיים בהצלחה" אומרת שהעתקה רצה. היא לא אומרת שאפשר לשחזר ממנה.
- בדיקת שחזור היא פשוטה: בוחרים משהו אמיתי, משחזרים אותו למקום נפרד, ובודקים שהוא נפתח ושלם.
- כדאי להחליט מראש שני דברים: כמה מידע מותר לאבד (RPO) וכמה זמן מותר להיות מושבתים (RTO). מהם נגזרים התדירות וסוג הגיבוי.
- שרתים ומערכות קריטיות דורשים גם בדיקה של שחזור מלא, לא רק של קובץ בודד.
כמעט כל עסק "מגבה". הרבה פחות עסקים בדקו מתי בפעם האחרונה שחזרו משהו מהגיבוי, ומה יצא. הפער הזה מתגלה בדרך כלל ביום הכי גרוע: שרת שקרס, קובץ שנמחק, כופרה. במדריך הזה נסביר איך בודקים שגיבוי באמת עובד, בלי להפוך את זה לפרויקט.
למה גיבוי "מוצלח" יכול להיכשל בשחזור
כמה סיבות נפוצות:
- גובים את הדבר הלא נכון: התיקייה זזה, נוספה מערכת חדשה, ואף אחד לא עדכן את הגדרות הגיבוי.
- הגיבוי לא שלם: מסד נתונים שגובה בזמן שהוא פתוח, בלי כלי שמתאים לכך, עלול לא להיפתח בשחזור.
- אין גרסאות מספיק ישנות: כשמגלים בעיה אחרי שבועיים, והגיבוי שומר רק כמה ימים אחורה.
- אין גישה: הסיסמה או מפתח ההצפנה של הגיבוי אצל מישהו שכבר לא בעסק.
- השחזור איטי מדי: שחזור של נפח גדול מהענן יכול לקחת זמן רב, ואם לא בדקו, לא יודעים כמה.
שתי שאלות שקובעות איזה גיבוי צריך
- כמה מידע מותר לאבד? (RPO, Recovery Point Objective) אם הגיבוי רץ פעם ביום בלילה, תקלה בשעה ארבע אחר הצהריים מחזירה אתכם לנקודה של הלילה. האם יום עבודה שלם זה מקובל?
- כמה זמן מותר להיות מושבתים? (RTO, Recovery Time Objective) אם השרת נופל, תוך כמה זמן העסק חייב לחזור לעבוד?
את התשובות קובע העסק, לא הטכנאי. אבל ברגע שהן ברורות, אפשר להתאים את תדירות הגיבוי, את מספר העותקים ואת סוג הגיבוי (קבצים בלבד, או גיבוי מלא של שרת שאפשר להרים ממנו מחדש).
איך עושים בדיקת שחזור, צעד אחר צעד
- בוחרים פריט אמיתי: קובץ עבודה, תיקייה, תיבת דואר או מסד נתונים, לא קובץ בדיקה שנוצר במיוחד.
- משחזרים למקום נפרד, כדי לא לדרוס את הגרסה הנוכחית.
- פותחים ובודקים: הקובץ נפתח? התוכן מלא? התאריך הוא מה שציפיתם?
- מודדים זמן: כמה זמן לקח השחזור, מההחלטה ועד שהקובץ זמין.
- מתעדים: תאריך, מה נבדק, מה יצא, ומי בדק.
- מתקנים: אם משהו לא עבד, זה הזמן לגלות את זה, לא ביום אמת.
מה בודקים, ובאיזו תדירות
אין תדירות אחת שמתאימה לכולם. כלל אצבע סביר:
- בדיקה קטנה וקבועה: שחזור של קובץ או תיקייה אקראיים, במרווחים קבועים שהעסק מחליט עליהם.
- אחרי כל שינוי: מערכת חדשה, שרת חדש, מעבר משרד או שינוי בהגדרות הגיבוי.
- בדיקה גדולה מדי פעם: שחזור מלא של שרת או של מערכת קריטית לסביבה נפרדת, כדי לוודא שאפשר באמת לחזור לעבוד ממנה.
- Microsoft 365: לבדוק גם שחזור של תיבת דואר ושל תיקיית OneDrive או SharePoint, אם יש לכם גיבוי ל-Microsoft 365.
שרתים: קבצים זה לא מספיק
בשרת יש מערכת הפעלה, הגדרות, תוכנות, הרשאות ומסדי נתונים. אם גובים רק את הקבצים, ביום שהשרת נופל צריך להתקין ולהגדיר הכול מחדש לפני שאפשר להחזיר את הקבצים. גיבוי מלא (Image) של השרת מאפשר לשחזר אותו כפי שהיה, לחומרה חדשה או לסביבה וירטואלית. כאן בדיקת שחזור מלאה, לפחות מדי פעם, חשובה במיוחד.
צ'קליסט קצר
- יודעים מה מגובה, ומה לא.
- הוגדרו RPO ו-RTO לכל מערכת חשובה.
- יש עותק מחוץ למשרד, ועותק שלא נגיש לכופרה (ראו: כופרה בעסק).
- יש תיעוד של בדיקת השחזור האחרונה.
- יודעים מי מבצע את השחזור, ואיפה הסיסמאות והמפתחות.
השורה התחתונה
גיבוי שלא נבדק בשחזור הוא בעיקר הנחה. בדיקה קצרה וקבועה, עם תיעוד, הופכת אותו לביטחון אמיתי. הרקע המלא על סוגי גיבוי וכלל 3-2-1 נמצא במדריך גיבוי בענן לעסקים.
איך ש.מ מחשבים יכולה לעזור
אנחנו מספקים גיבוי בענן לעסקים כשירות מנוהל: גיבוי לשרתים, לתחנות, למסדי נתונים ול-Microsoft 365, עם בדיקות שחזור תקופתיות: מושכים קבצים אמיתיים, מוודאים שהם נפתחים, ובודקים שההיקף תואם למה שקורה בעסק היום. אפשר להתחיל בשיחה קצרה ולבדוק יחד מה מצב הגיבוי אצלכם היום.