שירותי גיבוי בענן לעסקים – גיבוי, אבטחה ושחזור מידע

שירותי גיבוי בענן לעסקים – גיבוי, אבטחה ושחזור מידע

פורסם ב 27-01-2026

שירותי גיבוי בענן מאפשרים לשמור עותקים של קבצים, מסדי נתונים, אתרים ומערכות מחשוב בתשתית מרוחקת, כדי לשחזר אותם במקרה של מחיקה, תקלה או אירוע אבטחה. פתרון מתאים אינו מסתכם בשטח אחסון: הוא משלב מדיניות גיבוי, שמירת גרסאות, בקרת גישה ותהליך שחזור שניתן לבדוק מראש.

בעסק שמסתמך על מידע דיגיטלי, השאלה החשובה אינה רק “האם יש לנו גיבוי?”, אלא גם “האם הוא כולל את כל המידע הנחוץ, עד כמה הוא מעודכן וכמה זמן יידרש לחזור לעבוד?”.

במדריך הזה נבחן כיצד פועל גיבוי בענן, מה ההבדל בינו לבין אחסון וסנכרון קבצים, איך מתכננים את הגיבויים ואילו שאלות כדאי לשאול לפני שבוחרים ספק.

מה זה גיבוי בענן?

גיבוי בענן, או Cloud Backup, הוא יצירת עותק של מידע ושמירתו בתשתית ענן, בנפרד מהמידע המשמש לעבודה השוטפת. בעת הצורך משתמשים בעותק כדי לשחזר קבצים, נתונים או מערכת שלמה.

למרות השם, המידע אינו נשמר במקום מופשט. מאחורי שירותי הענן פועלים שרתים ומערכות אחסון בחוות שרתים. הגישה אליהם מתבצעת דרך האינטרנט או חיבור תקשורת ייעודי, בהתאם לפתרון.

המטרה היא לשמור עותק שאפשר להסתמך עליו גם כאשר סביבת העבודה המקורית נפגעת. לכן לא מספיק שהמידע נמצא “בענן”: חשוב לבדוק היכן נשמר הגיבוי, כיצד הוא מופרד ממערכת המקור ומי יכול לשנות או למחוק אותו.

איך פועלים שירותי גיבוי בענן?

תהליך הגיבוי מתחיל במיפוי המידע, ולא בבחירת נפח האחסון. יש להגדיר אילו מערכות וקבצים חיוניים לפעילות העסקית, ואז לבנות עבורם מדיניות מתאימה.

בחירת המידע לגיבוי. מגדירים את השרתים, התיקיות, מסדי הנתונים והיישומים שייכללו בתהליך. חשוב לבדוק גם מה מוחרג ממנו, כדי שלא לגלות בזמן תקלה שמערכת חשובה כלל לא גובתה.

הגדרת מדיניות. קובעים מתי יבוצעו הגיבויים, כמה גרסאות יישמרו, למשך כמה זמן והיכן יאוחסנו העותקים.

ביצוע הגיבוי. תוכנה או שירות ייעודי מעבירים את הנתונים ליעד הגיבוי. בהתאם לטכנולוגיה, ניתן להעביר את כל המידע או רק את השינויים מאז גיבוי קודם.

ניטור ושחזור. עוקבים אחר השלמת המשימות, מטפלים בכשלים ומבצעים בדיקות שחזור. כשנדרש שחזור אמיתי, בוחרים את המידע ואת נקודת הזמן הרצויה ומחזירים אותם לסביבה המתאימה.

אוטומציה מפחיתה את התלות בעבודה ידנית, אך אינה מבטלת את הצורך בפיקוח. גיבוי מתוזמן שלא הושלם או שאינו כולל את הנתונים הנכונים לא יספק את ההגנה שתוכננה.

מי אחראי על הגיבויים: העסק או ספק הענן?

