מגזין
גיבוי מידע – התאוששות מאסון - אתר חירום
התקופה מאופיינת באי וודאות ונושא שעולה לשיחה על בסיס יומי
הוא שמירה על המידע שלנו. גיבוי אפליקציות, קוד ובסיסי הנתונים של האתרים הם שיח יומיומי. במאמר זה נעלה מס' נקודות חשובות לכל בית עסק, בין אם מדובר בבית עסק עם אתר אינטרנט בודד ועד בית עסק אשר מחזיק מספר גדול של אתרים על פני תשתית רחבה.
כללי:
אתרי אינטרנט, אפליקציות, בסיסי הנתונים, ממשקי API, מערכות CRM, מערכות לניהול קריאות שירות וניהול משימות הם נכסים דיגיטליים חשובים ובעידן הנוכחי לרוב יכילו את כלל המידע הארגוני שלנו.יש חשיבות רבה לגיבוי המידע, הרחקת המידע והיכולת להתאושש במקרה של תקלה משביתה או אסון.
מהם הסכנות?
מגוון הסכנות גדול ולא נוכל לרשום כאן את כולם, אציין כמה לדוגמא:
טעות אנוש – עובד החברה/מתכנת/איש סיסטם מחק בטעות מידע מהאתר/שרת.
האקר אשר פורץ לאתר/שרת ומוחק/משחית/מצפין את המידע באופן בלתי הפיך.
וירוס אשר חדר לשרת, מוחק ומשבש את פעילות האתרים ועד למצב בו מצפינים את המידע.
תקלה במערכת הגיבוי של האתר הראשי בעקבותיה לא ניתן לשחזר מידע.
תרחיש קיצון - שריפה של חוות השרתים (חפשו ברשת "שריפה בחוות שרתים OVH") ועד לתרחיש אימים אשר תואם (לצערינו) את רוח התקופה ובמסגרתו חוות השרתים חווה אירוע ביטחוני ונהרסת כליל.
פתרונות מומלצים:
מגוון הפתרונות רחב, חלקם פתרונות בסיסיים, זולים וקלים למימוש, חלקם מורכבים יותר ודורשים הערכות מוקדמת, תוכנית עבודה ועלויות יקרות יותר. נתחיל מהפשוט והקל אל המורכבים יותר.
גיבוי קבצים מקומי
ברמה הבסיסית ביותר וודאו שיש לכם גיבוי קבצים של האתר!
גיבוי קבצים יכלול גיבוי של התיקיות, הקבצים ובסיסי הנתונים של האתר אל מערכת גיבוי מקומית. ב – SPD מקבלים גיבוי למשך 7 ימים כברירת מחדל, הן באירוח שיתופי והן בשרתים וירטואליים. הגיבוי מתבצע אל מערכת גיבוי בחווה המקומית בה גם מאוחסנים האתרים ולא מהווה גיבוי לאתר מרוחק.
גיבוי Snapshot (תמונת מערכת)
במסגרת גיבוי זה מבצעים "צילום" מלא של המערכת/שרת.
גיבוי זה בשונה מגיבוי הקבצים אשר כולל באופן פרטני את התיקיות/קבצים/בסיסי נתונים של האתר כולל בתוכו גיבוי מלא של מערכת ההפעלה, תוכנות אשר מותקנות בשרת, הגדרות של מערכת ההפעלה וגיבוי מלא של המידע (קבצים, תיקיות ובסיסי נתונים בשרת).
היתרונות של גיבוי Snapshot הם אדירים, בלחיצת כפתור ובפרק זמן קצר משחזרים את כל השרת, כולל המידע וכולל ההגדרות כך שאם מישהו פרץ לשרת והחריב אותו (דוגמא) אז בלחיצת כפתור ותוך זמן קצר מאד מתאוששים מהאירוע. התאוששות עם גיבוי Snapshot מייתרת את הצורך להתקין את השרת מחדש, לבצע הגדרות ולשחזר אליו את המידע, פעולות אשר עלולות להתארך שעות רבות במהלכם האתר מושבת. את הגיבוי הזה ניתן לרכוש עבור שרתים וירטואליים או פיזיים בלבד ולא ניתן ליישם אותו באירוח שיתופי.
כבסיס, הגיבוי מתבצע אל מערכת גיבוי בחווה המקומית בה גם מאוחסנים השרתים ולא מהווה גיבוי לאתר מרוחק, את גיבוי ה Snapshot ניתן לשמור בין 7 ל 30 ימים לפי השירות אשר נרכש.
גיבוי Snapshot (תמונת מערכת) לאתר מרוחק
גיבוי זה זהה לחלוטין לגיבוי ה Snapshot הרגיל מלבד הבדל אחד חשוב
בסיום גיבוי ה Snapshot באתר הראשי תשלח מערכת הגיבוי באופן אוטומטי עותק אל חווה רחוקה. באפשרות זו גיבוי ה Snapshot
מועתקים לחווה רחוקה ונשמרים שם לפרק זמן מסוים לפי סוג החבילה אשר נרכשה. כעת, כאשר המידע נמצא בחווה רחוקה אנו מוגנים מפני מקרי קיצון בחווה הראשית ומקבלים אפשרות להתאושש תוך מספר שעות עד מספר ימים בודדים עם כלל המערכות שלנו. בדומה לגיבוי ה Snapshot הרגיל גם את אפשרות זו ניתן לרכוש עבור שרתים וירטואליים או פיזיים בלבד והבסיס חייב להיות גיבוי Snapshot באתר הראשי.
תוכנית Offsite Backup
המונח Offsite Backup הוא למעשה תוכנית להרחקת המידע אל מחוץ לחווה הראשית. במסגרת Offsite Backup ניקח עותק של המידע מהאתר הראשי ונעביר אותו בתוכנית סדורה ועל בסיס קבוע אל אתר מרוחק. המידע יכלול את התיקיות, הקבצים, האפליקציה ובסיסי הנתונים ויורחק על בסיס יומי.
הרעיון מאחורי תוכנית Offsite Backup הוא בעיקר שמירת עותק של המידע במקום רחוק מהחווה הראשית, המידע נמצא שם וניתן להשתמש בו להתאוששות מאסון. את המידע ניתן לשמור על גבי שרת וירטואלי או שירות אחסון (Storage) בחווה רחוקה, הפתרון הטכני תלוי מאד בהיקף המידע אשר רוצים להרחיק והמקום בו הוא נמצא באתר הראשי (אחסון שיתופי, שרת וירטואלי ועוד). בשונה מאתר חירום עליו נרחיב בהמשך מידע זה אינו מוכן באופן מידי לעבודה ובעת הצורך נצטרך להתקין את השרתים מחדש, להגדיר את המערכות ולטעון את המידע אשר שמרנו באתר המרוחק.
במהלך השנה האחרונה, בצל המלחמה והאיומים על ישראל גבר הצורך להרחיק את המידע אל מחוץ לישראל, פעולה אשר נבצע לרוב מול שירותים אשר מוצעים בעננים ציבוריים כגון ORACLE ו – AWS.
היתרון של תוכנית זו – שמירת עותק של המידע באתר מרוחק, המידע מוגן וזמין בעת אסון.
חסרון של התוכנית – המערכות לא יעלו באופן מהיר, יש צורך להתקין את המערכות, לשחזר מידע והגדרות, פעולה אשר עשויה להתארך משעות בודדות ועד ימים שלמים במהלכם האתרים שלנו לא יהיו זמינים.
אופן היישום ונוהל עבודה:
ניתן להשתמש במספר שירותי ענן מוכרים אשר יודעים לספק כיום גם שטח אחסון עבור המידע וגם תוכנות עזר לביצוע הגיבוי בפועל, שירותים כגון Dropbox, שירותי S3 של עננים ציבוריים ואף שירותים כגון Google Drive ו – One Drive. במקרה של אחסון שיתופי באחריות הלקוח לקיים סוג כזה של גיבוי, במקרה של שרתים וירטואליים או שירותים מורכבים יותר כגון תשתיות ענן, סביבות קוברנטיס אז יש צורך לבצע איפיון מסודר ולהוציא לפועל כפרויקט ייעודי לתצורת Offsite Backup.
נוהל עבודה - כאשר מדובר במידע עסקי אז אופן היישום וגם נוהל עבודה חשובים מאד, נוהל העבודה הוא המקום בו מתעדים את התהליך, את אופן היישום ועד לביצוע בדיקה תקופתית כדי לוודא שהשירות פועל כשורה והמידע זמין לשימוש בעת הצורך.
אתר חירום (DR Site)
אתר חירום, באנגלית Disaster recovery (DR) site
אפשרות מורכבת יותר, יקרה יותר, אשר תתאים לרוב ללקוחות עם ריבוי אתרים אשר מרכיב השרידות והזמינות בהיבט העסקי הינם קריטיים עבורם. אתרים כגון, אתרי מכירות (ecommerce website), אתרי קמעונאות, עיתונים, מערכות קריטיות כגון אתרי המשטרה, מגן דויד אדום, חברת חשמל, בנקים ואחרים.
באופן כללי אתר החירום יכלול את אותם תשתיות המחשוב והשרתים אשר קיימים באתר הראשי, בחלק מהמקרים הם יהיו זהים לחלוטין ובחלק מהמקרים משיקולי עלות הם יהיו בתצורה חלשה יותר. הפתרון יכלול מנגנון לסנכרון המידע בין האתר הראשי לאתר החירום, המידע יועתק באופן אוטומטי, ויסונכרן Online, הן עבור האפליקציה והן עבור בסיסי הנתונים. בנוסף, הפתרון יכלול מנגנון של קפיצה/מעבר בין החוות בעת קריסה ו/או על פי תסריט שהוכן מראש.
סוגים של אתרי חירום (DR Site):
Active-Active – בתצורה זו 2 חוות השרתים, האתר הראשי והאתר השני יעבדו במקביל. גולשים או עובדים אשר יתחברו אל המערכות, ו/או יגלשו אל אתרי האינטרנט ינותבו באופן אוטומטי לעבודה בין 2 האתרים כאילו שהם היו אתר אחד.
פתרון זה לרוב יהיה יקר יותר ליישום, 2 האתרים יהיו לרוב זהים לחלוטין בהיקף המחשוב, הפתרון יכלול קווים ייעודיים מהירים (תמסורות) אשר יקשרו את התשתיות ויהפכו אותם למקשה אחת, מנגנוני תקשורת מתוחכמים אשר ידעו לנתב את העבודה בין 2 האתרים ולבסוף ולא פחות חשוב
גם האפליקציות צריכות להיות ערוכות לעבוד בסוג כזה של תצורה.
Active-Passive – בתצורה זו חוות שרתים אחת תוגדר כאתר ראשי וחוות שרתים שניה תוגדר כאתר משני. גולשים או עובדים אשר יתחברו אל המערכות ו/או יגלשו אל אתרי האינטרנט ינותבו באופן אוטומטי לעבודה מול האתר הראשי בלבד! האתר המשני יכלול לרוב את אותה התשתית ואותם שרתים אך הם יהיו מוחלשים יותר (פחות מעבד, פחות זיכרון) ואתר זה יהיה זמין לעבודה רק כאשר האתר הראשי קרס. בין האתרים יתקיימו תהליכי סנכרון מידע כך שהאתר המשני יכלול את המידע, אפליקציות, בסיסי הנתונים ויהיה ערוך להתאוששות על גביו במקרה של אסון או תקלה משביתה.
ישנם 2 פרמטרים חשובים שיש לקחת בחשבון בעת תכנון אתר חירום:
Recovery Time Objective (RTO) – פרק הזמן שייקח עד למצב בו אתר החירום יכנס לעבודה בעת תקלה. לדוגמא: במקרה של קריסה או תקלה משביתה באתר הראשי, המערכות יעברו תוך שעה לתפקוד מלא באתר החירום. זכרו שבתצורת Active-Active שני האתרים פעילים בו זמנית כך שנתון זה אינו נדרש בסוג כזה של פתרון.
Recovery Point Objective (RPO) – היקף המידע אשר ארגון מוכן לאבד במעבר לאתר חירום. לדוגמא: אנו מפעילים אתר ראשי ואתר משני בתצורת Active-Passive. במסגרת הפתרון אנו מבצעים סנכרון של המידע 4 פעמים ביום בשעות 08:00,14:00,20:00 ו – 02:00
במקרה כזה, אם החווה הראשית תקרוס בשעה 22:00 אז איבוד המידע יהיה שעתיים, זאת מאחר וסנכרון המידע האחרון היה בשעה 20:00.
גיבוי המידע והרחקה שלו לאתר חיצוני הינם פעולות חשובות במיוחד!
בין אם מדובר באתר קטן והרחקת המידע תתבצע אל המשרד או אל שירות חיצוני ועד לקיום תהליך Offsite backup או אתר DR מלא בענן עבור אתרים גדולים עתירי תשתיות מחשוב, פעולות אלו ישרתו אותנו נאמנה כאשר תתרחש תקלה בחוות השרתים.
נכתב על ידי: קובי שלום, סמנכ"ל פיתוח עסקי, שיווקי ומכירות
מוזמנים לדבר איתי 052-3546396