רוב העסקים בישראל חושבים שגיבוי זה מספיק. זה לא. גיבוי אומר שיש לכם עותק של המידע — DRP אומר שאתם יודעים בדיוק מה לעשות כשהכל קורס. הבדל של שעות בין שחזור מוצלח לבין שיתוק עסקי מלא.
מה זה DRP ולמה כל עסק צריך אחד
DRP (Disaster Recovery Plan) הוא מסמך ותהליך שמגדיר כיצד הארגון ישחזר את מערכות ה-IT שלו לאחר אירוע קיצוני: מתקפת כופרה, כשל חומרה קריטי, שרפה, הצפה, כשל בספק ענן, או כל תרחיש שמשבית את הפעילות.
DRP הוא לא מסמך שיושב במגירה. הוא תוכנית פעולה חיה שנבדקת באופן קבוע. ארגון בלי DRP עובד — כמו נהג בלי ביטוח: הכל בסדר עד שזה לא.
DRP מול BCP — ההבדל
**DRP** עוסק בשחזור מערכות IT. **BCP** (Business Continuity Plan) עוסק בהמשכיות עסקית כוללת: כוח אדם, מיקום פיזי, תקשורת עם לקוחות, ספקי משנה. DRP הוא חלק מ-BCP, לא תחליף לו.
חמישה רכיבים חיוניים של DRP
1. הגדרת תרחישי אסון
לא כל אירוע הוא אסון. DRP מגדיר את התרחישים שדורשים הפעלת התוכנית:
| תרחיש | סיכוי | השפעה | |--------|--------|--------| | מתקפת כופרה | גבוה | קריטי | | כשל Storage ראשי | בינוני | קריטי | | שרפה בחדר שרתים | נמוך | הרסני | | כשל ספק ענן ראשי | נמוך-בינוני | גבוה | | נפילת חשמל ממושכת | בינוני | בינוני-גבוה | | טעות אנוש (מחיקת נתונים) | גבוה | בינוני |
לכל תרחיש: מה הנזק הצפוי? כמה זמן הארגון יכול לעבוד בלי המערכת? מי מושפע ראשון?
2. יעדי שחזור — RTO ו-RPO
שני המדדים הקריטיים ביותר ב-DRP:
**RTO (Recovery Time Objective)** — כמה זמן מרגע האירוע עד שהמערכת חוזרת לעבוד. RTO של 4 שעות אומר: תוך 4 שעות המערכת חייבת לפעול.
**RPO (Recovery Point Objective)** — כמה מידע מותר לאבד. RPO של שעה אומר: הגיבוי האחרון חייב להיות לא יותר משעה לפני האירוע.
איך קובעים אותם? שאלו את מנהלי הפעילות: "כמה שעות בלי מערכת X גורמות לנזק בלתי הפיך?" — זה ה-RTO. "כמה עבודה אתם מוכנים לבצע מחדש?" — זה ה-RPO.
**דוגמה מעשית:** - מערכת ERP: RTO = 2 שעות, RPO = 15 דקות - אימייל (Exchange/M365): RTO = 1 שעה, RPO = 0 (שכפול בזמן אמת) - אתר אינטרנט: RTO = 4 שעות, RPO = 24 שעות - מערכת CRM: RTO = 4 שעות, RPO = 1 שעה
3. צוות DRP
תפקידים שחייבים להיות מוגדרים לפני שהאירוע קורה:
- **מוביל DRP** — מי שמחליט להפעיל את התוכנית. בדרך כלל מנהל IT או CISO.
- **צוות שחזור טכני** — מי שמבצע את השחזור בפועל. פנימי, ספק MSP, או שילוב.
- **מתקשר ניהולי** — מי שמדווח להנהלה ולבעלי עניין.
- **מתקשר חיצוני** — מי שמדווח ללקוחות, ספקים, ובמידת הצורך — לרגולטור.
- **מתאם לוגיסטי** — מי שמטפל בתשתית פיזית (חדר שרתים חלופי, חיבורי רשת, ציוד).
4. Runbook — מדריך שחזור צעד-אחר-צעד
Runbook הוא הלב של DRP. מסמך טכני שמפרט בדיוק: מה עושים, בסדר מה, ועם אילו כלים.
**מבנה Runbook מוצלח:** 1. אימות שהאירוע אכן דורש הפעלת DRP 2. הודעת הפעלה לצוות (מספרי טלפון, ערוצי תקשורת חלופיים) 3. בידוד מערכות נגועות (במקרה של מתקפת סייבר) 4. שחזור מערכות לפי סדר עדיפות — מערכות קריטיות קודם 5. אימות שלמות מידע לאחר שחזור 6. העברת תעבורה למערכות המשוחזרות 7. מעקב ותיעוד
**טיפ מהשטח:** Runbook טוב כתוב ברמה שטכנאי ג׳וניור יכול לבצע אותו. אם המומחה הראשי לא זמין (ויש סיכוי טוב שהוא לא יהיה) — מישהו אחר חייב להיות מסוגל לרוץ עם התוכנית.
5. בדיקות DRP
DRP שלא נבדק — לא קיים. נקודה.
**סוגי בדיקות:** - **Tabletop Exercise** — סימולציה על נייר. הצוות יושב ועובר על תרחיש. "מה עושים כש...?". עלות נמוכה, ערך גבוה. כל רבעון. - **בדיקת שחזור חלקית** — שחזור מערכת אחת מגיבוי לסביבה מבודדת. חודשי. - **Full DR Drill** — שחזור מלא לאתר חלופי. שנתי. יקר אבל הכרחי.
אסטרטגיית אתר חלופי
שלוש רמות של אתר DR:
| סוג | RTO | עלות | מתי מתאים | |------|------|-------|-----------| | Hot Site | דקות-שעה | גבוהה | מערכות קריטיות, 24/7 | | Warm Site | שעות | בינונית | רוב העסקים | | Cold Site | ימים | נמוכה | מערכות לא קריטיות |
**Hot Site** — שרתים פעילים עם שכפול בזמן אמת. כשל → מעבר אוטומטי. יקר, מתאים לבנקים, בתי חולים, חברות SaaS.
**Warm Site** — תשתית מוכנה, גיבויים עדכניים. צריך שעות ספורות להפעלה. המודל המומלץ לרוב העסקים.
**Cold Site** — מקום פיזי עם חשמל ורשת, בלי שרתים. ימים של עבודה. מתאים רק לגיבוי של גיבוי.
DRP בענן — האם זה משנה את הכללים?
כן ולא. ענן מקל על חלק מהאתגרים (אין חדר שרתים פיזי שנשרף) אבל מוסיף אחרים: - **כשל Region** — מה קורה אם Azure Israel East נופל? האם יש לכם שכפול ל-Region אחר? - **Lock-in** — האם אתם יכולים לשחזר ל-AWS אם Azure לא זמין לפרק זמן ארוך? - **גישה** — האם יש לכם גישה לכלי הניהול אם ה-VPN נפל?
צ׳קליסט מהיר: האם ה-DRP שלכם מוכן?
- [ ] תרחישי אסון מוגדרים ומתועדים
- [ ] RTO ו-RPO מוגדרים לכל מערכת קריטית
- [ ] צוות DRP ממונה עם פרטי קשר עדכניים
- [ ] Runbook כתוב ומעודכן לרבעון האחרון
- [ ] בדיקת Tabletop בוצעה ברבעון האחרון
- [ ] שחזור מגיבוי נבדק בחודש האחרון
- [ ] אתר חלופי (Hot/Warm/Cold) מוגדר ופעיל
- [ ] תקשורת חלופית מוגדרת (לא תלויה בתשתית הראשית)
איך DLTS בונה DRP לעסקים
אנחנו לא כותבים מסמך ושמים אותו במגירה. התהליך שלנו: 1. **סקר תשתיות** — מיפוי כל המערכות, תלויות, ונקודות כשל 2. **הגדרת RTO/RPO** — עם ההנהלה, לא רק עם IT 3. **כתיבת Runbook** — ברמת פירוט שכל טכנאי מוסמך יכול לבצע 4. **הקמת אתר DR** — ענן, On-Prem, או היברידי 5. **בדיקות תקופתיות** — Tabletop רבעוני, DR Drill שנתי 6. **עדכון שוטף** — כל שינוי תשתית → עדכון DRP
[דברו איתנו על בניית DRP](/contact)
שאלות נפוצות
**כמה עולה לבנות DRP?** תלוי בגודל הארגון ומורכבות התשתית. לעסק של 50–200 עובדים: הקמת DRP לוקחת 30–60 יום ועלותה נעה בין ₪15,000 ל-₪40,000 כפרויקט חד-פעמי, בתוספת עלות שוטפת לתחזוקת אתר DR.
**מה ההבדל בין DRP ל-BCP?** DRP מתמקד בשחזור מערכות IT. BCP מכסה את כל ההיבטים של המשכיות עסקית: צוות, מיקום, תקשורת, ספקים, לוגיסטיקה. DRP הוא רכיב אחד בתוך BCP.
**כמה פעמים צריך לבדוק DRP?** Tabletop — כל רבעון. שחזור חלקי — כל חודש. Full Drill — לפחות פעם בשנה. אחרי כל שינוי תשתיתי משמעותי — בדיקה נוספת.
DRP Testing — למה לתרגל
DRP שלא נבדק = אין DRP. 75% מהעסקים שיש להם DRP מגלים בעיות קריטיות במבחן הראשון. עדיף לגלות בתרגיל מאשר באסון אמיתי.
3 רמות בדיקה
- **Tabletop (שולחני):** צוות יושב ועובר על התרחיש. "מה היינו עושים אם..." — מזהה חורים בתהליך. זמן: שעה.
- **Simulation:** מדמים כשל (כיבוי שרת Test) ורצים את התהליך. בודקים שהגיבוי עובד, שהצוות יודע מה לעשות. זמן: חצי יום.
- **Full DR Test:** Failover אמיתי לסביבת DR. משתמשים עובדים מ-DR Site. הבדיקה האמיתית — אבל הכי מפחידה. זמן: יום מלא.
קראו גם: [BCP — תוכנית המשכיות](/blog/bcp-la-asakim) | [DR Test](/blog/dr-test-la-asakim)