ספק שירותי ענן מפעיל את השירות על גבי תשתיות מחשוב שהוא מנהל, בבעלותו או באמצעות ספקי תשתית אחרים. האחריות שלו אינה בהכרח כוללת את כל הפעולות הנדרשות להגנה על המידע שלכם.

יש הבדל בין רכישת שטח אחסון לגיבויים, שימוש בתוכנת גיבוי ושירות גיבוי מנוהל. במקרה הראשון, העסק עשוי להיות אחראי להגדרות, לניטור ולשחזור. בשירות מנוהל, חלק מהמשימות עשויות להתבצע על ידי הספק, בהתאם להסכם.

לפני ההצטרפות, הגדירו במפורש מי בוחר מה לגבות, מי מקבל התראות, מי מטפל בכשל ומי מבצע שחזור. אל תניחו שהמילים “שירות מנוהל” או “אחסון בענן” אומרות שכל המידע מגובה אוטומטית.

למה גיבוי בענן חשוב לעסקים?

התאוששות מטעויות וממחיקה. מחיקת תיקייה, עדכון שגוי או שינוי במסד נתונים עלולים לפגוע במידע הנחוץ לעבודה. שמירת גרסאות מאפשרת לחזור לעותק שקדם לשינוי, כל עוד הוא עדיין נשמר.

צמצום התלות באתר הפיזי של העסק. כאשר הגיבוי נמצא במיקום נפרד, תקלה מקומית, גניבת ציוד או נזק למשרד אינם חייבים לפגוע גם בכל עותקי המידע.

פחות התעסקות בתשתית הגיבוי. שירות ענן עשוי לצמצם רכישה ותחזוקה של ציוד מקומי ייעודי. עם זאת, עדיין צריך לנהל את מדיניות הגיבוי ולבחון את העלות הכוללת.

התאמה לצמיחה. ניתן לבחור פתרון שמאפשר להגדיל נפח, להוסיף מערכות ולשנות את מדיניות השמירה בהתאם להתפתחות העסק וליכולות הספק.

היתרון העסקי אינו עצם קיומו של עותק נוסף, אלא היכולת להשתמש בו כדי לצמצם אובדן מידע והפרעה לפעילות.

אילו סוגי מידע ומערכות ניתן לגבות בענן?

בהתאם לתוכנת הגיבוי ולשירות הנבחר, אפשר לגבות מסמכים ותיקיות עבודה, מחשבים, שרתים פיזיים ווירטואליים, מסדי נתונים, מערכות ניהול לקוחות, מערכות הנהלת חשבונות ואתרי אינטרנט. קיימים גם פתרונות לגיבוי תיבות דואר ומידע מיישומים עסקיים בענן.

חשוב להבדיל בין תמיכה בסוג קובץ לבין תמיכה בשחזור מערכת פעילה. גיבוי של מסד נתונים או יישום עסקי צריך להתאים לאופן הפעולה שלהם, כדי שניתן יהיה לשחזר מידע תקין ועקבי ולא רק אוסף קבצים.

גיבוי אתרי WordPress וחנויות מקוונות

גיבוי מלא של אתר WordPress טיפוסי צריך לכלול גם את קובצי האתר וגם את מסד הנתונים. הקבצים כוללים, בין היתר, תוספים, תבניות, תמונות והגדרות; מסד הנתונים מכיל תכנים ונתונים שהמערכת מנהלת. העתקת תיקיית האתר לבדה אינה בדרך כלל גיבוי של מסד הנתונים.

בחנות מקוונת חשוב לתכנן גם כיצד משחזרים בלי לדרוס מידע חדש. לדוגמה, החזרת האתר כולו לגיבוי מאתמול עשויה להסיר מהמערכת הזמנות שנקלטו מאז. לכן כדאי לבחון מראש אפשרויות לשחזור ממוקד ולשמירת הנתונים שנוספו לאחר נקודת הגיבוי.

