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