גיבוי שרתים: איך בודקים שהמידע הקריטי באמת ניתן לשחזור

מה צריך להיכלל בגיבוי שרתים?

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

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

הגדירו מהו שחזור שימושי לעסק

לפני שבוחנים מוצר או תזמון גיבוי, הגדירו שני יעדים עסקיים: כמה מידע מותר לאבד, וכמה זמן אפשר לעבוד בלי המערכת. בעולם ההתאוששות הם מכונים לעיתים RPO ו-RTO. אין כאן מספר נכון אחד; היעד צריך להתאים להשפעה של השבתת אותה מערכת על העבודה, הלקוחות והצוות.

המסגרת של NIST לתכנון התאוששות מדגישה תעדוף מערכות והגדרת דרישות התאוששות. למדריך רחב יותר על סוגי גיבוי, עותקים ויעדי התאוששות, קראו את המדריך לסוגי גיבויים.

בנו מפת כיסוי פשוטה

לכל שרת או שירות קריטי, תעדו את השאלות הבאות:

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

הגנו גם על עותקי הגיבוי

עותק גיבוי שנגיש לאותה תקלה או לאותו חשבון שנפגע אינו בהכרח עותק שאפשר להסתמך עליו. מדריך CISA להתמודדות עם כופרה ממליץ לשמור עותקים קריטיים לא מקוונים או מוגנים, ולבדוק את זמינותם ואת תקינותם כחלק מתרחיש התאוששות.

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

בדיקת שחזור: הרגע שבו גיבוי הופך לראיה

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

מתי צריך להעמיק בבדיקה?

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

סיכום

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

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

מקורות

• NIST SP 800-34 Rev. 1, עקרונות לתכנון התאוששות והמשכיות.
• CISA StopRansomware Guide, הנחיות לגיבוי והיערכות להתאוששות.