לפני עדכון משמעותי מומלץ ליצור גיבוי נוסף, אך לא להסתמך עליו במקום מדיניות גיבוי שוטפת.

מה ההבדל בין גיבוי בענן, אחסון בענן וסנכרון?

אחסון בענן הוא מושג רחב: שמירת מידע על תשתית מרוחקת לצורך עבודה, שיתוף, הפעלת יישומים או שימושים אחרים.

סנכרון נועד לשמור על התאמה בין קבצים במיקומים שונים. כתוצאה מכך, גם מחיקה או שינוי שגוי עלולים לעבור בין המכשירים והענן.

גיבוי נועד לאפשר חזרה למצב קודם. לשם כך נדרשים עותקים, נקודות שחזור ומדיניות שמירה שמתאימים לתרחישי אובדן המידע של העסק.

חלק משירותי הסנכרון מציעים היסטוריית גרסאות ושחזור קבצים שנמחקו. אלה יכולות מועילות, אך צריך לבדוק את משך השמירה, היקף השחזור וההרשאות. העובדה שקובץ מופיע גם במחשב וגם בענן אינה מוכיחה שקיים גיבוי עצמאי שיגן עליו בכל תרחיש.

סוגי גיבויים: מלא, אינקרמנטלי ודיפרנציאלי

גיבוי מלא יוצר עותק של כל המידע שנבחר לגיבוי. הוא מספק בסיס לשחזור, אך עשוי לדרוש זמן העברה ונפח אחסון משמעותיים.

גיבוי אינקרמנטלי שומר את השינויים מאז הגיבוי הקודם. הוא עשוי לצמצם את כמות הנתונים המועברת, אך השחזור תלוי בשיטה שבה המערכת שומרת ומרכיבה את נקודות השחזור.

גיבוי דיפרנציאלי שומר את השינויים מאז הגיבוי המלא האחרון. ככל שמצטברים שינויים, הגיבוי עשוי לגדול. במודל הקלאסי, השחזור דורש את הגיבוי המלא ואת הגיבוי הדיפרנציאלי הרלוונטי.

יש מערכות המשלבות שיטות נוספות, כמו יצירת גיבוי מלא סינתטי מתוך עותקים קיימים. לכן לא כדאי לבחור פתרון לפי שם השיטה בלבד: בדקו כמה זמן הגיבוי צורך, כמה מקום הוא תופס וכיצד נראה השחזור בפועל.

גיבוי בענן או גיבוי מקומי – מה עדיף?

אין תשובה אחת שמתאימה לכל עסק. גיבוי מקומי יכול לאפשר שחזור מהיר ברשת הפנימית, ואילו גיבוי בענן יכול לספק עותק מרוחק וגמישות תפעולית. במקרים רבים, שילוב ביניהם נותן מענה רחב יותר.

שיקול	גיבוי מקומי	גיבוי בענן
מיקום העותק	התקן או מערכת מקומיים	תשתית ענן, במיקום שיש לברר
שחזור נפח גדול	עשוי להיות מהיר ברשת המקומית	תלוי בתקשורת, באחסון ובפתרון השחזור
תחזוקת החומרה	באחריות העסק או ספק המחשוב שלו	באחריות ספק התשתית
הרחבת נפח	עשויה לדרוש ציוד נוסף	תלויה בתנאי השירות ובמשאבים הזמינים
הגנה מאירוע מקומי	מוגבלת אם המקור והגיבוי באותו מקום	טובה יותר כאשר נשמרת הפרדה מתאימה
אבטחה	דורשת תכנון ובקרה	דורשת תכנון ובקרה, גם בענן

ההבדלים האלה מדגישים מדוע צריך לבחון את מיקום העותקים ואת חלוקת האחריות, ולא להסתפק בהגדרה “מקומי” או “בענן”. JetServer

גישה מוכרת לתכנון גיבויים היא כלל 3-2-1: שלושה עותקים של המידע בסך הכול, כולל המקור, על שני סוגי מדיה, כשעותק אחד לפחות נמצא מחוץ לאתר המרכזי.

