גיבוי שרץ כל לילה עוד לא אומר שהעסק יחזור לעבוד מחר בבוקר. שירותי DR עונים על השאלה שהגיבוי לא עונה עליה: מה חוזר קודם, תוך כמה זמן, ומי מחליט.
⚡ TL;DR, תקציר מהיר
מה זה: שירותי DR כוללים עותק של המערכות במקום נפרד, תוכנית כתובה שקובעת מה חוזר קודם, ובדיקות שחזור שמוכיחות שזה עובד.
שני המספרים: RPO הוא כמה מידע מותר לאבד, RTO הוא כמה זמן מותר להיות מושבתים. Microsoft נותנת כדוגמה ארבע שעות של מידע ושמונה שעות השבתה.
הבדיקה: לפי Microsoft, תהליך שחזור שלא נבדק בתרגול, סביר יותר שייתקל בבעיות גדולות ביום האמיתי.
הצעד הראשון: רשימת המערכות שהעסק לא עובד בלעדיהן, ויעד RTO ו-RPO לכל אחת.
מה זה שירותי DR ומה הם כוללים בפועל?
שירותי DR (Disaster Recovery, התאוששות מאסון) הם מה שמחזיר את העסק לעבודה אחרי תקלה גדולה: שרת שקרס, משרד שנפגע או מתקפת כופרה שהשביתה את הרשת. שירות כזה כולל שלושה דברים: עותק של המערכות במקום אחר, תוכנית כתובה שקובעת מה מחזירים קודם ומי מחליט, ובדיקות שמוכיחות שהשחזור באמת עובד. בלי הבדיקות זו הבטחה, לא שירות.
Microsoft מפרידה בין שני סוגי סיכון, וההפרדה הזו עוזרת להבין על מה משלמים. לפי מסמך ההגדרות שלה, שעודכן ב-1 ביוני 2026, זמינות גבוהה (high availability) עוסקת בתקלות היומיומיות, ו-DR עוסק ב"uncommon risks and the catastrophic outages that can result". כלומר האירוע הנדיר שמשבית הרבה בבת אחת. אותו מסמך מונה גם אובדן או השחתה של מידע בעקבות מתקפת כופרה כסיכון שצריך לתכנן מולו, ומדגיש שהסיווג תלוי בארכיטקטורה: אותו אירוע יכול להיות תקלה יומיומית במערכת אחת ואסון במערכת אחרת. בעסק עם שרת יחיד במשרד, קריסה של השרת הזה היא כבר אירוע DR.
| גיבוי | זמינות גבוהה (HA) | התאוששות מאסון (DR) |
|---|---|---|
| מול מה זה מגן | מידע שנמחק, הושחת או הוצפן | תקלות יומיומיות: אתחול אחרי עדכון, ניתוק רשת קצר, שירות עמוס |
| במה מודדים | מתי נלקח העותק האחרון וכמה זמן הוא נשמר | אחוז זמינות. לפי Microsoft, 99.9% מאפשרים כ-43 דקות השבתה בחודש |
| מה נשאר באחריותכם | לבדוק שהשחזור עובד | להחליט כמה זמינות העסק באמת צריך |
מה ההבדל בין גיבוי ושחזור לבין DR?
גיבוי הוא עותק של המידע. DR הוא התוכנית שקובעת איך העסק חוזר לעבוד כשהמקור נפל, ובאיזה סדר. אפשר להחזיק גיבוי מצוין ועדיין לא לדעת כמה ימים ייקח להרים ממנו שרת, על איזו חומרה, ומי אמור לעשות את זה. Microsoft מונה את הגיבוי כאחד מכמה אמצעים, לצד יתירות, שכפול ומעבר לאתר משני (failover).
שני משפטים מהמסמך של Microsoft שווים הדפסה. הראשון: גיבוי שמשמש לתוכנית DR צריך להישמר "separately to the main data". עותק שיושב באותו שרת או באותו ארון תקשורת נופל יחד עם המקור. השני: שחזור מגיבוי לוקח זמן, ולכן לפי Microsoft חובה לבדוק את הגיבויים ואת תהליך השחזור כדי לוודא שהם תקינים ולהבין כמה זמן השחזור לוקח.
גיבוי ושחזור הם הבסיס, ו-DR נבנה מעליהם. אם עוד לא ברור איזה גיבוי רץ אצלכם היום, התחילו מסוגי גיבויים לעסק.
מה זה RTO ו-RPO, ואיך קובעים אותם לעסק שלכם?
RPO הוא כמות המידע שהעסק יכול להרשות לעצמו לאבד, נמדדת בזמן. RTO הוא כמה זמן העסק יכול להיות מושבת עד שהמערכות חוזרות. Microsoft נותנת דוגמאות: RPO של "four hours of data", כלומר ארבע שעות של מידע, ו-RTO של "eight hours of downtime", כלומר שמונה שעות השבתה. שני המספרים האלה הם החלטה עסקית, והם קובעים איך שירות DR ייבנה ומה הוא יעלה.
בתרשים רואים את שני היעדים משני צדי רגע התקלה. RPO נמדד אחורה, מהתקלה ועד הגיבוי האחרון, וזה המידע שיאבד. RTO נמדד קדימה, מהתקלה ועד שהמערכות חוזרות לעבוד, וזה הזמן שהמשרד מושבת. לפי Microsoft, RPO צריך להתאים לתדירות הגיבוי. גיבוי שרץ פעם בלילה לא יכול לעמוד ביעד של ארבע שעות.
איך קובעים אותם בפועל:
- רשמו את המערכות שהעסק לא עובד בלעדיהן. דואר, הנהלת חשבונות, שרת הקבצים, מערכת ה-CRM.
- שאלו על כל מערכת שתי שאלות. כמה שעות של עבודה אנחנו מוכנים להקליד מחדש? כמה שעות המשרד יכול לחכות?
- תנו לכל מערכת יעד משלה. Microsoft כותבת שלכל רכיב יכולים להיות ערכי RPO ו-RTO נפרדים. הנהלת החשבונות לא חייבת לחזור באותה מהירות כמו הדואר.
- אל תבקשו אפס. לפי Microsoft, RTO ו-RPO של אפס הם "difficult and costly to implement". היא ממליצה שהצד העסקי והצד הטכני יחליטו יחד על יעדים מציאותיים.
מה בודקים בשירות DR בענן?
שירות DR בענן משכפל את השרתים שלכם לאתר משני, וכשהאתר הראשי נופל מעבירים אליו את העבודה. Microsoft מתארת כך את Azure Site Recovery: הוא משכפל שרתים פיזיים ווירטואליים מהאתר הראשי למיקום משני, בתקלה עוברים לשם, וכשהאתר הראשי חוזר חוזרים אליו. לפי Microsoft, שכפול ל-Azure חוסך את העלות והמורכבות של אתר משני שמתחזקים בעצמכם.
לפני שחותמים, בדקו ארבעה דברים:
- מה בדיוק משוכפל. כל השרתים, או רק אלה שמישהו זכר לסמן. שרת שנוסף אחרי ההתקנה ולא נכנס לשכפול לא יחזור.
- כמה זמן לוקח המעבר. Microsoft מציינת שלוקח זמן לזהות שהאתר הראשי נפל ולעבור למשני, ושה-RTO צריך לכלול את הזמן הזה.
- איך חוזרים. החזרה לאתר הראשי (failback) היא תהליך נפרד. לפי מדריך ה-DR של Microsoft צריך לה תוכנית משלה, באותה רמת פירוט של המעבר עצמו.
- איפה המידע יושב ומי מחזיק את מפתחות ההצפנה. Microsoft ממליצה להצפין את הגיבויים ולתכנן איפה נשמרים המפתחות, כך שיהיו נגישים ביום שצריך אותם.
אם השרתים שלכם כבר מגובים לענן ואתם רוצים להבין מה בדיוק יחזור מהגיבוי הזה, גיבוי שרתים בענן עובר על זה שלב אחרי שלב.
למה תוכנית DR שלא נבדקה היא רק מסמך?
כי אף אחד לא יודע אם היא עובדת עד שמנסים. Microsoft כותבת את זה ישירות: "If you haven't tested your recovery processes in a disaster simulation, you're more likely to face major problems when using them in an actual disaster." בדיקת שחזור מלאה היא גם הדרך היחידה לדעת אם ה-RTO שכתבתם על הנייר אפשרי בכלל, או שהוא מספר שמישהו רצה לשמוע.
ראינו את זה מקרוב. באחת הבדיקות שעשינו ב-SouliTek הוזמנו כמבקר חיצוני כדי לענות על שאלה אחת: האם הגיבויים באמת עובדים. מצאנו שתי מערכות שחופפות זו לזו. Acronis ששומר שישה חודשים בלבד, בלי עותק immutable ובלי סיסמת הצפנה, ולצדו "קופסה שחורה" של אדם פרטי שמשחזרת קבצים מתוך Oracle VirtualBox בשאילתות SQL, בלי שקיפות לגבי מיקום השרתים. בדיקת שחזור מלאה על מכונת מעבדה חשפה את שתיהן.
על הנייר היו לעסק שתי מערכות גיבוי. רק בדיקת השחזור הראתה מה יש בהן בפועל.
מדריך ה-DR של Microsoft מבחין בין תרגול שולחני (tabletop), שעוזר לצוות לתרגל את התפקידים, לבין תרגול אמיתי, שהוא הדרך היחידה לוודא שהתוכנית עומדת ביעדי ה-RTO וה-RPO. את התרגול האמיתי Microsoft ממליצה להריץ קודם בסביבה שאינה סביבת העבודה.
מה צריך להיות כתוב בתוכנית התאוששות מאסון?
תוכנית התאוששות מאסון טובה עונה על שש שאלות: אילו מערכות חוזרות ובאיזה סדר, מה יעד ה-RTO וה-RPO של כל אחת, מי מכריז שזה אסון, מי מעדכן את העובדים ואת הלקוחות, איפה שמור עותק של התוכנית עצמה, ומתי בודקים אותה שוב. התוכנית לא צריכה להיות ארוכה. היא צריכה להיות ברורה למי שיקרא אותה בבוקר הכי גרוע של השנה.
מדריך ה-DR של Microsoft, שעודכן ב-19 בנובמבר 2025, מוסיף כמה פרטים שקל לפספס:
- תפקידים בשמות. מי מכריז על אסון, מי סוגר את האירוע, מי מריץ את הבדיקות ומי מנהל את התקשורת פנימה והחוצה.
- עותק מודפס. Microsoft ממליצה להחזיק "offline or printed copies" של התוכנית למקרה הגרוע. תוכנית שיושבת רק על השרת שקרס לא תעזור לאף אחד.
- עדכון קבוע. המסמך קורא לבחון את התוכנית עם כל הגורמים הרלוונטיים באופן קבוע, "ideally every six months", ובכל פעם שהסביבה משתנה.
- מה קורה אחרי המעבר. רשימת המשימות שצריך לבצע כדי להחזיר את העבודה לגמרי, ולא רק להרים את השרת.
אל תשכחו את המידע שכבר נמצא בענן. תיבות הדואר והקבצים ב-Microsoft 365 הם חלק מהתוכנית בדיוק כמו השרת במשרד, וגיבוי Microsoft 365 מסביר מה Microsoft לא מגבה בשבילכם.
מה לשאול ספק לפני שחותמים על שירותי DR?
שאלו את השאלות הבאות וקבלו תשובות בכתב לפני שחותמים. הן בודקות אם ההצעה נבנתה על המערכות שלכם או על תבנית, ואם מישהו כבר ניסה לשחזר משהו מהגיבוי. ספק שעונה עליהן בלי להתחמק כבר חשב על הסביבה שלכם. ספק שעונה "הכול מגובה" עוד לא.
- מה ה-RTO וה-RPO של כל מערכת אצלנו, ואיך הגעתם אליהם? יעד אחד לכל העסק הוא סימן שלא עשו מיפוי.
- מתי הייתה בדיקת השחזור האחרונה, ומה היא הראתה? בקשו את דוח בדיקת השחזור, לא את דוח הגיבוי היומי.
- איפה נשמרים העותקים, והאם הם מופרדים מהמידע המקורי?
- מי מחזיק את סיסמת ההצפנה של הגיבוי, ומה קורה אם הוא לא זמין?
- איך חוזרים לאתר הראשי אחרי המעבר, ומי אחראי על זה?
- כל כמה זמן התוכנית נבדקת ומתעדכנת?
אם אתם באמצע המיפוי הזה ורוצים לדעת איך תוכנית DR נראית על המערכות שלכם, גיבוי בענן לעסקים הוא המקום להתחיל בו.
שאלות נפוצות
מה ההבדל בין שירותי DR לגיבוי רגיל?
גיבוי הוא עותק של המידע. שירותי DR הם היכולת להחזיר את העסק לעבודה אחרי אירוע גדול: עותק של המערכות במקום נפרד, תוכנית שקובעת מה חוזר קודם, ובדיקות שמוכיחות שזה עובד. אפשר להחזיק גיבוי תקין ועדיין לא לדעת כמה זמן ייקח להרים ממנו את השרת. DR עונה בדיוק על השאלה הזו, מראש ובכתב.מה זה RTO ו-RPO במילים פשוטות?
RPO הוא כמה מידע מותר לאבד, נמדד בזמן: למשל ארבע שעות של עבודה שיצטרכו להקליד מחדש. RTO הוא כמה זמן העסק יכול להיות מושבת עד שהמערכות חוזרות, למשל שמונה שעות. שתי הדוגמאות האלה מופיעות במסמך ההגדרות של Microsoft. לכל מערכת בעסק יכולים להיות יעדים שונים, ויעד של אפס הוא לפי Microsoft קשה ויקר ליישום.האם גיבוי בענן מספיק במקום תוכנית DR?
גיבוי בענן פותר חלק אחד: עותק שיושב מחוץ למשרד. הוא לא קובע באיזה סדר מחזירים את המערכות, על איזו תשתית מרימים אותן, ומי מחליט שזה אסון. לפי Microsoft, שחזור מגיבוי לוקח זמן, ולכן צריך לבדוק אותו כדי לדעת כמה זמן בדיוק. בלי הבדיקה הזו אתם לא יודעים מה ה-RTO האמיתי שלכם.כל כמה זמן צריך לבדוק את תוכנית ה-DR?
מדריך ה-DR של Microsoft ממליץ לבחון את התוכנית עם כל הגורמים הרלוונטיים באופן קבוע, באופן אידיאלי כל שישה חודשים, ובכל פעם שהסביבה משתנה: שרת חדש, מעבר לענן, החלפת חומת אש. בנוסף לבחינת המסמך, Microsoft ממליצה על תרגולים. תרגול שולחני מלמד את הצוות את התפקידים, ותרגול אמיתי הוא הדרך היחידה לוודא שהיעדים אפשריים.מקורות
- Microsoft, What are business continuity, high availability, and disaster recovery?, עודכן 1 ביוני 2026. זמינות גבוהה מול DR, RTO ו-RPO, גיבוי ובדיקות שחזור.
- Microsoft, Architecture strategies for disaster recovery, עודכן 19 בנובמבר 2025. תפקידים, תרגולים, עותק מודפס ו-failback.
- Microsoft, About Azure Site Recovery, עודכן 23 בספטמבר 2026. שכפול לאתר משני, failover ו-failback.
רוצים לדעת תוך כמה זמן העסק שלכם באמת חוזר לעבוד אחרי תקלה?
המומחים שלנו ב-SouliTek ישמחו לבצע סקירה מקצועית ולהתאים עבורכם תוכנית פעולה.
יוצא עולם הסייבר ההתקפי עם למעלה מ-10 שנות ניסיון בשירותי IT לארגונים. מוביל את SouliTek במתן שירותי מחשוב מנוהלים ואבטחת מידע לעסקים קטנים ובינוניים בישראל.