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

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

סקירת תוכנת גיבוי מתחילה ביעדי התאוששות

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

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

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

לא כל גיבוי הוא יכולת שחזור

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

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

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

בדיקת שחזור היא בקרת אבטחה, לא תרגיל תיעודי

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

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

הגנה מפני כופרה: הפרדה, אי-שינוי והרשאות

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

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

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

ענן ו-SaaS: אחריות משותפת אינה גיבוי

שירותי ענן מספקים זמינות גבוהה, אך הם לא בהכרח שומרים גרסאות היסטוריות לפי מדיניות הארגון, לא מגנים מפני מחיקה שגויה של משתמש בעל הרשאה ולא מבטיחים התאוששות נקודתית לכל סוג מידע. זה בולט במיוחד בסביבות Microsoft 365, שבהן דואר, SharePoint, OneDrive ו-Teams הם חלק מהפעילות היומית.

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

סקירת תוכנת גיבוי לפי רישוי ועלות כוללת

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

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

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

תפעול יומיומי הוא חלק מהבחירה

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

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

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

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