זהו בסיס לתכנון, לא הבטחה להגנה מלאה. צריך לבדוק גם הפרדת הרשאות, אפשרות לפגיעה בכמה עותקים יחד והגנה מפני מחיקה. שתי תיקיות על אותו כונן אינן מספקות הפרדה מפני כשל של הכונן.

כל כמה זמן צריך לגבות ולכמה זמן לשמור גרסאות?

תדירות הגיבוי צריכה להיגזר מכמות המידע שהעסק מוכן לאבד, ולא מברירת המחדל של התוכנה.

תדירות הגיבוי: כמה מידע אפשר לאבד?

המונח RPO – יעד נקודת ההתאוששות מתאר את חלון הזמן המרבי של אובדן מידע שהוגדר כמקובל. לדוגמה, RPO של שעה פירושו שהפתרון צריך להיות מתוכנן כך שניתן יהיה לשחזר לנקודה שאינה ישנה ביותר משעה ביחס לאירוע, בתרחיש שלשמו תוכנן.

נניח שחנות מגובה בכל לילה בחצות ונפגעת בשעה 16:00. אם אין מקור שחזור נוסף, הגיבוי האחרון אינו כולל את הפעילות שנוספה מאז חצות. במקרה כזה, צריך לבחון אם גיבוי יומי אכן מתאים לעסק.

המונח RTO – יעד זמן ההתאוששות מתייחס לפרק הזמן המרבי שהוגדר להחזרת השירות לפעילות לאחר הפרעה. זהו יעד נפרד: גיבוי תכוף אינו מבטיח שחזור מהיר.

תקופת השמירה: כמה רחוק אפשר לחזור?

תדירות הגיבוי ומשך שמירתו הם שני דברים שונים. גיבוי שמתבצע מדי שעה אך נשמר לזמן קצר לא בהכרח יעזור לגלות ולתקן מחיקה ישנה.

אפשר לשלב עותקים תכופים לטווח הקצר עם עותקים יומיים, שבועיים או חודשיים לתקופות ארוכות יותר. המדיניות צריכה להתאים לחשיבות המידע, לזמן שעלול לחלוף עד גילוי תקלה, לנפח האחסון ולדרישות העסק.

לדוגמה, אם תיקייה נמחקה והדבר התגלה רק כעבור שבועיים, צריך שתישמר נקודת שחזור שקדמה למחיקה. שמירת הגיבוי האחרון בלבד אינה מספיקה לתרחיש הזה.

אבטחת מידע והגנה על הגיבויים מפני כופרה

גיבויים הם חלק ממערך ההתאוששות, אך גם הם עלולים להיות יעד לתקיפה. לכן צריך להגן על מערכת הגיבוי עצמה ולא רק על המערכת העסקית.

הצפנה וניהול הרשאות

בדקו שהפתרון מספק הצפנה בזמן העברת המידע ובזמן אחסונו, ומי מנהל את מפתחות ההצפנה. יש לתכנן גישה למפתחות גם במצב חירום, בלי לחשוף אותם למשתמשים שאינם מורשים.

הגבילו הרשאות לפי תפקיד, הפעילו אימות רב־שלבי והפרידו ככל האפשר בין הרשאות ניהול הייצור לבין הרשאות מחיקת הגיבויים. גישה לחשבון אחד אינה צריכה לאפשר בקלות פגיעה בכל העותקים.

גיבויים מבודדים או בלתי ניתנים לשינוי

עותק מנותק או מבודד מצמצם את החשיפה לתקיפה של הסביבה הפעילה. יכולות Immutable Backup מאפשרות, בהתאם למימוש ולהגדרות, למנוע שינוי או מחיקה של גיבויים במהלך תקופת שמירה מוגדרת.

