הגיבוי ירוק. השחזור עוד לא נבדק. זה ההבדל בין ״נראה בסדר״ לבין ״ניסינו, וזה עובד בתרחיש שבדקנו״. קל לחשוב שכופרה, כשל חומרה או מחיקה בטעות קורים רק למישהו אחר. אבל מערך גיבוי צריך יותר מאופטימיות טובה: הוא צריך בדיקות מסודרות.
הוכחה שהגיבוי שימושי
- שחזור למיקום נפרד
- פתיחת קבצים והפעלת יישום
- מדידת הזמן ותיעוד
כשלא בודקים, עלולים לגלות מאוחר מדי שהגיבוי נכשל, שהשחזור איטי מהצפוי או שהתשתית בכלל לא מוכנה אליו. המחיר יכול להיות אובדן מידע, הזדמנויות עסקיות, תפוקה וכסף.
במקום לחכות לאירוע, בנו תוכנית מסודרת לבדיקת הגיבויים. המדריך הזה יעזור לתכנן בדיקות שמראות אם המידע שנשמר באמת ניתן לשחזור.
מתחילים מרשימה, גם אם הכול כבר בראש
הצעד הראשון הוא לתעד את תהליכי הגיבוי. גם אם מנהל המערכת מכיר הכול, וגם אם מנהל המערכת הוא אתם, הרשימה עדיין חשובה. יש לכך שתי סיבות טובות:
- האדם שמכיר את מערך הגיבוי עשוי להיעדר או לעזוב את החברה. בלעדיו, אתם או מנהל מערכת חדש עלולים להשקיע זמן רב בהבנת התשתית. במהלך אסון, חוסר הידע הזה עלול להאריך את ההשבתה.
- גם אנשי המקצוע הטובים ביותר עלולים להתבלבל בפרטים טכניים או לשכוח אותם כשהמצב יוצא משליטה ונוצר לחץ.
רשמו את כל הגיבויים, הסוגים שלהם, הגדרות השימור והחומרה שנדרשת לגיבוי ולשחזור. הוסיפו גם את חישובי זמן ההתאוששות ונקודת ההתאוששות. בהמשך תוכלו להשוות את התוצאות לתוכנית, במקום לנחש אם ״זה היה די מהר״.
בודקים את שני צדי התהליך
גיבוי שומר את המידע; שחזור מחזיר אותו לשימוש. צריך לבדוק את שתי הפעולות. הצלחה בהעתקה לא בהכרח אומרת שהיישום יעלה, שהקבצים ייפתחו או שהשירות יחזור בזמן.
בדיקות גיבוי
בנו מיפוי של כל רכיב תשתית וכל סוג מידע שצריך לגבות. אלה הבדיקות הבסיסיות שכדאי לבצע בקביעות:
- בדיקת תשתית הגיבוי: במערך מקומי, בדקו את בריאות הדיסקים באמצעות נתוני S.M.A.R.T ואת התקני ה־NAS. בגיבוי לענן, בדקו את עקביות הקבצים שנשמרו באחסון.
- בדיקת עקביות המידע: חלק מפתרונות הגיבוי כוללים אפשרות לבדוק את עקביות המידע במחשב וביעד האחסון, כדי לסייע בבדיקת שלמותו.
- בדיקת כיסוי התשתית: גם אם כבר רשמתם את כל תוכניות הגיבוי, ייתכן שחסר רכיב חיוני. ערכו סקירה של התשתית וודאו שכל מה שקריטי לחברה נכלל בגיבוי.
- בדיקת הגדרות אבטחה: האם מופעלת הצפנה בזמן העברה ובאחסון? האם נדרשת גם הצפנה של שמות הקבצים? למי יש גישה ליעד הגיבוי? במדיניות ההרשאות פעלו לפי עקרון ההרשאות המזעריות.
בדיקות שחזור
המקור מציע את הכללים הבאים כדי להרחיב את היכולת לשחזר מידע כשצריך:
- בדקו ביחס ליעדי RTO ו־RPO: היעדים מגדירים באיזו מהירות צריך להתאושש וכמה מידע אפשר לאבד במקרה של השבתה. אם טרם הוגדרו, יש לחשב אותם לפני הערכת תוצאות השחזור.
- הגדירו את היקף הבדיקות: התחילו בבדיקות הפשוטות והתקדמו לתרחישים מורכבים. בדקו באופן קבוע שחזור קובץ בודד, מחשב או שרת יחיד, עם התשתית הנלווית ובלעדיה, שחזור רכיבים תלויים ברשת ובתשתית, ולבסוף התאוששות מאסון בתרחישים שונים.
- קבעו לוח זמנים: בדיקות סדירות מאפשרות לזהות שינויים בתשתית. בנוסף, יש לתכנן אותן כך שלא יפגעו בפעילות העסקית, למשל מחוץ לשעות העבודה.
- תעדו הכול: תעדו את המועדים, ההיקף, הבדיקות המדויקות ותוצאותיהן, חישובי RTO ו־RPO, האנשים המורשים לבצע את הבדיקות וחברי צוות נוספים שיש ליידע.
עדיף לגלות את הפער בתרגיל
בדיקות גיבוי ושחזור אולי לא מתחרות בחופשה הבאה על מידת ההנאה, אבל הן מאפשרות לבדוק מראש איך מחזירים את התשתית לפעילות אחרי אסון, טעות אנוש או תקלה. זו עבודה שגרתית עם ערך גדול מאוד.
בסביבה שמשלבת מערכות מקומיות, ענן ותלויות בין שירותים, גם רכיב קטן יכול להשפיע על השחזור. הכינו סביבת בדיקה מתאימה ובדקו שכל מה שחיוני לעסק מכוסה. ככה השקט התפעולי נשען על תוצאות, ולא רק על תחושת בטן.
נוסח עברי מלא המבוסס על גוף המאמר בקובץ ה־PDF שסופק, בעריכת שפה לקריאה נוחה. הערות דיוק ותיקונים למקור מסומנים בנפרד. דוגמאות הסבר נוספו לפי הצורך; תפריטי אתר, מודעות וקישורי המלצות אינם חלק מגוף המאמר.
מקור: Backup Testing Best Practices.pdf מאת MSP360. למאמר המקורי.
