המשכיות עסקית ו-DR: מה זה RTO ו-RPO ואיך בוחרים?

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

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

מה זה בעצם RPO ומה זה RTO?

RPO (Recovery Point Objective) מגדיר את נקודת השחזור הרצויה - הפרק הזמן המרבי שממנו הארגון מוכן "לחזור אחורה" ולאבד את המידע שנוצר בו. RTO (Recovery Time Objective) מגדיר את משך ההתאוששות - הזמן המרבי שיכול לעבור מרגע התקלה ועד שהמערכת חוזרת לפעול במלואה. שני הפרמטרים משפיעים זה על זה, אבל הם לא זהים: אפשר לאבד מעט מאוד מידע (RPO נמוך) ועדיין לקחת זמן ארוך לחזור לפעולה (RTO גבוה), ולהפך.

איך קובעים ערכים לפי רמת הקריטיות של המערכת?

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

מה משפיע בפועל על העלות והבחירה

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

מי צריך לקבוע את הערכים, לא רק ה-IT

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

מהתכנון לבדיקה בפועל

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

איך RVM מלווה ארגונים בבניית תוכנית DR והמשכיות עסקית

אנחנו ב-RVM בונים לארגונים תשתית גיבוי והתאוששות מותאמת ליעדי RTO ו-RPO שנקבעו, כולל שירות DRaaS מנוהל, גיבוי מבוסס Veeam והגנה שוטפת על נקודות הקצה. הליווי כולל גם את שלב התרגול, כדי לוודא שהתוכנית עומדת במבחן המציאות ולא רק בתיאוריה.

לסיכום

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

RVM Systems | 072-244-2222

שאלות נפוצות

מה קורה אם לא מגדירים RTO ו-RPO מראש?

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

כמה פעמים כדאי לתרגל תוכנית DR?

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