חשוב לבדוק מה בדיוק נעול, למשך כמה זמן והאם קיימות הרשאות שעשויות לעקוף את ההגנה. הצפנה לבדה אינה מונעת מחיקה של הגיבוי.

גם גיבוי מוגן אינו מונע חדירה למערכות או דליפת מידע. לאחר אירוע כופרה צריך לזהות נקודת שחזור תקינה, לטפל בגורם הפגיעה ולוודא שהסביבה שאליה משחזרים בטוחה לשימוש.

איך בודקים שהגיבוי באמת ניתן לשחזור?

הודעה שהגיבוי הסתיים בהצלחה היא סימן חשוב, אך היא אינה תחליף לבדיקת שחזור.

בדיקה מעשית צריכה לכלול שחזור קובץ או מערכת לסביבת בדיקה מתאימה, פתיחת הנתונים והפעלת היישום. יש לוודא שהמידע הנחוץ קיים, שההרשאות מתאימות ושהמערכת מתפקדת כמצופה.

חשוב גם למדוד את הזמן הכולל: איתור הגיבוי, קבלת גישה, הכנת סביבת היעד, העברת המידע, הפעלת השירות ובדיקת תקינותו. זמן הורדת הקבצים לבדו אינו משקף בהכרח את זמן החזרה לעבודה.

תעדו את שלבי השחזור ואת בעלי התפקידים, וחזרו על הבדיקה בהתאם לקריטיות המערכת ולאחר שינויים משמעותיים. כך אפשר לזהות מראש תלות בסיסמה, במפתח הצפנה או באדם יחיד.

מה ההבדל בין גיבוי בענן להתאוששות מאסון?

גיבוי מתמקד בשמירת מידע וביכולת לשחזר אותו. התאוששות מאסון, Disaster Recovery, עוסקת בהחזרת מערכות ושירותים לפעילות לאחר אירוע משמעותי.

לדוגמה, עותק של מסד הנתונים אינו מספיק לבדו כדי להפעיל מערכת עסקית אם השרת, הרשת והרשאות הגישה אינם זמינים. תוכנית התאוששות צריכה להתייחס גם לתשתית חלופית, לתלויות בין המערכות, לסדר ההפעלה ולבדיקות.

עסק שיכול להמתין לשחזור שונה מעסק שנדרש לחזור לפעילות במהירות רבה. לכן כדאי להתאים את פתרון ההתאוששות מאסון ליעדי ההתאוששות שהוגדרו, ולא להסתפק בשאלה האם קיים גיבוי.

גיבוי בענן לעסקים בישראל: היכן כדאי לשמור את המידע?

מיקום הגיבוי צריך להיבחר כחלק מתכנון הסיכונים. שאלו היכן נמצאות המערכות הראשיות, היכן עותקי הגיבוי והאם אירוע אחד עלול לפגוע בכולם.

אפשר לשלב עותקים במיקומים גאוגרפיים שונים, בהתאם לדרישות העסק ולשירות הזמין. עם זאת, מרחק פיזי אינו תחליף להפרדת הרשאות ולהגנה על החשבונות.

לפני הבחירה, בדקו גם את דרישות הארגון לגבי מיקום המידע, זמינות התמיכה בעברית ובשעות הפעילות הנחוצות, ואפשרויות השחזור כאשר אחד האתרים אינו זמין. את ביצועי ההעברה והשחזור כדאי למדוד בפועל, ולא להסיק אותם רק מהמדינה שבה נמצא השרת.

איך בוחרים ספק שירותי גיבוי בענן?

התחילו מתרחישי השחזור שלכם, ורק לאחר מכן השוו חבילות. בקשו מהספק מענה ברור לשאלות הבאות:

