מעל 72% מהעסקים מעריכים כי הם לא מצליחים לעמוד בציפיותיהם לשחזור ה-IT ביחס למטרות נקודת השחזור (RPO) וזמן השחזור (RTO) שלהם.
כדי לסייע לך ליצור תוכנית שחזור יעילה, חשוב לך לפתח הבנה מלאה של RTO ו-RPO וללמוד על ההבדלים. הפוסט הזה מסביר את כל מה שצריך לדעת על שני הפרמטרים האלה לאסטרטגיה אמינה לשחזור מזיקות. קרא כדי לגלות כיצד ניתן להשיג RPO ו-RTO יותר צמודים כדי למזער אובדן המידע ולחדש את הפעילות העסקית הרגילה בהקדם האפשרי לאחר מקרה זיקוק.
מהו RTO?
מטרת זמן השחזור (RTO) מתייחסת לכמות הזמן המרבית שארגון יכול להתמודד עם זמן ריחוק לאחר אירוע מפריע. במילים אחרות, RTO היא תקופת הזמן בין התרחשות האסון לשחזור של עבודות קריטיות שנתפסו.
חישוב RTO תלוי לרוב בתוכנית השחזור מקרים, המשאבים הזמינים שלך והתקציב. בזמן שהתשתית ה-IT שלך אינה זמינה, תצטרך לזמן מסוים כדי לזהות את הסיבה(ות) לכישלון ולקחת את הפעולה הנדרשת כדי לתקן את הבעיה. עם זאת, צריכים להיות שלבי שחזור מקרים במקום כדי לוודא שהמערכות והעומסים הקריטיים נגישים וזמינים בעת פתרון בעיה ביצור.
מהו RPO?
מטרת נקודת השחזור (RPO) מייצגת את הכמות המרבית של נתונים שארגון יכול לעמוד בהם במקרה של אסון בלי השלכות קריטיות. המדד הזה מתוכנן בשעות/דקות מאז התהליך האחרון של גיבויים/שיבוץ. ניתן להשתמש בו כדי לקבוע כמה פעמים צריך ליצור גיבויי נתונים ושיבוצים כדי להפחית את אובדן הנתונים לאחר אירוע מפריע.
במצב אידיאלי, תהליך גיבוי או שיבוץ מושלם נגמר דקות לפני שהמכונה המקורית נכשלת. עם זאת, מצב כזה נדיר בחיי היומיום, לכן יש פער בין הרגע שבו נוצר הגיבוי האחרון המוצלח והרגע שבו המכונה המקורית נכשלת. במהלך זמן זה, ה-VM ביצע פעולות ואחסן נתונים, וסביר שנתונים אלו יאבדו.
מהו RTO ו-RPO בשחזור מקרי אסון
המטרה הסופית של הגנת נתונים היא ברורה: אתה רוצה להיות בטוח שנתונים קריטיים אינם אבודים אם משהו הולך לא נכון ושתוכל לעמוד בהסכמי רמת שירות (SLA) של הארגון שלך במונחים של זמינות וזמן פעילות. עם זאת, זה די יקר לשקף את כל השינויים בסביבה הווירטואלית שלך לאתר התאוששות מאסונות (DR) בזמן אמת. לכן אתה צריך לקבל את הרעיון שתאבד קצת נתונים ושירותי ה-IT שלך יופסקו במקרה של תקלה. כך שהמשימה שלך היא למזער את ההפסדים וההפסקות האלה.
בואו נמחיש את המושגים של RPO ו-RTO בתרשים פשוט:
התרשים מראה תרחיש נפוץ: מכונה וירטואלית קורסת מסיבה כלשהי. הקו הצהוב מייצג את ה-RPO, שהוא הזמן בין הגיבוי האחרון לבין ההפרעה. הקו הכתום הוא ה-RTO ומשקף את הזמן הנדרש לשחזר את ה-VM.
הבדלים בין RTO ל-RPO
כדי להבין איך לקבוע את ה-RTO וה-RPO, עליך להסתכל על ההבדלים שלהם ועל תפקידם בתהליך ה-DR.
הערכה
- הזמן הרגעי להחזרת התפעול בעקבות אסון מעניין בעיקר את תקופת הזמן בה צפוי להתחדש תפעול העסק במהלך אסון. הנקודות שיש לשקול הן:
- להעריך את צרכי ועדיפויות הארגון שלך, שהם ייחודיים לכל ארגון.
- לשקול אילו יישומים הם הכי בסיסיים עבור השירותים והיישומים הכריטיים להישרדות הארגון, וגם מה עשינוי המצפים להיות אם יישומים אלו יכשלו.
- לקבוע את הסדר בו יש לשחזר כל מערכת/יישום כדי להבטיח שחזור מוצלח של אסון עם הפסדי זמן מינימליים.
- זמן נקוב חוזר ממוקד יותר על כמות הנתונים שניתן לאבד במהלך זמן עצירה מבלי לגרום נזק חמור לתחתית הקו של ארגון. הנקודות שיש לשקול הן:
- לזהות את תדירות הגיבוי/השכפול, וכמה נתונים עשויים להיאבד בין הגיבוי האחרון של VM ולאסון אמיתי.
- לשקול את כמות הנתונים שארגונך יכול להרשות לעצמו לאבד לכל סוג של עומס עבודה.
עלויות
ההבדל העיקרי בין RTO ו-RPO הוא שהראשון מתחשב בכל הנושאים של מבנה העסק ותהליך השחזור מקיף, בעוד שהשני רק מתייחס לחיוניות הנתונים והיישומים לרציפות העסקית. לכן, עמידה בערכי RTO עשויה להיות משימה מתקשה ויקרה כדי לוודא שהשחזור יהיה מהיר. באותו אופן, ככל שיש RPO קטנים יותר זה אומר שעליך לבצע יותר גיבויים וליצור נקודות שחזור נוספות שעשויות להגביר את עלויות האחסון שלך.
אוטומציה
- מאחר ש-RPO מתמקד בנתונים וביכולת ההתמודדות של המערכת שלך עם אובדן, מומלץ להפעיל גיבויים תכופים. רבים מפתרונות הגיבוי המודרניים מאפשרים לך לבצע גיבויים אוטומטיים של MV, מה שאומר שאפשר להתאים את אסטרטגיות הגיבוי שלך בדרך שתענה על מטרות ה-RPO שלך ביעילות, ועם פחות התערבות מצידך.
- להשיג RTO הוא תהליך מורכב יותר לניהול, מכיוון שהוא מתחשב בכל התהליכים העסקיים והרכיבים המערכתיים שיש לשחזר במהלך אירוע שחזור דחוף. אומרים, מומלץ לאוטומציה ולאורכסטרציה של תהליך השחזור המלא מההתחלה ועד לסיום כדי לוודא שמטרות ה-RTO שלך יכולות להישג.
נוחות בחישוב
- המדד RPO קל לחישוב, מאחר והוא מכסה רק אספקט אחד של תהליך השחזור – הנתונים.
- RTO מתייחס לכל האספקטים של הארגון שלך, כולל חשיבותם של הנתונים והשירותים שלך, עלות הזמן הלא פעיל, השקעה בפעילויות DR, וכו'. בעת חישוב RTO, עליך לקחת בחשבון את סוגי העומסים והיישומים השונים מאחר ויכולים להיות להם תהליכי שחזור שונים. מומלץ לחשב את ה-RTO על סמך תוכנית המשך עסקית, שמתארת את הסיכונים והאיומים העסקיים האפשריים, ומתארת את הצעדים שיש לנקוט כדי לשוב לתהליכי העסק.
כדי להגדיר את ה-RTO המתאים לעומסי העבודה השונים בארגונים שלך, ענה על השאלה הבאה:
כמה זמן יכולה להיות אפליקציה/מערכת/מכונה מסוימת מושבתת ללא השפעה משמעותית על פעולות הליבה של הארגון שלך?
לאחר עניית השאלה זו עבור מכונות שונות, שקול האם התוצאות הצפויות יכולות לשבע את צרכי העסק שלך כרגע. אם לא, חשוב על איך תוכל לשפר את תוכניות הגיבוי וה-RTO שלך כדי לשמור על הנתונים המגובים כמעט ככל הניתן.
כיצד להשיג RPO ו-RTO צמוחים עם NAKIVO
NAKIVO Backup & Replication מאפשר לך ליצור גיבויים של מכונות וירטואליות ופיזיות בתדירות גבוהה יותר, משפר את ה-RPO. פשוט תזמן גיבויים רגילים במרווח שאינו גדול מהמטרה שלך.
הפתרון מסייע גם בצמצום RTO באמצעות התאוששות מיידית של מכונות וירטואליות ותפקוד השכפול עבור VMware vSphere, Microsoft Hyper-V ו- Amazon EC2. שילוב שירותי ניטור הרשת והפעלת תהליך התאוששות מיד עם מכונה וירטואלית הופכת לזמינה. ניתן גם ליצור עותקים זהים מדויקים) של מכונות וירטואליות קריטיות באתר מרוחק. אם המכונה הווירטואלית המקורית נכשלה, עותקים זהים יופעלו אוטומטית. אם אחזקת העותקים דורשת יותר משאבים מכפי שאתה יכול להרשות לעצמך, באפשרותך לבחור בתכונת האתחול המיידי של מכונה וירטואלית מהגיבוי.
כדי להשיג את יעדי ה- RTO התובעניים ביותר, NAKIVO Backup & Replication הציגה את תפקוד תזמורת התאוששות האתר. אוטומציה מלאה של כשל מעליות ומעברי כשל עבור תרחישי DR שונים וביצוע בדיקות ללא הפרעה כדי להבטיח התאוששות במסגרת הזמן הצפויה.