ניו-טק מגזין | מרץ 2019

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

לקבצים exclude . בצעו Dump וגם את ה- הפעילים. גם ככה לא תוכלו להשתמש בהם על מנת להשתחזר. לכל יצרן של תוכנת גיבוי אמורה להיות רשימה כזו, מוכנה מראש. כל מה שצריך הוא לפנות אליו / לחפש באתר שלו ולהטמיע אותה. כשמדברים על גיבוי, עולות מספר שאלות :2 מפתח. החשובות שבשאלות הן . כמה זמן אתם מוכנים לחכות עד שהמידע 1 ) RTO שאיבדתם יחזור אליכם? ( . מהי כמות המידע שאתם מוכנים לאבד 2 מנקודת הגיבוי האחרונה ועד לאסון שקרה? ) RPO ( התשובה לשאלות האלו מגיעה מתוך מדיניות הגיבוי של הארגון וכמות המשאבים הכלכליים אותם הוא מוכן להשקיע בפתרון. תחשבו על גוף ארגוני גדול כמו בנק או חברת ביטוח שעקב תקלה, בסיס הנתונים הראשי שלו אינו זמין עוד. כל שניה שעוברת בה אין אפשרות לעדכן את בסיס הנתונים או לשלוף ממנו מידע הוא קריטי וגורם לחברה הפסד כספי עצום שלא לדבר על הלקוחות המתוסכלים ועובדי החברה שמושבתים ויושבים בחוסר (אר טי RTO 0 - מעש. כלומר אנחנו זקוקים ל או אפס) שפירושו הוא שחזור של המידע הלא זמין באופן מיידי על מנת לאפשר המשך עבודה (אר פי או אפס) שיאפשר RPO 0- רציפה ול חזרה לאחת השניות האחרונות בהן המידע היה זמין מבלי לאבד שום מידע או לאפשר איבוד מינימאלי שלו. קיימות מערכות גיבוי שתומכות בפתרונות הללו אך הן מאוד יקרות. וה- RTO ככל שאנו יורדים בזמנים של ה- , לדוגמא שחזור של לפני יום, יומיים או RPO שבוע והזמן שייקח למידע לחזור אלינו כגון של שעתיים, שלוש או יותר, נצטרך להשקיע פחות כסף במערכת הגיבוי ומחירה יירד בהתאמה. קיימים סוגים שונים של גיבויים. הנפוצים מבניהם הם:

. הדרך Snapshot לגבות אותם באמצעות הפשוטה לגבות אותם תהיה להתקין עליהם סוכן גיבוי. חברות האחסון אינן מתחייבות %- בפני וירוס 100 עמיד ב Snapshot לכך ש וזוהי עוד סיבה מדוע תוכנת ransomware ה- . Snapshot גיבוי עדיפה על פני Snapshot במידה ואתם משכפלים את ה למארז אחסון נוסף, ניתן לקרוא לכך גיבוי אבל הוא יהיה די מוגבל: בדרך כלל אין קטלוג של פריטים בודדים, אין אפשרות לבצע חיפוש ואין אפשרות לשמירה שונה של פריטים שונים. retention על אחת הדרכים היעילות לבצע גיבוי של המידע הכלל ארגוני הוא באמצעות תוכנת גיבוי כגון קומוולט. בחרו בתוכנה רובסטית ונפוצה שיכולה לתת מענה לכל האפליקציות שקיימות בארגון, שיש לה תמיכה רחבה ושהיא תומכת במערכות הפעלה וגרסאות תוכנה חדשות במהירות. רצוי לבחור בתוכנה שמספקת ממשק ניהול אחיד ושעקומת הלמידה שלה היא שטוחה. אחרי שבחרנו תוכנת גיבוי, נשאלת השאלה החשובה – מה לגבות? האני מאמין שלי הוא תמיד לגבות הכל. עדיף לגבות יותר מידע מאשר לגלות שבחרנו לדלג בזמן הגדרת הגיבוי על תיקיה או כונן מסוים ובדיעבד לגלות ששם הסתתר המידע שאותו היינו צריכים. חשוב מאוד גם לבצע גיבוי לתוכנת הגיבוי (לקטלוג הראשי). בעת הצורך כאשר תוכנת הגיבוי תקרוס מכל סיבה שהיא, נוכל להתקין אותה מחדש ולהתחיל לשחזר ולגבות באופן מידי. כמובן שחשוב לא לשכוח להגדיר לתוכנת כללית שתכלול קבצי exclude הגיבוי רשימת וכדומה. עוד דוגמא להגדרה של tmp וספריות DB לקבצי exclude מניעת כפילות היא ביצוע : MSSQL של שרת , dumps בהנחה שאתם מגבים את השרת ע"י DB אין צורך לגבות אותו פעמיים: גם את ה-

התרחשות האירוע

R ecovery T ime O bjective

R ecovery P oint O bjective

שניות

שניות

דקות

דקות

שעות

שעות

ימים

ימים

שבועות

שבועות

זמן לאחר האירוע

עלות

זמן לפני האירוע

New-Tech Magazine l 34