תחום לבדיקה	מה כדאי לברר?
התאמה למערכות	מה ניתן לגבות ומה ניתן לשחזר: קובץ, מסד נתונים, תיבת דואר או שרת שלם?
מדיניות הגיבוי	מה התדירות, כמה זמן נשמרות גרסאות ומה קורה כשמשימה נכשלת?
ממשק ותפעול	האם ניתן לראות היסטוריה, לקבל התראות ולבצע שחזור עצמאי?
הפרדה והגנה	היכן העותקים נשמרים, מי יכול למחוק אותם וכיצד מוגנת תשתית הגיבוי?
תמיכה ואחריות	מי מטפל בתקלה, באילו שעות ומי אחראי לביצוע השחזור?
תנאי השירות	מה מובטח בהסכם רמת השירות, כיצד מודדים זאת ומהם החריגים?
מעבר לספק אחר	באיזה פורמט אפשר לקבל את הגיבויים, ומהן עלויות הייצוא והשחזור?

בקשו לבדוק גם אישורים ודוחות אבטחה רלוונטיים, כגון הסמכה ל־ISO/IEC 27001 או דוח SOC 2. אלה אינם אותו סוג מסמך, וחשוב להבין לאיזה ארגון, שירות ותקופה הם מתייחסים. אין בהם תחליף לבירור ההגנות של השירות המסוים.

הבחינו במיוחד בין זמינות השירות, זמן תגובה לפנייה וזמן שחזור מערכת. אלה מדדים שונים; התחייבות לאחד מהם אינה בהכרח התחייבות לאחרים.

כמה עולים שירותי גיבוי בענן?

העלות תלויה בנפח הנתונים, במספר המערכות, בקצב השינויים, במשך שמירת העותקים וברמת הניהול והשחזור הנדרשת.

בהשוואת הצעות, בדקו כיצד מחושב האחסון: לפי המידע המקורי, לפי הנפח שנשמר בפועל או לפי חבילה. בררו גם אם יש חיוב על רישיונות, עותקים נוספים, העברת נתונים, שחזור, בדיקות שחזור או טיפול מקצועי.

תשלום חודשי נמוך אינו בהכרח העלות הכוללת הנמוכה ביותר. מנגד, אין צורך לשלם על יכולות שאינן משרתות את דרישות העסק. ההשוואה הנכונה היא בין פתרונות שנותנים מענה לאותם תרחישים ולאותה מדיניות שמירה.

שירותי גיבוי בענן ופתרונות המשכיות עסקית של Jetserver

ב־Jetserver אנו מציעים אפשרויות גיבוי כחלק משירותי הענן, שירותי ניהול השרתים ופתרונות ההתאוששות מאסון שלנו.

שירותי השרתים המנוהלים כוללים אפשרויות גיבוי לצד ניטור, אבטחה ותמיכה. במסגרת פתרונות ההתאוששות מאסון ניתן לבחון התאמת תדירות הגיבוי ונפחי האחסון, וכן גיבויים במספר מיקומים גאוגרפיים.

התאמת הפתרון מתחילה בהבנת הסביבה שלכם: אילו מערכות חיוניות לעבודה, כמה מידע נוצר, מה צריך לשחזר ובתוך כמה זמן. מפרט השירות, תקופות השמירה ואפשרויות השחזור נקבעים בהתאם לפתרון שנבחר.

מחפשים שירותי גיבוי בענן לעסק? צרו קשר עם Jetserver כדי לבחון פתרון שמתאים למערכות שלכם ולדרישות ההתאוששות של העסק.

:סיכום קצר של הדברים שעליהם עברנו

בעולם בו אנו חיים כיום, גיבוי בענן הוא הכרח, לא מותרות – והדבר נכון במיוחד לעסקים ולבעלי מידע חשוב וקריטי.
כאשר מדובר בעסקים אשר מסתמכים על מידע דיגיטלי, לענן יש חשיבות גבוהה ואף מכרעת. הסיבה לכך היא לא רק היתרונות הרבים שיש לשימוש בשירותי גיבוי בענן – זמינות בכל עת ומכל מקום, אבטחה מתקדמת, וחיסכון במשאבים – אלא גם היכולת לשמור על המשכיות עסקית וסדירה, גם במקרה חירום.

