גיבויים הם מותרות, מה שנחוץ הוא יכולת השחזור…

גיבויים הם מותרות, מה שנחוץ הוא יכולת השחזור…

Print Friendly, PDF & Email

כשהייתי בן 14 או 15 התוודעתי לראשונה ל-DOS, בהדרגה, התוודעתי לפקודה אחר פקודה ע"י ניסוי וטעייה. ביום שגיליתי את הפקודה Format אמא שלי גילתה את הצורך בגיבוי.

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

במשך 8 השנים האחרונות גיליתי לא פעם כי גם בקרב אנשי מקצוע – מנהלי רשת, מומחי Storage ומנהלים קיימות תפיסות שיכולות להתברר כבעייתיות במיוחד במקרה בו נדרש שחזור של מידע. למשל, בתחילת 2008 שרת דואר של ספק אינטרנט גדול המשמש לקוחות משוודיה, פינלנד, דנמרק ועוד. לאחר הקריסה נתגלה כי הגיבוי האחרון שניתן לשחזור בוצע ב-15/12/2007, כתוצאה מכך 300,000 תיבות דואר ניזוקו. לכן, במאמר זה אני מתכוון לפרט כמה מהתפיסות השגויות הבולטות במיוחד וכיצד ניתן, תוך שמירה על מספר כללים בסיסיים ליצור טכניקת גיבוי שתהיה אפקטיבית מספיק.

1. גיבוי מבוסס Snapshots: הקלות הרבה בה ניתן להגדיר גיבוי מבוסס Snapshots כמו גם סכומי העתק המושקעים במערכות Storage התומכות בשיטה זו לביצוע גיבויים מחזקת את התחושה שהגיבוי שלקח פעם מספר שעות מתבצע כעת תוך פחות מדקה וניתן לשמור דורות גיבוי רבים יותר מבעבר, בקיצור – ימי טייפ הגיבוי חלפו עברו להם. האם זה אכן כך? ובכן, אם מבינים אל נכון את אופן ביצוע גיבוי כזה ניתן להבין בקלות את "גבולות הגזרה" שלו. גיבוי מבוסס Snapshots למעשה עובד כל הזמן. הדיסק הקשיח מחולק לבלוקים כאשר בלוק בדיסק משתנה נרשם השינוי בדיסק והערך המקורי נרשם באזור ה-Snapshot, כאשר "מתבצע" Snapshot בעצם הדבר היחיד שקורה הוא שהשטח של ה-Snapshot הופך להיות Read-Only ומוקצה שטח אחר במקומו על מנת שעליו ייכתבו הערכים המקוריים טרם השינוי ולכן הגיבוי באמצעות Snapshot הוא כל כך מהיר. נושא נוסף שחשוב להבין הוא שמשום שזיכרון RAM מהיר הרבה יותר מזיכרון בדיסק הקשיח מערכות רבות (במיוחד מסדי נתונים) נוהגות להחזיק בזיכרון ה-RAM חלק גדול ככל האפשר מהנתונים ולעבד אותו שם וברגע של "מנוחה" להעביר אותם לדיסק הקשיח. כתוצאה מכך, ניסיון לשחזר נתונים שעובדו באופן כזה ע"י Snapshot נדון מראש לכישלון, כלומר הנתונים שישוחזרו יהוו רק את החלק שהיה בדיסק הקשיח באותו רגע נתון ולכן ייתכן שלא יהיה ניתן להשתמש בנתונים האלו ללא החלק שהיה בזיכרון ה-RAM באותה נקודת זמן בדיוק. חשוב לדעת שהרבה מערכות שאנו מכירים הם למעשה מבוססות על מסד נתונים או לכל הפחות על הטכניקה הזו, למשל: מערכת הקבצים של Windows, שרתי SQL, Oracle ועוד רבים וטובים. ובכן, בדיוק לשם כך קיים פתרון של יצרני ה-Storage השונים, פתרון זה בד"כ כולל תוכנת לקוח (Agent) המותקנת באותו שרת והיא מודיעה למערכת הרלוונטית (למשל SQL) לעבור ל-Backup Mode, במצב זה תכתוב המערכת את הכל ישירות לדיסק הקשיח ללא שימוש ב-RAM,מיד לאחר מכן תפנה תוכנת הלקוח הזו אל שרת ה-Storage ותבקש ממנו "לקחת" Snapshot כעת. כמובן שביצועי המערכת ייפגעו במשך פרק הזמן הזה אבל מייד לאחר ביצוע ה-Snapshot תחזיר תוכנת הלקוח את המערכת למצב הרגיל. אם כך, אז הכל מצויין? אז זהו שלא, כפי ששמת לב, התנאי לכך שיהיה ניתן להשתמש בגיבוי מבוסס Snapshot הוא שהתוכנה או המערכת שאת נתוניה מגבים עונה לפחות לאחד מהקריטריונים הבאים:
1. אינה משתמשת כלל במנגנונים העובדים תוך שימוש ב-RAM וכותבים אותם לאחר מכן לדיסק אלא כותבת ישירות לדיסק וגם אינה מסתמכת על מנגנונים שכאלו.
2. משתמשת באופן מלא וללא יוצא מן הכלל במנגנון שפועל באופן כזה ואשר קיימת עבורו תוכנת לקוח (Agent) כזו שסופקה ע"י יצרן ה-Storage.
בכל מקרה אחר, גיבוי בעזרת Snapshot יתבצע כביכול בהצלחה אך לא תמיד יהיה ניתן לשחזור כלל.

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

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

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

השאר תגובה