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

מישהו אומר: "אין בעיה, יש גיבוי".

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

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

גיבוי ושחזור אינם אותו הדבר

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

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

לדוגמה:

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

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

מה העסק באמת צריך להיות מסוגל לשחזר?

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

בעסק טיפוסי כדאי לבדוק לפחות את הנכסים הבאים:

• מסמכים ותיקיות משותפות
• מערכות הנהלת חשבונות ושכר
• תוכנות ניהול לקוחות או ניהול עסק
• מסדי נתונים
• תיבות דואר, לוחות שנה ואנשי קשר
• קבצים ב-Microsoft 365, ב-SharePoint וב-OneDrive
• שרתים פיזיים או וירטואליים
• מערכות ענן ויישומים עסקיים
• הגדרות של מערכות תקשורת ואבטחת מידע
• מחשבים שעליהם נשמר מידע שאינו נמצא במקום מרכזי

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

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

שתי שאלות שמנהלים צריכים לשאול

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

כמה מידע העסק יכול להרשות לעצמו לאבד?

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

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

כמה זמן העסק יכול לעבוד בלי המערכת?

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

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

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

איך בודקים שגיבוי באמת ניתן לשחזור?

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

הבדיקה יכולה להתבצע בכמה רמות:

שחזור של קבצים ותיקיות

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

שחזור של תיבת דואר או מידע מ-Microsoft 365

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

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

שחזור של מערכת עסקית

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

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

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

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

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

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

אלה השאלות שכדאי לשאול:

1. מה בדיוק מגובה?

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

2. מה אינו מגובה?

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

3. באיזו תדירות מתבצע הגיבוי?

חשוב להבין כמה שעות או ימי עבודה עלולים ללכת לאיבוד.

4. כמה זמן נשמרות גרסאות קודמות?

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

5. היכן נשמר עותק הגיבוי?

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

6. האם קיימת הפרדה בין סביבת העבודה לגיבוי?

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

7. האם הגיבויים מנוטרים?

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

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

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

9. מי אחראי לבצע שחזור במקרה הצורך?

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

10. כמה זמן צפוי לקחת השחזור?

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

גיבוי מקומי לבדו אינו מספיק

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

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

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

ומה לגבי מידע בענן?

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

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

כדאי לבדוק בכל שירות:

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

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

שחזור טוב דורש גם תיעוד

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

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

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

מי בודק שהגיבוי ממשיך לעבוד?

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

לכן צריך לחבר בין שלושה דברים:

• ניטור שוטף של עבודות הגיבוי
• טיפול מתועד בכל כשל
• בדיקות שחזור תקופתיות

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

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

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

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

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