מלבד זאת, גיבוי בענן הוא פתרון הרבה יותר יציב, חסכוני וקל לניהול מפתרונות “מסורתיים” קלאסיים. נסו לדמיין בעצמכם את הפעולות הכרוכות בביצוע גיבויים (ובשחזורם) באמצעות כונן נייד, או אפילו באמצעות שרת פרטי. לעומת זאת, הענן ושירותי הגיבוי בענן מאפשרים את ביצוע כל הפעולות הללו באופן אוטומטי, ובאמצעות כמה הקלקות. כלומר, בזריזות רבה יותר, וביעילות רבה הרבה יותר.

אם אתם רוצים לייעל את הפעולות הדיגיטליות שלכם, ואם אתם בעלי מידע חשוב שמצריך גיבוי, שקלו מעבר לשירותי ענן מתקדמים.

שאלות נפוצות על שירותי גיבוי בענן

האם גם עסק קטן צריך פתרון גיבוי?

גם עסק קטן עשוי להיות תלוי במסמכים, בנתוני לקוחות ובאתר אינטרנט. הבחירה צריכה להתבסס על חשיבות המידע ועל היכולת לשחזר אותו במקרה של אובדן, ולא רק על מספר העובדים.

האם אפשר לשחזר קובץ בודד בלי להחזיר את כל המערכת לאחור?

בחלק מהפתרונות כן. חשוב לוודא שקיימת אפשרות לשחזור ברמת קובץ או פריט, ולבדוק מראש אם ניתן לשחזר למיקום חלופי בלי לדרוס מידע קיים.

האם המידע כבר מגובה אם השרת שלי נמצא בענן?

לא בהכרח. עצם הפעלת השרת בענן אינה מגדירה את מדיניות הגיבוי שלו. צריך לבדוק אם השירות כולל גיבויים, מה נכלל בהם והאם הם נשמרים בנפרד מהמערכת הפעילה.

האם Snapshot נחשב לגיבוי?

Snapshot הוא צילום מצב בנקודת זמן. בחלק מהטכנולוגיות הוא בסיס למערכת גיבוי, ובאחרות הוא תלוי בתשתית המקור. צריך לבדוק האם הוא נשמר בנפרד, מהי תקופת השמירה והאם אפשר להשתמש בו גם לאחר אובדן סביבת המקור. המונח לבדו אינו מעיד על רמת ההגנה.

כמה זמן לוקח לשחזר מידע מהענן?

אין זמן אחיד. הוא תלוי בנפח, בסוג המערכת, בטכנולוגיית הגיבוי, בתשתית היעד ובמהירות התקשורת. הדרך לבדוק התאמה לצורכי העסק היא לבצע שחזור ניסיון ולמדוד את הזמן עד שהשירות חוזר לפעילות.

האם אפשר לוותר על גיבוי נוסף כאשר יש גיבוי בענן?

לא כדאי להניח שגיבוי יחיד מתאים לכל הסיכונים. בדקו אם יש עותק נוסף ומופרד, וכיצד תתבצע התאוששות במקרה של פגיעה בחשבון הגיבוי או בתשתית שעליה הוא נשמר.

לסיכום: בוחרים גיבוי לפי היכולת לחזור לעבוד

שירותי גיבוי בענן צריכים לתת תשובה לארבע שאלות: מה מגובה, עד כמה הגיבוי מעודכן, כיצד הוא מוגן ואיך משחזרים ממנו.

השילוב בין מדיניות מתאימה, עותקים מופרדים, ניטור ובדיקות שחזור הופך את הגיבוי מחבילה של קבצים לתהליך התאוששות שימושי. כשבוחנים את הדברים מראש, אפשר לבחור פתרון שתומך בצורכי העסק גם בשגרה וגם ברגע שבו המידע נחוץ ביותר.