בימינו אלו, זמינות המידע היא אחת מאבני הדרך של העולם הטכנולוגי. קחו לדוגמא את האפליקציה הכי בסיסית בטלפון הנייד שלכם: אפליקציית החייגן. ללא קו, המכשיר שנועד לשמש אתכם לשיחות הוא חסר ערך.
אם נעלה שלב ברמת האפליקציות ונסתכל על אפליקציית הדואר בה אתם משתמשים, האפליקציה שבאמצעותה אתם שולחים הודעות או המשחק האהוב עליכם: אם הם לא ייפתחו תוך זמן סביר ויספקו את התוכן שאותו אתם רוצים לצרוך, אתם תחליפו את האפליקציה או את יצרן התוכן באחד אחר. באותה נשימה, אתם תמיד מצפים לפתוח את אלבום התמונות שעל המכשיר הנייד שלכם או הענן ולמצוא שם את התמונות שצילמתם מהטיול האחרון.
אבל, לפעמים, המידע לא יהיה שם. הסיבה לכך לאו דווקא נעוצה בכם: החל מתקלות חומרה ותוכנה, פגעי טבע וכלה במעשה ידי אדם.
הפתרון לבעיה הוא די פשוט. קוראים לו גיבוי. הוא תמיד נמצא שם, כולם מדברים עליו, כולם מכירים אותו אבל לא כולם מיישמים אותו ויתרה מכך, בשלל ההוצאות של העסק או בבית, הוא תמיד נמצא במקום האחרון עד שמגיעה התקלה. והיא תגיע – תמיד היא מגיעה, בזמן שהוא הכי פחות מתאים לכם, כשאתם בלחץ ואתם חייבים את המידע או שאתם חייבים שהמערכת שקרסה תעבוד.
אבל תרשו לי להתחיל מהסוף:
מה שהכי חשוב בגיבוי הוא בעצם האפשרות לשחזר. אם נדייק, ביצוע שחזור יזום של קובץ, ספריה או ממערכת שלמה, תקטין את הסיכוי לכשל מערכתי בצורה דרמטית. דאגו לבצע שחזורים על בסיס קבוע בכדי לוודא את תקינות הגיבוי.
לא משנה אם מדובר באדם פרטי, בחברה עם 10 עובדים או בארגון עם עשרות או מאות עובדים.
גיבוי צריך להיות אחד מהדברים שצריך לתכנן, לבצע ולוודא שהוא תמיד פועל. בדיוק כמו שמשלמים את חשבון החשמל והמים. גיבוי הנתונים שלכם הוא סוג של ביטוח. אתם אף פעם לא תרצו להשתמש בו אבל תמיד תשמחו לדעת שהוא שם בכדי להגן עליכם.
הפרוש המילולי של גיבוי הוא שמירת עותק של אובייקט קיים במקום אחר, כלומר לדאוג לכך שמקור המידע והמקום אליו אתם מגבים הם שתי ישויות שונות ונפרדות לחלוטין. לדוגמא קובץ שיצרתם במחשב האישי והעתקם לספריית הקבצים הארגונית או חיבור של דיסק חיצוני למחשב האישי והעתקה של ספרית My Documents פעם בשבוע אליו.
דרך אגב, ישנם ארגונים שלא מסתפקים בשני עותקים של המידע אלא דורשים שלושה וארבעה העתקים של המידע: עותק ראשון בסביבת הייצור, עותק שני לגיבוי ארוך טווח כגון קלטות או ענן (גם בסביבת הייצור) ועותק נוסף, שלישי באתר ה-DR.
במידה ואתם משכפלים את הסנאפשוט למארז אחסון נוסף, ניתן לקרוא לכך גיבוי אבל הוא יהיה די מוגבל:
בדרך כלל אין קטלוג של פריטים בודדים, אין אפשרות לבצע חיפוש ואין אפשרות לשמירה על retention שונה של פריטים שונים.
אחת הדרכים היעילות לבצע גיבוי של המידע הכלל ארגוני הוא באמצעות תוכנת גיבוי כגון קומוולט.
בחרו בתוכנה רובסטית ונפוצה שיכולה לתת מענה לכל האפליקציות שקיימות בארגון, שיש לה תמיכה רחבה ושהיא תומכת במערכות הפעלה וגרסאות תוכנה חדשות במהירות. רצוי לבחור בתוכנה שמספקת ממשק ניהול אחיד ושעקומת הלמידה שלה היא שטוחה.
אחרי שבחרנו תוכנת גיבוי, נשאלת השאלה החשובה – מה לגבות?
האני מאמין שלי הוא תמיד לגבות הכל. עדיף לגבות יותר מידע מאשר לגלות שבחרנו לדלג בזמן הגדרת הגיבוי על תיקיה או כונן מסוים ובדיעבד לגלות ששם הסתתר המידע שאותו היינו צריכים.
חשוב מאוד גם לבצע גיבוי לתוכנת הגיבוי (לקטלוג הראשי). בעת הצורך כאשר תוכנת הגיבוי תקרוס מכל סיבה שהיא, נוכל להתקין אותה מחדש ולהתחיל לשחזר ולגבות באופן מידי.
כמובן שחשוב לא לשכוח להגדיר לתוכנת הגיבוי רשימת exclude כללית שתכלול קבצי וספריות tmp וכדומה. עוד דוגמא להגדרה של מניעת כפילות היא ביצוע exclude לקבצי DB של שרת MSSQL:
בהנחה שאתם מגבים את השרת ע”י dumps, אין צורך לגבות אותו פעמיים: גם את ה-DB וגם את ה-Dump. בצעו exclude לקבצים הפעילים. גם ככה לא תוכלו להשתמש בהם על מנת להשתחזר.
לכל יצרן של תוכנת גיבוי אמורה להיות רשימה כזו, מוכנה מראש. כל מה שצריך הוא לפנות אליו / לחפש
באתר שלו ולהטמיע אותה.

