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