תקלה בתשתית, מתקפת כופר, נפילת שירות ענן או אירוע פיזי יכולים לעצור פעילות קריטית ברגע. תכנון BCDR מחבר בין גיבוי, שחזור, סדרי עדיפויות ויעדי התאוששות כדי שהארגון ידע מה מחזירים קודם, כמה זמן אפשר להיות מושבתים וכמה מידע מותר לאבד.
מערכות ותהליכים קריטיים תחילה
יעדי זמן ואובדן מידע מוגדרים
שחזור, Failover והחזרת שירותים
בדיקות שחזור ותרגול מוכנות
שכבת אימות נוספת בהתאם לרמת הסיכון
פחות חשבונות נפרדים ומדיניות עקבית יותר
פתיחה, שינוי וסגירה מסודרת של הרשאות
ארגון יכול להיות מגובה היטב ועדיין לגלות בזמן אמת שאין לו סדר שחזור ברור, שאין יעד זמן לכל מערכת או שלא ידוע מי אחראי על כל שלב. BCDR נועד להפוך את הגיבוי מתשתית טכנית לתוכנית התאוששות שאפשר להפעיל.
המשכיות עסקית מסתכלת על הפעילות שצריכה להמשיך בזמן שיבוש. Disaster Recovery מתמקד בהחזרת מערכות, אפליקציות ונתונים. גיבוי ושחזור הם חלק מהתמונה, אבל הם אינם התוכנית כולה. התכנון צריך להתאים ליותר מתרחיש אחד, כולל כופרה, כשל תשתית, השבתת שירות ענן, טעות אנוש, אירוע פיזי באתר או פגיעה בספק קריטי.
יש גיבויים, אבל לא בוצעה בדיקת שחזור מלאה לאחרונה.
לא ברור אילו מערכות חייבות לחזור ראשונות בזמן השבתה.
הארגון עבר לענן, SaaS או סביבה היברידית והתלות בשירותים חיצוניים גדלה.
יש דרישה עסקית או חוזית לזמני התאוששות ברורים.
מתקפת כופר או אירוע קודם העלו ספק לגבי יכולת השחזור בפועל.
תוכנית טובה מחברת בין מה שהעסק חייב להמשיך לעשות לבין הדרך הטכנית להחזיר את המערכות והמידע שתומכים בו.
לא כל מערכת צריכה אותה רמת התאוששות. התכנון צריך להתחיל מההשפעה העסקית ורק לאחר מכן לקבוע את שכבות הגיבוי, השחזור והטכנולוגיה.
מזהים מה מניע את הפעילות, אילו שירותים תלויים זה בזה ומה ההשפעה של כל השבתה.
מגדירים לכל מערכת את פרק הזמן המרבי שהארגון יכול לספוג עד שהיא חוזרת לפעילות.
מגדירים כמה מידע, במונחי זמן, ניתן לאבד ומאיזו נקודת שחזור צריך להיות אפשר לחזור.
מתאימים תדירות גיבוי, סוגי עותקים, יעדי שחזור וארכיטקטורה לרמת הקריטיות של המערכות.
בוחנים Off-site, הפרדה מהסביבה הראשית ומנגנוני הגנה מפני שינוי או מחיקה בהתאם לפתרון ולסביבה.
מגדירים מי עושה מה, באיזה סדר מחזירים שירותים ואיך מאמתים שכל מערכת חזרה בצורה תקינה.
בוחנים מעבר לסביבה חלופית, Replication או מנגנוני Recovery אחרים כאשר יעדי ההתאוששות דורשים זאת.
מוודאים שהגיבוי לא רק נוצר אלא גם ניתן לשחזור, כולל בדיקת תקינות של מערכות ונתונים.
בודקים את התוכנית לאחר שינויים מהותיים ומעדכנים יעדים, תלויות וסדרי פעולה לפי הצורך.
הדרך הנכונה לבנות התאוששות מתחילה בתלות העסקית. רק אחרי שמבינים אילו תהליכים ומערכות קריטיים אפשר לקבוע RTO, RPO ולבחור את הארכיטקטורה שתעמוד ביעדים.
היעד הוא לא רק שהגיבוי הסתיים בהצלחה. היעד הוא שהעסק יוכל לחזור לעבוד בסדר הנכון ובזמן שהוגדר.
מזהים מערכות, נתונים, תהליכים, ספקים ותלויות שבלעדיהם הפעילות נפגעת באופן מהותי.
קובעים יעדי התאוששות ואובדן מידע לפי חשיבות עסקית, SLA, תלויות ורמת הסיכון.
בוחרים גיבוי, Replication, Off-site, Failover או שילוב ביניהם, ומתעדים את סדר הפעולות והאחריות.
מבצעים Restore Tests ותרגולים, בודקים פערים מול היעדים ומעדכנים את התוכנית כאשר הסביבה משתנה.
גיבוי, Disaster Recovery והמשכיות עסקית הם שכבות שונות. גיבוי שומר עותקים. DR מגדיר כיצד מחזירים מערכות ונתונים. המשכיות עסקית מסתכלת על היכולת של הארגון להמשיך להפעיל תהליכים קריטיים גם בזמן שיבוש.
גם יעדי RTO ו-RPO אינם מספרים כלליים. הם צריכים להיקבע לכל מערכת לפי ההשפעה העסקית. מערכת מכירות קריטית יכולה לדרוש התאוששות מהירה יותר ממערכת ארכיון פנימית.
בהתאם לסביבה ולפתרונות ש-Trio מספקת, טכנולוגיות כמו Veeam ו-MSP360 יכולות להשתלב בשכבת הגיבוי והשחזור. הבחירה צריכה להגיע אחרי הגדרת המערכות הקריטיות ויעדי ההתאוששות, ולא להחליף את תהליך התכנון.
פתרון BCDR אינו מוצר אחד. הוא שילוב בין קריטיות עסקית, ארכיטקטורת IT, תדירות גיבוי, יעדי התאוששות והיכולת לבדוק את התהליך בפועל.
Trio מחברת בין סביבת ה-IT, פתרונות הגיבוי והשחזור והצורך העסקי, כדי להבין מה צריך לחזור ראשון ואיך לבנות שכבות התאוששות שמתאימות לסביבה הקיימת.
ממפים מה אסור שייעצר ורק אחר כך בוחרים את שכבות הגיבוי, השחזור וה-DR.
בוחנים סדר פעולות, נקודת שחזור, יעד התאוששות ובדיקות תקינות, ולא מסתפקים בכך שקיים עותק.
On-Prem, ענן, SaaS וסביבה היברידית דורשים תכנון שונה בהתאם למערכות ולתלויות שכבר קיימות.
Trio מסייעת לחבר בין יעדי ההתאוששות לבין פתרונות הגיבוי והשחזור הרלוונטיים לסביבת הארגון.
המשכיות עסקית רחבה יותר ומתייחסת ליכולת של הארגון להמשיך תהליכים קריטיים בזמן שיבוש. Disaster Recovery מתמקד בעיקר בהחזרת מערכות IT, אפליקציות ונתונים.
לא לבדו. גיבוי בענן מספק עותק של מידע, אבל תוכנית DR צריכה להגדיר גם מה משחזרים, באיזה סדר, לאיזו סביבה, בתוך כמה זמן, מי אחראי ואיך בודקים שהשירות חזר בצורה תקינה.
RTO הוא פרק הזמן המרבי שהמערכת יכולה להיות מושבתת עד לחזרה לפעילות. RPO מגדיר כמה מידע, במונחי זמן, הארגון מוכן לאבד ולשחזר מנקודת זמן קודמת.
לא. היעדים צריכים להיקבע לפי חשיבות עסקית. מערכת שמייצרת הכנסה או תומכת בשירות קריטי יכולה להצדיק יעדים קצרים יותר ממערכת פנימית שאינה קריטית.
גיבוי שהסתיים בהצלחה אינו מוכיח שהמערכת כולה תחזור לעבוד. בדיקת שחזור בוחנת את תקינות העותק, את סדר הפעולות ואת היכולת להגיע לתוצאה שהארגון מצפה לה.
בתרחיש כופר נדרש לא רק עותק גיבוי, אלא גם יכולת לזהות נקודת שחזור נקייה, להחזיר מערכות לפי סדר עדיפות ולצמצם את הסיכון להחזיר את האיום יחד עם הנתונים.
כאשר יש שינוי משמעותי בתשתית, באפליקציות, בספקים, בתהליכים העסקיים או ברמת הקריטיות. גם בדיקת שחזור או אירוע אמיתי יכולים לחשוף פערים שמצריכים עדכון של התוכנית.
ספרו לנו אילו מערכות קריטיות לפעילות, איך נראה מערך הגיבוי היום ומה הכי מדאיג אתכם בתרחיש השבתה. נבחן יחד את שכבות הגיבוי, השחזור וההתאוששות שכדאי לחזק.
076-5993076 · הרוקמים 25, חולון
אנו משתמשים בעוגיות לצורך תפעול האתר, ניתוח נתונים ושיפור חוויית המשתמש. בלחיצה על כפתור האישור או בהמשך הגלישה באתר, הנך מסכים/ה לשימוש בעוגיות בהתאם למדיניות הפרטיות. מדיניות הפרטיות.
