הגיבוי הסתיים, הדוח ירוק ואפשר לחזור לעבודה. מעולה — אבל זו עדיין לא סיבה להיפרד ממנו לשלום. מערך גיבוי צריך תכנון, הגדרה ומעקב, ולפעמים גם טיפול בתקלה. הוא קצת כמו רכב: זה שהתניע אתמול לא אומר שאפשר לוותר על תחזוקה.
מה בודקים כשגיבוי נכשל?
- יומן ושעת הכשל
- רשת, מקום והרשאות
- בדיקה חוזרת ושחזור
גם כשהכול עובד יפה, הסביבה לא עומדת במקום. אולי עברתם משרת מקומי ליישומים בענן, ואולי המידע כבר נוצר ונשמר במקום אחר. בכל שינוי כזה צריך לבדוק אם התוכנית עדיין מכסה את מה שחשוב — ולעיתים לתכנן אותה מחדש.
גם גיבויים יכולים להיכשל. אפשר, כמובן, להתקשר לספק ולבקש עזרה, אבל העסק עדיין צריך להחזיר את המידע למצב שמאפשר עבודה. כאן נעבור על ארבע תקלות נפוצות, ונראה מה כדאי לבדוק בכל אחת.
הגיבוי קיים, אבל האם אפשר להשתמש בו?
אחת ההפתעות שפחות רוצים לקבל היא הודעת שגיאה דווקא בזמן השחזור. המערכת דיווחה שהמידע עלה לאחסון, אבל כשמנסים להשתמש בו מתברר שהוא פגום. זו לא בהכרח הסיבה הנפוצה ביותר לאובדן מידע מגובה, אבל היא בהחלט סיבה לבדוק מראש.
איך יודעים שהגיבוי שימושי? משחזרים ובודקים. כאנשי IT שמנהלים גיבויים, חשוב לבדוק גם את עקביות המידע בתדירות שמתאימה לסביבה. בלי בדיקות כאלה, גיבוי פגום יכול להישאר בשקט עד הרגע שבו תצטרכו אותו.
אלה כמה סיבות נפוצות לפגיעה במידע:
- כופרה: נוזקות הצפנה עשויות לזהות יעדי גיבוי ומידע מגובה ולהצפין גם אותם.
- מדיית גיבוי פגומה: הדבר נפוץ בעיקר במדיה מקומית. למשל, אפשר לא להבחין שדיסק במערך RAID הפסיק לעבוד. האחסון אולי ממשיך לפעול, אבל הוא קרוב יותר למצב שבו תקלה נוספת תגרום לאובדן.
- כשל בפתרון הגיבוי: אפשר לבחור ספק ותיק עם פתרון שנבדק והוכיח את עצמו. שימוש בפתרון מיושן או לא מתאים עלול להשאיר מידע לא עקבי ביעד האחסון ולמנוע שחזור של חלק ממנו.
כדי להגן מפני גיבוי פגום, בחרו פתרון עדכני בעל היסטוריה יציבה שנבדקה. חלק מהפתרונות כוללים בדיקות עקביות אוטומטיות. בנוסף, בדקו מדי פעם שאפשר לשחזר מהגיבויים שלכם.
הגיבוי שהיה אמור לרוץ — ולא רץ
לפעמים הבעיה פשוטה יותר: כולם בטוחים שיש גיבוי, אבל אף אחד לא הפעיל אותו. כשמסתמכים על הזיכרון במקום על לוח זמנים אוטומטי, יום עמוס מספיק כדי לדלג על המשימה. הזיכרון האנושי הוא כלי נהדר, אבל בתור מתזמן גיבויים יש לו ימי חופש.
וגם משימה אוטומטית יכולה להיכשל בלי שמישהו ישים לב. אם לא הוגדרו התראות, או שלא ברור מי מטפל בהן, התקלה עלולה להישאר מתחת לרדאר.
כדי לצמצם את הסיכון להישאר ללא גיבוי:
- הגדירו לוח זמנים אוטומטי.
- ודאו שמשימות הגיבוי אינן נקטעות.
- הגדירו הודעות על גיבויים שלא הושלמו.
כשהגיבוי לוקח את הזמן שלו
גיבוי שמתקדם לאט מדי אולי לא נראה כמו אירוע חירום, אבל הוא יכול להכביד על העבודה ולפגוע ביכולת לעמוד ביעדי זמן ההתאוששות ונקודת ההתאוששות. כדאי לחפש את צוואר הבקבוק, במקום רק לקוות שהפס יתקדם מהר יותר.
הסיבות העיקריות לאיטיות הן:
- חיבור אינטרנט איטי או בעיות ביצועי רשת: מצאו תזמון והגדרות שיאפשרו לנצל את קצב התעבורה המרבי האפשרי בלי לפגוע בפעילות החברה. אם אי אפשר לשפר את מהירות ההעלאה, תעדפו את המידע ובחרו איזה מידע קריטי יועלה ראשון.
- ביצועים נמוכים במחשב שמגבים: ייתכן שהמחשב עמוס במשימות בזמן שנבחר, דבר שגורם לבעיות ביצועים במהלך הגיבוי ואף להשבתת המחשב. כשבוחרים חלון גיבוי, בדקו מתי מתרחשים עומסי השיא והימנעו מהפרעה לעבודה הרגילה.
- בחירת סוג גיבוי שאינו מתאים: יש שיטות המתאימות במיוחד לגיבוי קבצים בודדים, ואחרות מעבירות עותק מלא של המחשב או של מחיצות נבחרות. בחרו את השיטה שמתאימה למידע שצריך לגבות.
יש גיבוי. עכשיו צריך גם להגיע אליו
אפשר לשמור גיבוי תקין ולהיתקע דווקא בדרך אליו: יעד האחסון לא נגיש, פרטי הכניסה אבדו או שמישהו שינה את ההרשאות. בזמן אירוע כל עיכוב כזה עולה בזמן יקר. הנה שני דברים שכדאי לבדוק:
- פרטי גישה שנשכחו או אבדו: שמרו סיסמאות במקום בטוח שאפשר לגשת אליו לפי הצורך. אל תשתפו פרטי מנהל. אם מחליפים סיסמה, עדכנו גם את מערכת ניהול הסיסמאות. המקור מציין שאין צורך בהחלפה מחזורית ללא סיבה, כגון חשד לפגיעה בסיסמה.
- פרטי גישה שנפגעו: תוקפים עשויים לשנות את פרטי הכניסה ליעד האחסון, כך שלא תוכלו להגיע לגיבויים ולשחזר. זו סיבה נוספת להגן על הסיסמאות, לבדוק ביומני הגישה אם קיימת פעילות חשודה ולהגביל משתמשים מגישה ליעד הגיבוי. צמצום הגישה מפחית את האפשרויות לפגיעה.
לא משאירים את כל העותקים באותו סל
כדי שתקלה אחת לא תיקח איתה את כל העותקים, תכננו לפי כלל 3-2-1: שלושה עותקים של המידע, שני סוגי מדיה ועותק אחד מחוץ לאתר. זה דורש השקעה ותכנון, אבל המטרה פשוטה — להשאיר דרך מעשית לשחזור גם כשחלק מהמערך נפגע.
נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.
מקור: 4 Common Backup Problems and How to Handle Them.pdf מאת MSP360. למאמר המקורי.