כשמדברים על גיבוי, עולות מספר שאלות מפתח. החשובות שבשאלות הן 2:
1. כמה זמן אתם מוכנים לחכות עד שהמידע שאיבדתם יחזור אליכם? (RTO)
2. מהי כמות המידע שאתם מוכנים לאבד מנקודת הגיבוי האחרונה ועד לאסון שקרה? (RPO)
התשובה לשאלות האלו מגיעה מתוך מדיניות הגיבוי של הארגון וכמות המשאבים הכלכליים אותם
הוא מוכן להשקיע בפתרון. תחשבו על גוף ארגוני גדול כמו בנק או חברת ביטוח שעקב תקלה, בסיס הנתונים הראשי שלו אינו זמין עוד. כל שניה שעוברת בה אין אפשרות לעדכן את בסיס הנתונים או לשלוף ממנו מידע הוא קריטי וגורם לחברה הפסד כספי עצום שלא לדבר על הלקוחות המתוסכלים ועובדי החברה שמושבתים ויושבים בחוסר מעש. כלומר אנחנו זקוקים ל- RTO 0 (אר טי או אפס) שפירושו הוא שחזור של המידע הלא זמין באופן מיידי על מנת לאפשר המשך עבודה רציפה ול-RPO 0 (אר פי או אפס) שיאפשר חזרה לאחת השניות האחרונות בהן המידע היה זמין מבלי לאבד שום מידע או לאפשר איבוד מינימאלי שלו. קיימות מערכות גיבוי שתומכות בפתרונות הללו אך הן מאוד יקרות.
קיימים סוגים שונים של גיבויים. הנפוצים מבניהם הם:
גיבוי מלא – בגיבוי זה אנו מבצעים שמירה של כל המידע באופן גורף. על מנת להשתחזר מגיבוי זה אנו זקוקים לגיבוי המלא האחרון בלבד.
גיבוי דיפרנציאלי – זהו גיבוי חלקי אשר מכיל את המידע אשר עודכן או נוסף מאז הגיבוי המלא האחרון.
על מנת להשתחזר מגיבוי זה אנו זקוקים לגיבוי המלא האחרון ולגיבוי הדיפרנציאלי האחרון.
גיבוי אינקרמנטלי – זהו גיבוי חלקי בו נשמרים השינויים מאז הגיבוי האינקרמטלי האחרון.
על מנת להשתחזר מגיבוי זה אנו זקוקים לגיבוי המלא האחרון ולכל הגיבויים האינקרמטלים שבצענו.
גיבוי סינטטי – זהו גיבוי מלא שנוצר משילוב של הגיבוי המלא האחרון שיצרנו בתוספת כל השינויים
שנוצרו  עד לרגע יצירת הגיבוי הסינטטי. ברגע שיצרנו גיבוי סינטטי הוא למעשה הופך לסוג של גיבוי מלא ועל כן שחזור מלא מתוך הגיבוי הסינטטי האחרון שיצרנו אפשרי ללא שימוש ביתר הגיבויים.
בחירת סוג הגיבוי היא פונקציה של חלון זמן. חלון זמן הוא הזמן הכי פחות קריטי בו אנו זקוקים למידע
או למערכת אותה אנו מגבים. בדרך כלל, הפעלה של גיבוי, מעמיסה על משאבי השרתים אותם היא מגבה: במעבד, בזיכרון ובתקשורת. אם נפעיל את הגיבוי מחוץ לחלון הזמן, זה עלול לפגוע בעובדים או בלקוחות שמשתמשים במערכת המתגבה, לכן ברוב הפעמים נרצה להפעיל את הגיבוי רק בחלון הזמן ונשתדל לא לחרוג ממנו. עבור רוב הארגונים, חלון הזמן מתחיל ב-8 בערב (כשאחרון העובדים הולך) ומסתיים ב-6 בבוקר (כשראשון העובדים מגיע לעבודה). ברוב המקרים נעדיף לבצע גיבוי מלא אך אם אין באפשרותנו לבצע גיבוי מלא מכיוון שהוא לוקח המון זמן (הוא עובר על כל המידע הקיים) נבצע גיבוי דיפרנציאלי או אינקרמנטלי במהלך השבוע ובסוף השבוע נבצע גיבוי מלא או גיבוי סינטטי.
לעיתים גיבוי של שרת פעיל אינו מספק מכיוון שהאפליקציה (השרות) שהוא מספק תפוסים על ידי מערכת
ההפעלה או גורם אחר ולא ניתן לעצור אותם. במקרה כזה, בדרך כלל ליצרן האפליקציה יש אפשרות לבצע dump יזום של המידע אותו אפשר לגבות ולשחזר ממנו את האפליקציה בקלות או אפשרות להכניס את האפליקציה ל Hot Backup Mode, בה האפליקציה מספקת שירותים הכרחיים בלבד (היא מתפקדת באופן מלא אך מאוד איטי ולפעמים מוגבל) עד אשר יסתיים הגיבוי ואז מחזירים אותה למצב רגיל.
ללא שימוש בצורה מיוחדת זו לגיבוי האפליקציה אנו נגיע למצב שנקרא Crash Consistent.
מצב זה מתייחס לשליפת כבל החשמל של השרת תוך כדי פעולה. כשננסה להדליק מחדש את השרת,
האם הוא יעלה והאפליקציה תעבוד כרגיל או שלא? הסיכוי לכך הוא 50:50. מכיוון שאנו משתמשים בגיבוי
בתור תעודת ביטוח היינו רוצים לקבל ודאות של 100% לכן ככל שנימנע יותר ממצב של Crash Consistent,
מצבנו יהיה טוב יותר.
שימו לב שקיימות מערכות נוספות בארגון כגון מתגים, נתבים, חומות אש ועוד שלא ניתן לבצע להן גיבוי
רגיל. במקרה זה מומלץ לדבר עם יצרן המערכת ולבדוק איתו מהי הדרך הנכונה והמהירה שתעזור לכם
לגבות ולשחזר מערכות אלו.
קיימת חשיבות גדולה למצע הגיבוי קרי קלטת גיבוי, דיסק, ענן וכו’. לכל אחד היתרונות והחסרונות שלו.
בשנים האחרונות עקב ירידת מחירי הדיסקים בעולם הולך וגדל שוק הגיבוי לדיסקים וקלטות הגיבוי שהיו
מקור הגיבוי העיקרי מזה שנים הולך ונעלם. אך הן עדיין קיימות ומשמשות כאחד הפתרונות היעילים ביותר לגיבוי ובפרט כנגד וירוס ה- ransomwareהידוע לשמצה. מצד שני יש לציין כי יצירת גיבוי או עותק שני על קלטת אורך הרבה זמן וגם הטיפול בקלטות (הכנסה והוצאה מספריית הגיבוי, שימוש בקלטות ניקוי, אחסון הקלטות ועוד) ובספריית הגיבוי מעיקים. מצע גיבוי יעיל יותר מגיע מצד הדיסק שהינו מהיר (ביחס לקלטת) והיום יותר זמין אך הוא יותר פגיע לווירוס ה-ransomware. אחד היתרונות הגדולים של הדיסק הוא האפשרות לביצוע של כיווץ ודי דופליקציה של מידע אשר מאפשרים (תלוי בסוג המידע) לחסוך במקום על דיסקים ובממוצע להגיע ליחס דחיסה של 1:10.
קיימים מספר פתרונות בשוק שמדברים על אפשרות נעילה מוחלטת של הגיבוי שעל הדיסק כהגנה מפני הווירוס אך מכיוון שהם אינם מופרדים פיזית ממערכת הגיבוי, עדיין קיימת האפשרות המזערית של פגיעה בהם. ההגנה היעילה ביותר נגד ווירוס ה- ransomwareהוא גיבוי לקלטות גיבוי והוצאתן באופן פיזי ובמהירות האפשרית מתוך ספריית הגיבוי. בצורה זו, אין אפשרות לווירוס לפגוע במידע שעל הקלטת, שום גורם אינו יכול לשנות אותו ולכן ההגנה של גיבוי זה היא מקסימלית.
פתרון נוסף למצע גיבוי שהולך ותופס תאוצה בשנים האחרונות הוא גיבוי לענן. היתרון של פתרון זה הוא עצום: לא נדרש כל שטח אחסון מקומי ומכיוון שרוב הזמן אנו מעבירים דלתאות הוא גם יחסית מהיר. אך יש לשים לב באיזה ענן נשמרים הנתונים, האם הוא מספיק אמין והאם בבוא יום הדין נוכל לשחזר ממנו. נקודה נוספת שצריך לחשוב עליה היא שלהחזיר כמות מידע נכבדת מתוך הענן לאתר המקומי היא פעולה שיכולה לפעמים לקחת שעות וימים. היא תלויה ברוחב הפס שלנו לענן. קיימים עננים מקומיים אשר במידה וקורה אסון ואנו זקוקים לשחזור מתוך הענן יאפשרו לנו להגיע לאתר בו מאוחסן הענן עם דיסק חיצוני על מנת שנעתיק אליו את המידע או נשחזר אותו אליו ובצורה זו נוכל לחסוך בזמן השחזור.
על מנת להבטיח רציפות עסקית של המידע מביאה חברת בינת, התמחות ומיקוד בתחום
ה-Data Protection. לצורך כך בבינת קיימים מומחים טכנולוגיים מהשורה הראשונה, לרבות  צוות ייעודי ומנוסה לתחום, המסתכל על תהליכי רציפות וגיבוי המידע, תוך התאמת פתרונות הגיבוי בהתאם לצרכים העסקיים של הלקוח. חברת בינת ביצעה עשרות פרויקטים במגוון רחב של ארגונים וחברות, ביניהם חברות בטחון, ממשלה, היי-טק, פיננסים, בריאות, אקדמיה ותעשייה.