מנהלים בכירים ומנהלי מערכות מידע בארגונים גדולים שוגים לחשוב שאם דאגו לגיבוי המידע של הארגון שלהם, הם מוגנים מפני נפילות מערכת המחשוב, מתקפת סייבר או הונאות כופר (ransomware), תקלות של עובדים, אסונות טבע ועוד. הנחת היסוד של מנהלים רבים, בארץ ובעולם, היא שבכל מקרה של תקלה כלשהי במערכות המחשוב, הם פשוט יעשו שימוש בגיבוי שלהם, ושום נזק משמעותי לא ייגרם לארגון שבראשו הם עומדים. מדובר בהנחה שגויה מן היסוד, הרחוקה מאוד מן המציאות וייתכן כי מבוססת, בין השאר, על פרשנות מילולית מוטעית של המילה גיבוי או באנגלית Backup. בישראל מתווספת לזה גם תרבות "הסמוך" ו"יהיה בסדר", והרי לפניכם אסון מסחרי, שיווקי ותדמיתי ידוע מראש.
במילים גיבוי ו - Backup טמונה תחושת הביטחון של מנהלים שהם מוגנים מפני נזקים העלולים להיגרם כתוצאה מנפילת מערכת המחשוב של הארגון בראשו הם עומדים, שהרי לתפיסתם יש להם גב. המידע שלהם מגובה, ובמקרה של בעיה כלשהי, יושיטו אליו יד וישתמשו בו עד שתתוקן התקלה במערכת המחשוב שלהם. אם כך אכן היו פני הדברים, היו נמנעות אינספור השבתות של חברות גדולות בארץ ובעולם, שהובילו להפסדים כספיים עצומים ולתלונות קשות מצד לקוחות.
בפועל, גיבוי מבטיח רק שמירה למרבית המידע היקר, אך בינו ובין חזרה לפעילות מהירה ותקינה אין דבר וחצי דבר. גיבוי מידע ונתונים אינו פתרון מקיף דיו, ואינו מאפשר חזרה מהירה לפעילות מלאה, לכן התפתח מאוד בעשור האחרון תחום ה"המשכיות עסקית" (Business Continuity) ו"התאוששות מאסון", אשר מבטיחים לא רק שמירה על המידע כי אם חזרה לפעילות מלאה מאותה נקודה, בתוך זמן קצר מאוד, ולמעשה ללא השבתת המערכת כלל, גם במצבי קיצון.
השבתה של מרכז הנתונים פירושה שהארגון אינו יכול לשרת את לקוחותיו והוא אינו יכול לבצע עסקאות, מה שעלול להוביל לאובדן רב של הכנסות. לכן הכלל הראשון של כל מנהל מערכות מידע שרוצה להימנע מהשבתת מרכז הנתונים שלו, הוא להיערך בהתאם כדי לספק מענה לכל תקלה ולהבטיח המשכיות עסקית.
חשוב להדגיש ולציין כי גיבוי הוא עדיין כלי הכרחי, שיכול להגן על הנתונים במקרים כמו גניבת מחשב נייד, טעויות אנוש (מחיקת קובץ חשוב), או בעיות טכניות (בעיות חומרה), כך שניתן לגשת אל עותק של הנתונים ולשחזר אותו בקלות. יחד עם זאת, היכולת לגבות את המידע אמנם יעניק אפשרות לאחזר את המידע אך עדין הוא יהיה עדכני אך ורק לזמן ביצוע הגיבוי האחרון (המתבצע בדרך כלל שעות הלילה על מנת שלא לפגוע במשאבי ה IT). ישנם ארגונים שאינם יכולים להרשות לעמם לאבד נתונים של כמה שעות או יום שלם.
כיום, גישות הגיבוי וההתאוששות מאסון של העבר כבר אינן מספיקות והן פוגשות את הגישה הנוכחית, של דרישה להתאוששות ארגונית או – תכנית המשכיות עסקית (BCP). בעזרת תכנית התאוששות מאסון (DRP), העובדים יכולים להמשיך לעבוד באמצעות מערכת מקבילה כך שבזמן שצוות ה-IT עובד על תיקון הבעיה ברשת המקורית.
בעוד שגיבוי הוא אלמנט חשוב, הארגון צריך לתכנן גם כיצד הוא מתאושש מאסון בכדי להבטיח הגנה מלאה. השלב הראשון הוא אחסון הגיבויים מחוץ לאתר. ניתן לעשות זאת באמצעות שכפול הגיבוי לענן או על ידי אחסון עותקים משניים במיקום אחר הרחק מן השרתים שלך. הפתרון המומלץ הוא כמובן מערכת גיבוי לענן כיוון שהוא הפתרון האמין והקל ביותר לגישה.
במקרה של אסון זמן הוא קריטי. היתרון העיקרי של תכנית התאוששות מאסון, שהיא משתמשת כמראה של המערכת, כך שניתן להתאושש מהר ולא לחכות להעתקת הנתונים. בעזרת שרתים וירטואליים עם התקנת DR ניתן לשחזר את המידע בתוך דקות ספורות.
האלמנט החשוב ביותר הוא להבטיח בראש ובראשונה את ה – RPO (Recovery Point Objective) הנמוך ביותר (near zero RPO) כלומר היקף המידע שייפגע. במקביל חשוב לוודא כי אנו מגיעים ל - RTO (Recovery Time Objective) הנמוך ביותר ((near zero RTO- הזמן בפועל בו יישום או שירות יחזור לשימוש מלא ויאפשר עבודה סדירה של העובדים ו\או הלקוחות.
חשוב להבין כי גיבוי, טוב ככל שיהיה, עדיין אינו מספק משום שאינו מבטיח את אותן יכולות המאפשרות את ה- RPO וה- RTO בצורה מלאה. יחד עם זאת, שילוב נכון בין שני מרכיבים אלה, מאפשר כיום לארגונים לא רק להבטיח המשכיות עסקית גבוהה אלא גם לנצל את המידע בצד ה DR לטובת פיתוח, מחקר, כריית נתונים ועוד. באמצעות הקמת מערך שכפול נתונים יעיל ויצירת מאגרי מידע בענן לצד היכולת לאחזר את המידע ולהחזירו לשימוש בפרק זמן של דקות ספורות. כמו כן נדרש תמיד לבדוק את מערכת הגיבוי על בסיס קבוע בכדי להבטיח את תקינותה, באמצעות תרחישי בדיקה המוודאים כי הכל פועל כראוי לפני שמקרה חירום יקרה במציאות.
על מנהלים בכירים ומנהלי מערכות מידע להתאים עצמם למציאות החדשה, שבה גיבוי מידע הוא אמנם הכרחי, אך בפירוש אינו מספיק בכדי למנוע נזקים אדירים, ולעתים אף בלתי הפיכים לארגון.
מאמר זה נכתב על ידי גיל שני, CTO ב- MedOne
מנהלים בכירים ומנהלי מערכות מידע בארגונים גדולים שוגים לחשוב שאם דאגו לגיבוי המידע של הארגון שלהם, הם מוגנים מפני נפילות מערכת המחשוב, מתקפת סייבר או הונאות כופר (ransomware), תקלות של עובדים, אסונות טבע ועוד. הנחת היסוד של מנהלים רבים, בארץ ובעולם, היא שבכל מקרה של תקלה כלשהי במערכות המחשוב, הם פשוט יעשו שימוש בגיבוי שלהם, ושום נזק משמעותי לא ייגרם לארגון שבראשו הם עומדים. מדובר בהנחה שגויה מן היסוד, הרחוקה מאוד מן המציאות וייתכן כי מבוססת, בין השאר, על פרשנות מילולית מוטעית של המילה גיבוי או באנגלית Backup. בישראל מתווספת לזה גם תרבות "הסמוך" ו"יהיה בסדר", והרי לפניכם אסון מסחרי, שיווקי ותדמיתי ידוע מראש.
במילים גיבוי ו - Backup טמונה תחושת הביטחון של מנהלים שהם מוגנים מפני נזקים העלולים להיגרם כתוצאה מנפילת מערכת המחשוב של הארגון בראשו הם עומדים, שהרי לתפיסתם יש להם גב. המידע שלהם מגובה, ובמקרה של בעיה כלשהי, יושיטו אליו יד וישתמשו בו עד שתתוקן התקלה במערכת המחשוב שלהם. אם כך אכן היו פני הדברים, היו נמנעות אינספור השבתות של חברות גדולות בארץ ובעולם, שהובילו להפסדים כספיים עצומים ולתלונות קשות מצד לקוחות.
בפועל, גיבוי מבטיח רק שמירה למרבית המידע היקר, אך בינו ובין חזרה לפעילות מהירה ותקינה אין דבר וחצי דבר. גיבוי מידע ונתונים אינו פתרון מקיף דיו, ואינו מאפשר חזרה מהירה לפעילות מלאה, לכן התפתח מאוד בעשור האחרון תחום ה"המשכיות עסקית" (Business Continuity) ו"התאוששות מאסון", אשר מבטיחים לא רק שמירה על המידע כי אם חזרה לפעילות מלאה מאותה נקודה, בתוך זמן קצר מאוד, ולמעשה ללא השבתת המערכת כלל, גם במצבי קיצון.
השבתה של מרכז הנתונים פירושה שהארגון אינו יכול לשרת את לקוחותיו והוא אינו יכול לבצע עסקאות, מה שעלול להוביל לאובדן רב של הכנסות. לכן הכלל הראשון של כל מנהל מערכות מידע שרוצה להימנע מהשבתת מרכז הנתונים שלו, הוא להיערך בהתאם כדי לספק מענה לכל תקלה ולהבטיח המשכיות עסקית.
חשוב להדגיש ולציין כי גיבוי הוא עדיין כלי הכרחי, שיכול להגן על הנתונים במקרים כמו גניבת מחשב נייד, טעויות אנוש (מחיקת קובץ חשוב), או בעיות טכניות (בעיות חומרה), כך שניתן לגשת אל עותק של הנתונים ולשחזר אותו בקלות. יחד עם זאת, היכולת לגבות את המידע אמנם יעניק אפשרות לאחזר את המידע אך עדין הוא יהיה עדכני אך ורק לזמן ביצוע הגיבוי האחרון (המתבצע בדרך כלל שעות הלילה על מנת שלא לפגוע במשאבי ה IT). ישנם ארגונים שאינם יכולים להרשות לעמם לאבד נתונים של כמה שעות או יום שלם.
כיום, גישות הגיבוי וההתאוששות מאסון של העבר כבר אינן מספיקות והן פוגשות את הגישה הנוכחית, של דרישה להתאוששות ארגונית או – תכנית המשכיות עסקית (BCP). בעזרת תכנית התאוששות מאסון (DRP), העובדים יכולים להמשיך לעבוד באמצעות מערכת מקבילה כך שבזמן שצוות ה-IT עובד על תיקון הבעיה ברשת המקורית.
בעוד שגיבוי הוא אלמנט חשוב, הארגון צריך לתכנן גם כיצד הוא מתאושש מאסון בכדי להבטיח הגנה מלאה. השלב הראשון הוא אחסון הגיבויים מחוץ לאתר. ניתן לעשות זאת באמצעות שכפול הגיבוי לענן או על ידי אחסון עותקים משניים במיקום אחר הרחק מן השרתים שלך. הפתרון המומלץ הוא כמובן מערכת גיבוי לענן כיוון שהוא הפתרון האמין והקל ביותר לגישה.
במקרה של אסון זמן הוא קריטי. היתרון העיקרי של תכנית התאוששות מאסון, שהיא משתמשת כמראה של המערכת, כך שניתן להתאושש מהר ולא לחכות להעתקת הנתונים. בעזרת שרתים וירטואליים עם התקנת DR ניתן לשחזר את המידע בתוך דקות ספורות.
האלמנט החשוב ביותר הוא להבטיח בראש ובראשונה את ה – RPO (Recovery Point Objective) הנמוך ביותר (near zero RPO) כלומר היקף המידע שייפגע. במקביל חשוב לוודא כי אנו מגיעים ל - RTO (Recovery Time Objective) הנמוך ביותר ((near zero RTO- הזמן בפועל בו יישום או שירות יחזור לשימוש מלא ויאפשר עבודה סדירה של העובדים ו\או הלקוחות.
חשוב להבין כי גיבוי, טוב ככל שיהיה, עדיין אינו מספק משום שאינו מבטיח את אותן יכולות המאפשרות את ה- RPO וה- RTO בצורה מלאה. יחד עם זאת, שילוב נכון בין שני מרכיבים אלה, מאפשר כיום לארגונים לא רק להבטיח המשכיות עסקית גבוהה אלא גם לנצל את המידע בצד ה DR לטובת פיתוח, מחקר, כריית נתונים ועוד. באמצעות הקמת מערך שכפול נתונים יעיל ויצירת מאגרי מידע בענן לצד היכולת לאחזר את המידע ולהחזירו לשימוש בפרק זמן של דקות ספורות. כמו כן נדרש תמיד לבדוק את מערכת הגיבוי על בסיס קבוע בכדי להבטיח את תקינותה, באמצעות תרחישי בדיקה המוודאים כי הכל פועל כראוי לפני שמקרה חירום יקרה במציאות.
על מנהלים בכירים ומנהלי מערכות מידע להתאים עצמם למציאות החדשה, שבה גיבוי מידע הוא אמנם הכרחי, אך בפירוש אינו מספיק בכדי למנוע נזקים אדירים, ולעתים אף בלתי הפיכים לארגון.
מאמר זה נכתב על ידי גיל שני, CTO ב- MedOne
הודעתך לא התקבלה - נסה שוב מאוחר יותר
Oops! Something went wrong while submitting the form