מאגרי מידע

"יש לי גיבוי" זו לא תוכנית: מה באמת אומר DR והתאוששות מאסון


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

גיבוי ו-DR זה לא אותו דבר - וההבדל מעשי לגמרי

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

שני המספרים שכל מנהל צריך להכיר: RTO ו-RPO

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

RPO - Recovery Point Objective

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

RTO - Recovery Time Objective

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

איך נראית תוכנית DR שבאמת עובדת

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

  • מיפוי מערכות לפי קריטיות - לא הכול שווה בערכו. שרת ה-ERP והחנות המקוונת אינם באותה קטגוריה עם ארכיון התמונות מאירוע החברה מ-2019. לכל קבוצה נקבעים RTO ו-RPO משלה.
  • הגדרת תרחישים - כשל חומרה, תוכנת כופר, שריפה או הצפה במשרד, טעות אנוש, וכן תרחישים שהתרגלנו אליהם באזורנו כמו הפסקת חשמל ממושכת או מצב חירום ביטחוני. לכל תרחיש תגובה שונה.
  • סביבה חלופית מוגדרת - היכן הכול יעלה מחדש. שרת בענן, אתר משני, או תשתית וירטואלית שממתינה. ההחלטה הזו מתקבלת בשקט מראש, לא בפאניקה.
  • אחריות אישית ורשימת קשר - מי מקבל את ההחלטה להפעיל את התוכנית, מי מבצע, למי מודיעים. עם מספרי טלפון שלא נמצאים רק במייל שאי אפשר להיכנס אליו כרגע.
  • תיעוד נגיש - עותק מודפס או מחוץ למערכת. תוכנית DR ששמורה רק על השרת שנפל היא בדיחה ותיקה בתעשייה, ועדיין קורית.
  • תרגול תקופתי - הסעיף שהכי מדלגים עליו והכי חשוב. תוכנית שלא תורגלה היא השערה.

שלוש טעויות שחוזרות שוב ושוב

להניח שהגיבוי עובד

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

לשמור את הגיבוי במקום אחד בלבד

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

להתעלם מהאנשים

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

שאלות שעולות בשטח

אנחנו עסק קטן. באמת צריך תוכנית DR?

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

כמה זמן לוקח לבנות תוכנית כזו?

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

הכול אצלנו בענן. זה לא פותר את הבעיה?

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

כל כמה זמן צריך לעדכן את התוכנית?

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

DR מול המשכיות עסקית - הבחנה קטנה שכדאי להכיר

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

שורה תחתונה

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



נכתב ע"י: LiveDNS Ltd  אחסון אתרים | תאריך: 30/08/2026
צפיות: 28

חזרה לדף קודם