‏27/10/2013

התאוששות  מאסון בפרספקטיבת IT חלק ב

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

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

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

( Clustering redundancy off site backup,snapshot, images etc.).

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

מה כן חובה לעשות על מנת לייצר שרידות והמשכיות?

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

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

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

דוגמא ב:  אותו התסריט תקף גם למסדי נתונים בהיעדר מודול מתאים לא ניתן לשחזר מסד נתונים בודד אלא את כל ה DB ושם זה קצת יותר מסובך עבוד אנשי System וצריך להיעזר באנשי מסדי נתונים (DB).

Selection List - במקרים רבים נותנים למנהל תפעול איש כספים איש ה IT או איש
אפליקציות לעבור על רשימת הנתונים לגיבוי (מה צריך לגבות) ומנהל הארגון שבע רצון
מהדוח היומי שהגיבוי הסתיים בהצלחה – זה לא מספיק! 

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

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

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

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

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

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

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

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

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

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

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

גיבוי online

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

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

סיפור מקרה:

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

התוכנה שלה הייתה מותקנת מקומית על המחשב שלה ועל הנייד ובסיס הנתונים
ישב ב drop box.

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

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

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

בהתייחסות לפתרונות גיבוי אונליין עסקיים עבור עסקים קטנים ובינוניים
בחנו מספר מוצרים וביניהם:

1. C-tera  משווק ע"י בזק בינלאומי פתרון זול משמעותית מגיע בתצורת גיבוי בענן
   בלבד ובתצורה משולבת של גיבוי ענן עם התקן מקומי (NAS), היתרון היחידי של פתרון
   זה הוא המחיר, משתמשים מתקדמים מאוד יכולים להוציא מהמוצר גיבוי סביר, על פניו המוצר מגיע עם אפשרויות מתקדמות וממשק משתמש נוח,  אך הבעיה המרכזית בו היא התמיכה של בזק בינלאומי שלא ממש מכירים את  המוצר נכון לכתיבת שורות אלו, בבדיקה שלנו הם כשלו בתפעול תקלות מורכבות או מצבים
   לא סטנדרטיים.
2. Atera – פתרון המשווק ע"י חברת אטרה עצמה לחברות IT והם מוכרות ללקוח הסופי,
   פתרון יקר יותר אך בהחלט מקצועי ויעיל, הגיבוי של אטרה מתבצע לענן בחוות שרתים
   מוכרת וידועה העומדת בכל התקנים והתוכנה מגיעה גם עם שלל אפשרויות גיבוי כולל שרתי
   דואר, שרתי קבצים, בסיסי נתונים ועוד....  כמו כן אטרה מספקים פלטפורמה נוחה לניהול וניטור הרשת.
3. PMBox – פתרון בשלב פיתוח המספק פתרון בתצורה משולבת של גיבוי ענן עם התקן מקומי (שרת) והגיבוי הוא גיבוי image מלא כולל שינויים ע"פ הגדרות המשתמש, יתרון הגיבוי הנ"ל הוא זמן התאוששות מהיר, למערכת זו ישנה אפשרות להפעיל מערכת שקרסה בצורה וירטואלית עד כ 30 דקות מרגע קריסתה, לכן פתרון זה מומלץ לארגונים שלא יכולים להרשות לעצמם השבתה ארוכה, המערכת יודעת לגבות ניידים, מחשבים, וכמעט כל סוגי השרתים.

בברכה,

עוקשי אסף

Prodigy LTD

www.prodigy.co.il