עותק נתונים הוא התחלה. החזרת שירות דורשת תוכנית.
גיבוי נתונים עסקיים נועד לאפשר שחזור. התאוששות מאסון (Disaster Recovery, או DR) עוסקת גם בהחזרת מערכת ושירות לפעילות, כולל תשתיות, תלויות וסדר עבודה.
| מושג | המטרה העיקרית | מה צריך לבדוק |
|---|---|---|
| אחסון | שמירת מידע וגישה אליו | האם קיימות נקודות חזרה והגנה על עותקים |
| סנכרון | עדכון קבצים בין מיקומים | האם גם מחיקה או השחתה עוברות הלאה |
| גיבוי | שמירת עותקים או נקודות לשחזור | כיסוי, שמירה ויכולת שחזור בפועל |
| שכפול | העברת שינויים לסביבה אחרת | פער הנתונים, נקודות חזרה ותלות במקור |
| DR | החזרת מערכת או שירות לאחר שיבוש | תשתית יעד, זהויות, רשת, תהליך ובדיקות |
במסך צר אפשר לגלול את הטבלה לרוחב.
משימת גיבוי שהצליחה אינה הוכחה שהמערכת תחזור לעבוד. בדיקת שחזור בוחנת גם את המידע וגם את היכולת להשתמש בו בתרחיש שנבדק.
פתרונות גיבוי והתאוששות המוצגים באתר
באתר ITEAM מוצגים פתרונות גיבוי Acronis, אחסון Cloud Storage S3 ופתרונות גיבוי והתאוששות מאסון — Backup & DR.
מפרט השירות צריך לפרט את המערכות המכוסות, המדיניות, הטיפול בכשלים והאחריות לשחזור. יעד אחסון, תוכנת גיבוי ותוכנית התאוששות ממלאים תפקידים שונים במערך.
הסברים על טכנולוגיות וארכיטקטורות בהמשך הם מידע מקצועי כללי; הם אינם פירוט של חבילת שירות אחידה.
אילו מערכות ונתונים נכללים בתוכנית?
ממפים את השירות העסקי ואת הרכיבים הדרושים להפעלתו. גיבוי שרת אינו בהכרח כיסוי של כל התלויות שלו.
- שרתים ויישומיםשרתים פיזיים, מכונות וירטואליות, מסדי נתונים ויישומים — לפי הסביבה והמוצר התומך בהם.
- קבצים ותחנותמידע צוותי, מסמכים ונתונים שנשמרים בתחנות עבודה. בודקים מה ייחודי ומה כבר נשמר במערכת אחרת.
- זהויות ותצורהרשת, הגדרות שירות, הרשאות, רישיונות ותיעוד הנדרשים להחזרת הפעילות.
- סביבות ענן ו־SaaSבודקים כיסוי לכל שירות ולכל סוג נתון; נוכחות בענן אינה מגדירה תוכנית גיבוי.
מפתחות ופרטי גישה הנדרשים להתאוששות צריכים להיות מוגנים ונגישים לגורמים מורשים לפי מדיניות הארגון.
ומה לגבי Microsoft 365?
בודקים מנגנוני שמירה ושחזור קיימים ואת הצורך בפתרון גיבוי לפי השירותים והנתונים. Microsoft 365 Backup הוא שירות ייעודי, לצד פתרונות אחרים; אין להסיק שקיים כיסוי מלא או שחייבים דווקא מוצר צד שלישי.
להיקף השירות: תיעוד Microsoft 365 Backup. הדוגמאות כאן מיועדות למיפוי ואינן הצהרה שכל סוגי המערכות נכללים בשירות ITEAM.
איך בונים מדיניות גיבוי שימושית?
מדיניות מחברת בין מה שנשמר לבין מה שנדרש לשחזר. היא צריכה להתעדכן כשמערכות, נפחי מידע או צורכי העסק משתנים.
- כיסוי וסיווגמגדירים מערכות, בעלי אחריות וחשיבות עסקית. מתעדים גם החרגות.
- תדירות ונקודות שחזורמתאימים את אופן יצירת נקודות השחזור לשינויי המידע וליעד ה־RPO.
- תקופת שמירה — Retentionקובעים כמה זמן נשמרות נקודות שחזור ואילו דרישות עסקיות ומשפטיות אושרו.
- הפרדת עותקיםבוחנים הפרדה מהמקור והגנה מפני כשל או פגיעה משותפים.
- הרשאות והצפנהמגינים על חשבונות הגיבוי, מצמצמים הרשאות ומגדירים הצפנה וניהול מפתחות לפי הפתרון.
- ניטור ובדיקותמגדירים מי מקבל התראות, מי מטפל בכשל ואיך בודקים ומתעדים שחזור.
עותק מנותק
עותק שאינו נגיש ברציפות דרך הסביבה הפעילה. בודקים איך הוא מתעדכן ואיך ניגשים אליו לצורך שחזור.
עותק עם הגבלת שינוי או מחיקה
מנגנון הגנה בהתאם למוצר, לתקופה ולמצב ההגדרה. הוא יכול להיות מקוון; חשוב לבדוק גם הרשאות וחריגים.
CISA ממליצה על גיבויים מנותקים ומוצפנים של מידע קריטי ועל בדיקת זמינות ושלמות בתרחיש התאוששות: מדריך StopRansomware. דוגמה למנגנון מוצר: Amazon S3 Object Lock.
3-2-1 הוא כלל אצבע, לא הוכחת מוכנות. שלושה עותקים, שני סוגי מדיה ועותק אחד מחוץ לאתר הם מסגרת נפוצה. עדיין צריך לבדוק הפרדה, הגנה ויכולת שחזור.
RPO ו־RTO — שתי שאלות עסקיות שונות
קובעים יעדים לכל שירות לפי ההשפעה של שיבוש, התלויות והעלות של החלופות.
RPO: כמה מידע אפשר לאבד?
יעד לנקודה בזמן שאליה נדרש לשחזר. הוא מבטא, בטווח זמן, את אובדן הנתונים המרבי שהארגון מוכן לקבל.
RTO: תוך כמה זמן השירות צריך לחזור?
יעד הזמן להחזרת מערכת או שירות לפעילות לאחר שיבוש. הוא כולל את תהליך ההתאוששות ולא רק העתקת קבצים.
למשל, שיקולי ההתאוששות של מערכת עסקאות יכולים להיות שונים מאלה של מאגר מסמכים היסטורי. זו דוגמה לתכנון, ולא המלצה ליעד או התחייבות לזמן שחזור.
להגדרות ולתכנון: Microsoft — אסטרטגיות התאוששות מאסון. יעד נבדק בתרגול; הוא הופך להתחייבות חוזית רק אם כך הוגדר בהסכם.
איך בודקים שהגיבוי ניתן לשימוש?
בדיקת שחזור צריכה להיות מתוכננת ולהוכיח את התרחיש שהוגדר. תוצאה טובה בבדיקה אחת אינה אישור לכל המערכות ולכל סוגי הכשל.
בחירת תרחיש וגבולות
קובעים אם בודקים קובץ, מסד נתונים, מכונה או שירות שלם. מגדירים סביבת בדיקה ואישור מראש.
בחירת נקודת שחזור
בודקים שהיא זמינה ומתאימה לתרחיש ושיש הרשאות ומשאבים הנדרשים לשחזור.
בדיקת נתונים ויישום
מאמתים שלמות, פתיחה ושימוש, בהתאם למערכת. בדיקת קובץ לבדה אינה בדיקת שירות עסקי שלם.
בדיקת תלויות וגישה
בוחנים זהויות, רשת, תצורה וגישה של משתמשים רלוונטיים בסביבה שנבדקה.
תיעוד ותיקון פערים
מתעדים תוצאה, זמן, חריגים ופעולות תיקון. חוזרים על בדיקה כששינוי או פער מצדיקים זאת.
שלושה תרחישים לבדיקה
קובץ נמחק
בודקים אם קיימת נקודת שחזור מתאימה, אם הקובץ נפתח ואם ההרשאות מאפשרות לעובד להשתמש בו.
שרת אינו זמין
בודקים גם את היישום, מסד הנתונים, הרשת והזהויות שנדרשים להחזרת השירות.
המשרד אינו נגיש
בוחנים היכן המערכת תפעל, כיצד העובדים יתחברו ואילו תלויות נשארו באתר המקורי.
אלה תרחישים כלליים להמחשה, ולא פרויקטים או הבטחות שירות של ITEAM.
תדירות הבדיקות והיקפן נקבעים במדיניות ובמפרט. לאחר אירוע אבטחה, החזרת מערכת לפעילות דורשת תיאום עם תוכנית התגובה ובדיקת נקודת השחזור והסביבה.
להעמקה בנושא אירועים: מאמר ITEAM על תגובה למתקפת כופרה.
מה כוללת תוכנית התאוששות מאסון?
תוכנית DR מגדירה איך מחזירים שירות, מי מחליט ומי מבצע. היא יכולה להסתמך על שחזור מגיבוי, אתר חלופי או סביבה בענן, לפי צורכי המערכת.
- תעדוף ותלויותמזהים שירותים קריטיים ואת סדר החזרת הרכיבים שמאפשרים להם לעבוד.
- חלופת התאוששותמגדירים תשתית יעד, גישה וקיבולת, ומוודאים התאמה ליעדים ולתקציב.
- Runbook — נוהל ביצועמתעדים תנאי הפעלה, בעלי תפקידים, שלבי שחזור ובדיקות קבלה.
- תרגול וחזרה לשגרהבוחנים את התוכנית ומגדירים איך חוזרים לסביבה הראשית ומעדכנים תיעוד.
מקור לתכנון: NIST SP 800-34 Rev. 1 — הגרסה המעודכנת. זהו מקור הנחיות, ולא הסמכה או מפרט שירות של ITEAM.
להקשר ענני: טעויות במעבר לענן. גיבוי המאוחסן בענן אינו כשלעצמו שירות DRaaS הכולל הפעלה וניהול של סביבת התאוששות.
Active-Active לעומת Active-Passive
אלה דפוסי ארכיטקטורה, ולא סוגי גיבוי או שמות מוצר. הבחירה תלויה בעומס העבודה ובאופן שבו המידע נכתב ונקרא.
| דפוס | אופן הפעולה | מה דורש תכנון |
|---|---|---|
| Active-Active | מספר סביבות משרתות פעילות במקביל | ניתוב, עקביות נתונים, כתיבה ותלות בין רכיבים |
| Active-Passive | סביבה פעילה וסביבה משנית להתאוששות | מצב מוכנות, קיבולת, פער נתונים ושלבי מעבר |
במסך צר אפשר לגלול את הטבלה לרוחב.
ב־Active-Passive מוכנות הסביבה המשנית עשויה לנוע מ־Cold דרך Warm ועד Hot. בשני הדפוסים מגדירים מעבר לחלופה (Failover), בדיקות וחזרה לסביבה הראשית (Failback).
שכפול וזמינות אינם מחליפים נקודות שחזור. שינוי שגוי או השחתה עלולים לעבור גם לסביבה השנייה, בהתאם למנגנון. יש לתכנן הגנת נתונים בנפרד.
אין דפוס שמבטיח לבדו אפס השבתה או אפס אובדן. להרחבה: AWS — אפשרויות התאוששות בענן. מורכבות ועלות נבחנות לפי המימוש.
Veeam, HPE Zerto ואחסון S3
שם הטכנולוגיה הוא נקודת התחלה לבדיקה. צריך לבחון מוצר, גרסה, רישוי, מערכות נתמכות ותשתית יעד.
Veeam Backup & Replication
פתרון לגיבוי ושחזור, עם יכולות שכפול והתאוששות לפי המוצר והסביבה. התאמתו נבדקת מול כיסוי הנתונים, נקודות השחזור והדרישות התפעוליות.
הגנת נתונים רציפה והתאוששות
HPE Zerto מבוסס על CDP — הגנת נתונים רציפה — ומשלב שכפול ותזמור התאוששות. יש לבחון כיסוי, תשתית, נקודות חזרה והפעלה בפועל.
Veeam ו־Zerto אינם חלופות זהות בכל תרחיש. אף אחד מהם אינו מימוש אוטומטי של Active-Active. ההסבר כאן אינו הצהרה ש־ITEAM משווקת או תומכת במוצרים האלה.
S3 הוא רכיב אחסון, לא תוכנית שחזור מלאה
אחסון אובייקטים בממשק S3 יכול לשמש יעד במערך גיבוי. צריך לבדוק את ספק האחסון, התאימות, ההרשאות ויכולות ההגנה. תמיכה בממשק S3 אינה הוכחה שכל יכולות Amazon S3 זמינות או מופעלות.
מה לבדוק בהצעת שירות גיבוי?
שירותי גיבוי לעסקים צריכים להיות מתוארים לפי כיסוי ואחריות. כך אפשר להשוות פתרונות שנותנים מענה לאותו צורך.
- כיסוי והחרגותאילו מערכות ונתונים כלולים, ומה נדרש לגבות בנפרד?
- מדיניותמהי תדירות יצירת נקודות השחזור וכמה זמן הן נשמרות?
- מיקום והפרדההיכן העותקים נמצאים ומה מפריד אותם מהמקור ומחשבונותיו?
- הגנת עותקיםהאם קיים עותק Offline או Immutable, ומהם התנאים וההרשאות?
- טיפול בכשליםמי בודק התראות, מי מטפל ובאילו שעות?
- שחזור ותרגולמי מאשר ומבצע שחזור, ואילו בדיקות כלולות?
- יעדי התאוששותהאם RPO/RTO הם יעדים מתוכננים או התחייבות חוזית?
- עלות כוללתמה מושפע מנפח, שמירה, תעבורה, רישוי ותשתית התאוששות?
שאלות נפוצות על גיבוי והתאוששות
מה ההבדל בין גיבוי בענן לסנכרון קבצים?
סנכרון מעביר שינויים בין מיקומים ויכול להעביר גם מחיקות. גיבוי מתוכנן לשמור עותקים או נקודות שחזור. היכולת לחזור למידע תקין תלויה במדיניות ובהגנות של הפתרון.
האם גיבוי בענן הוא גם התאוששות מאסון?
לא בהכרח. גיבוי מאפשר שחזור נתונים; DR כולל גם תשתיות, תלויות ותהליך להחזרת השירות. שחזור מגיבוי יכול להיות חלק מתוכנית DR.
מה ההבדל בין RPO ל־RTO?
RPO מתאר את אובדן הנתונים המרבי שהארגון מוכן לקבל, בטווח זמן. RTO מתאר את יעד הזמן להחזרת השירות לפעילות. מגדירים ובודקים אותם לכל מערכת.
כל כמה זמן צריך לבדוק שחזור?
לפי חשיבות המערכת, קצב השינויים והמדיניות. מגדירים מראש היקף ותדירות ומבצעים בדיקות נוספות לאחר שינויים או כשלים רלוונטיים. אין תדירות אחידה לכל עסק.
האם Offline ו־Immutable הם אותו דבר?
לא. Offline מתייחס לעותק שאינו נגיש ברציפות דרך הסביבה הפעילה. Immutable מתייחס להגבלת שינוי או מחיקה לפי הגדרת המוצר, ויכול להיות מקוון. בשניהם בודקים גם גישה ושחזור.
האם Microsoft 365 כולל אפשרויות גיבוי ושחזור?
קיימים מנגנוני שירות לשמירה ולשחזור, וגם Microsoft 365 Backup ופתרונות אחרים. בודקים כיסוי, מדיניות והפעלה לפי הצורך; אין להסיק שכל הנתונים מוגנים רק מעצם קיום המנוי.
האם Active-Active מחליף גיבוי?
לא. זהו דפוס להפעלת מספר סביבות במקביל. הגנה מפני מחיקה או השחתה ובחירת נקודת שחזור דורשות תכנון נפרד, גם כאשר קיימת סביבת פעילות נוספת.
לקריאה נוספת
מדריכים באתר ITEAM
מקורות מקצועיים
- CISA — StopRansomware Guideגיבויים מוגנים ובדיקת זמינות ושלמות.
- NIST SP 800-34 Rev. 1הנחיות לתכנון התאוששות מערכות מידע; גרסה מעודכנת.
- Microsoft — אסטרטגיות DRיעדי התאוששות ותכנון החזרת שירות.
- AWS — אפשרויות DR בענןדפוסי התאוששות ושיקולי מימוש.
- AWS — S3 Object Lockמנגנון להגבלת שינוי או מחיקה.
- Microsoft 365 Backupסקירת שירות הגיבוי של Microsoft.
- Veeam Backup & Replicationיכולות גיבוי, שחזור ושכפול לפי מוצר.
- HPE ZertoCDP ותזמור התאוששות.
מקורות התוכן נבדקו ב־7 באוקטובר 2026. יכולות מוצר דורשות אימות לפי גרסה, רישוי ותצורה ואינן מפרט שירות של ITEAM.