גיבוי לעסקים.
התאוששות מאסון.

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

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

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

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

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

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

לדוגמה בלבד, אם התקלה מתחילה בשעה 12:00 והעסק הגדיר RTO של ארבע שעות, יעד החזרה הוא 16:00. אם ה RPO הוא שעה, נקודת השחזור צריכה להיות מ 11:00 או מאוחר יותר. אלה יעדים להמחשה, ולא התחייבות שירות.

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

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

טבלת יעדי התאוששות למילוי משותף

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

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

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

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

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

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

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

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

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