RPO ו-RTO בפשטות: כמה מידע וכמה זמן מותר לאבד

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

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

שתי שאלות שכל תוכנית התאוששות מתחילה מהן

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

RPO: כמה מידע מותר לאבד

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

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

RTO: כמה זמן מותר להיות מושבתים

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

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

איך זוכרים מי זה מי

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

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

דוגמאות מהיום-יום

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

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

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

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

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

דירוג מערכות העסק לפי דחיפות

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

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

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

מה ההבדל בין גיבוי להתאוששות מאסון

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

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

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

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

ומה לגבי זמינות גבוהה

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

יעדים שלכם מול התחייבות של ספק

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

איך קובעים יעדים, שלב אחר שלב

1. רושמים את המערכות. כל מה שהעסק משתמש בו: תוכנות, שרתים, אתר, דוא"ל וקבצים משותפים. גם שירותי ענן נכנסים לרשימה, כי גם המידע שבהם יכול להימחק.
2. שואלים מה קורה בלי כל מערכת. אחרי שעה, אחרי יום ואחרי שבוע. מי לא יכול לעבוד? אילו לקוחות נפגעים? יש דרך לעבוד ידנית בינתיים?
3. מעריכים את הנזק. לא חייבים מספר מדויק. מספיק לדעת אם השבתה של יום היא אי-נוחות, הפסד כספי ממשי או פגיעה בלקוחות ובמוניטין.
4. קובעים RPO לכל מערכת. כמה עבודה אפשר להקליד מחדש בלי נזק אמיתי? מערכת שמקבלת נתונים מלקוחות כל הזמן תקבל יעד קצר יותר ממערכת שמתעדכנת פעם ביום.
5. קובעים RTO לכל מערכת. מתי ההשבתה מפסיקה להיות מטרד והופכת לבעיה עסקית? זה היעד.
6. מתאימים את הפתרון ליעד. תדירות הגיבוי נגזרת מה-RPO. שיטת השחזור נגזרת מה-RTO: שחזור קבצים, שחזור של מכונה שלמה או התאוששות מאסון.
7. בודקים בפועל. מבצעים שחזור ניסיוני ומודדים כמה זמן הוא נמשך. אם התוצאה רחוקה מהיעד, משנים את הפתרון או את היעד.
8. חוזרים על התהליך. עסק משתנה. מערכת חדשה, עובדים נוספים או נפח מידע גדול יותר משנים את התמונה, ולכן עוברים על היעדים אחת לתקופה.

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

טעויות נפוצות

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

שאלות נפוצות

מה ההבדל בין RPO ל-RTO?

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

האם אפשר להגיע ל-RPO של אפס?

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

מי בעסק צריך לקבוע את היעדים?

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

איך יודעים שעומדים ביעדים?

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

האם גם עסק קטן צריך להגדיר RPO ו-RTO?

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

צריך התאוששות מאסון לכל השרתים?

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

רוצים לקבוע יעדים ולוודא שהם מושגים?

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