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

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

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

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

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

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

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

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

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

בונים מערך גיבוי עם יותר מעותק אחד

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

מערך מאוזן כולל בדרך כלל את המרכיבים הבאים:

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

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

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

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

שרתים ומכונות וירטואליות

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

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

קבצים ושיתופים ברשת

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

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

דואר אלקטרוני ושירותי ענן

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

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

מחשבי עובדים ומנהלים

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

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

ההגנה על הגיבוי חשובה כמו ההגנה על המידע

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

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

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

מבחן השחזור הוא הרגע שבו מגלים את האמת

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

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

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

מי עוקב אחרי הגיבוי ביום-יום?

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

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

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

טעויות שכדאי למנוע מראש

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

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

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