המחשב לא עולה בבוקר, תיקיית הלקוחות נעלמה או שמופיעה הודעת כופר על המסך? ברגע כזה, גיבוי ענן לעסקים הוא לא עוד שירות טכני ברשימה. הוא ההבדל בין כמה שעות של טיפול מסודר לבין ימים של השבתה, לקוחות שממתינים ותשלומים שלא יוצאים.
עסקים רבים מגלים מאוחר מדי שיש הבדל גדול בין "יש לנו גיבוי" לבין "אפשר להחזיר את המידע עכשיו". דיסק חיצוני שמחובר למחשב, קבצים שמועתקים מדי פעם ידנית או גיבוי שאף אחד לא בדק חודשים אינם תוכנית התאוששות. גיבוי נכון צריך להיות אוטומטי, מוגן, מנוטר ובעיקר כזה שאפשר לשחזר ממנו את מה שצריך בזמן שצריך.
למה העסק צריך גיבוי מחוץ למשרד?
מחשב אחד יכול להכיל שנים של עבודה: הצעות מחיר, חשבוניות, תמונות, תוכניות, חוזים, מסמכי לקוחות, קבצי הנהלת חשבונות ודואר אלקטרוני. גם עסק קטן שמנוהל ממחשב אחד תלוי במידע הזה כדי להמשיך לעבוד.
תקלת דיסק היא רק תרחיש אחד. יש גם מחיקה בטעות, תקלה בעדכון, מחשב שנגנב, קצר חשמלי, נזקי מים, שריפה או משתמש שלחץ על קובץ זדוני. במתקפת כופר, למשל, הקבצים על המחשב ועל הכוננים המחוברים אליו עלולים להיות מוצפנים יחד. אם הגיבוי נמצא באותו מקום או נגיש באותה צורה, הוא עלול להיפגע בדיוק כשהוא אמור להציל אתכם.
גיבוי בענן שומר עותק של המידע במיקום נפרד מתשתית המשרד. כלומר, גם אם המחשב, השרת או המשרד עצמו נפגעו, נשארת נקודת חזרה. זה לא מבטל את הצורך באבטחת מידע, אנטי-וירוס, עדכונים והרשאות גישה נכונות. הוא נותן שכבת הגנה קריטית כאשר משהו בכל זאת משתבש.
גיבוי ענן לעסקים אינו רק העתקת קבצים
פתרון בסיסי של סנכרון קבצים יכול להיות נוח לעבודה משותפת, אבל לא תמיד הוא גיבוי מלא. אם קובץ נמחק או מוצפן והוא מסתנכרן מיד לכל המקומות, ייתכן שהבעיה תועתק במקום להיפתר. לכן צריך להבין מה מגובה, כמה גרסאות נשמרות ולכמה זמן אפשר לחזור אחורה.
בעסק פעיל, הגיבוי עשוי לכלול הרבה יותר מתיקיית מסמכים. לעיתים צריך להגן על תוכנות ייעודיות, תיקיות עבודה, פרופילי משתמשים, דואר אלקטרוני, מחיצות שלמות, מסדי נתונים ומכונות וירטואליות. מסד נתונים של מערכת הנהלת חשבונות, למשל, אינו עוד קובץ שאפשר להעתיק תוך כדי עבודה. הוא דורש גיבוי שמטפל במידע בצורה תקינה ועקבית, כדי שהמערכת תוכל להיפתח לאחר השחזור.
אותו עיקרון חל על Microsoft SQL Server, MySQL, Oracle וסביבות VMware. כאן חשוב להתאים את שיטת הגיבוי למערכת עצמה ולא להסתפק בפתרון כללי. טעות בהגדרה יכולה לייצר תחושת ביטחון, אך ברגע האמת להשאיר קבצים שלא ניתן להשתמש בהם.
השאלה החשובה: כמה מהר חייבים לחזור לעבוד?
לפני שבוחרים שירות, צריך להגדיר את המחיר האמיתי של השבתה. משרד ייעוץ שמסוגל לעבוד יום אחד באופן חלקי אינו דומה לחנות מקוונת, מרפאה, מוקד שירות או חברה שמפעילה מערכת הזמנות. גם בתוך אותו עסק יש מידע קריטי יותר ופחות.
שתי שאלות עוזרות לעשות סדר. הראשונה היא כמה מידע העסק מוכן לאבד במקרה קיצון. אם גיבוי רץ פעם ביום, ייתכן שעבודה של יום שלם לא תהיה בעותק האחרון. אם נתונים משתנים לאורך כל היום, נדרש גיבוי תכוף יותר. השאלה השנייה היא כמה זמן העסק יכול להמתין עד שהמערכות חוזרות לפעול. שחזור של קובץ בודד שונה מאוד משחזור שרת שלם או מכונה וירטואלית גדולה.
אין תשובה אחת שמתאימה לכולם. גיבוי תכוף יותר ושמירת גרסאות ארוכה יותר יכולים לדרוש נפח, תכנון ועלות גבוהים יותר. מצד שני, חיסכון קטן בגיבוי עלול להפוך להפסד משמעותי אם העסק מושבת. המטרה היא לא לרכוש את הפתרון הכי גדול, אלא לבנות כיסוי שמתאים לאופן שבו העסק באמת עובד.
מה צריך לבדוק לפני שמחליטים?
בעל עסק לא חייב להפוך לאיש מערכות מידע כדי לבחור גיבוי טוב, אבל כדאי לקבל תשובות ברורות לשאלות הבאות:
- אילו מחשבים, שרתים, תיקיות, תוכנות ומסדי נתונים נכללים בגיבוי.
- באיזו תדירות הגיבוי פועל, ומה קורה אם מחשב כבוי בזמן שנקבע.
- כמה גרסאות של קבצים נשמרות ולכמה זמן אפשר לחזור לאחור.
- האם המידע מוצפן בזמן ההעברה ובזמן השמירה, ומי מחזיק בהרשאות הגישה.
- איך מבצעים שחזור בפועל, מי מטפל בו וכמה זמן הוא צפוי לקחת.
- האם הגיבוי מנוטר, כך שמישהו יודע על כישלון בגיבוי לפני שמתרחשת תקלה אמיתית.
הסעיף האחרון חשוב במיוחד. גיבוי יכול להיכשל בגלל חיבור אינטרנט, שינוי סיסמה, חוסר מקום, עדכון מערכת או תקלה בדיסק. אם אף אחד לא בודק התראות, הבעיה נשארת שקטה עד לרגע שבו כבר אין מאיפה לשחזר. שירות מנוהל צריך לכלול לא רק התקנה, אלא גם מעקב וטיפול כשמשהו לא רץ כפי שתוכנן.
שחזור שנבדק הוא ההוכחה היחידה
הטעות הנפוצה ביותר היא להניח שאם רואים סימון ירוק של "הגיבוי הסתיים", הכול תקין. הסימון מאשר בדרך כלל שהעברת הנתונים הסתיימה, לא בהכרח שהמידע ישוחזר באופן מלא ושימושי.
בדיקות שחזור תקופתיות נותנות תשובה מעשית: האם אפשר להחזיר קובץ מסוים? האם אפשר לפתוח אותו? האם מסד הנתונים עולה? האם ניתן לשחזר מחשב או שרת במקרה של כשל חומרה? הבדיקה גם חושפת מראש כמה זמן לוקחת הפעולה ומה צריך להכין ביום תקלה.
לא חייבים בכל חודש לשחזר את כל השרת. אפשר לבנות בדיקה מדורגת: פעם אחת קובץ, בפעם אחרת תיקייה או תיבת דואר, ובהמשך בדיקה של מערכת קריטית. העיקר הוא לא להישען על הנחות. כשיש תוכנית שחזור ידועה ואדם שמכיר את הסביבה, הלחץ בזמן תקלה יורד בצורה משמעותית.
דואר אלקטרוני ומערכות ענן: לא להניח שהכול מגובה
עסקים רבים עובדים עם Microsoft 365 ומניחים שהמידע בדואר, בלוח השנה ובאחסון הקבצים מוגן בכל תרחיש. הפלטפורמה מספקת זמינות גבוהה וכלי אבטחה חשובים, אך זה לא בהכרח מחליף מדיניות גיבוי שמותאמת לעסק.
מחיקה של משתמש, שינוי הרשאות, מחיקה רחבה בטעות או צורך לשחזר מידע ישן יכולים להפוך לאירוע מורכב. לכן כדאי להחליט במפורש אילו נתונים בענן חייבים להישמר, מי אחראי עליהם ומהי תקופת השמירה הדרושה. המידע נמצא בענן, אבל האחריות העסקית עליו נשארת אצל העסק.
גיבוי טוב מתחיל במיפוי פשוט
לפני התקנה, כדאי לעבור על יום עבודה רגיל ולשאול: בלי אילו נתונים אי אפשר לתת שירות מחר בבוקר? לאילו מערכות יש רק אדם אחד שיודע את הסיסמה? אילו קבצים נמצאים על מחשבים אישיים במקום בשרת או בתיקייה משותפת? האם יש מחשב ישן שמריץ תוכנה קריטית ואף אחד לא זוכר איך הוגדר?
המיפוי הזה מגלה לא פעם נקודות תורפה שאינן קשורות לגיבוי בלבד. הוא מאפשר לסדר הרשאות, לתעד סיסמאות בצורה מאובטחת, להגדיר הגנות למחשבים ולהחליט מה באמת צריך להיכלל בתוכנית. כך הגיבוי הופך מחבילה כללית לחלק מסביבת מחשוב מסודרת.
בטופ מחשבים מתאימים גיבוי ענן מנוהל לפי המערכות והעבודה בפועל, כולל קבצים, דואר, תוכנות, מסדי נתונים ומכונות וירטואליות לפי הצורך. המטרה אינה להעמיס מונחים טכניים, אלא לוודא שביום שבו יש תקלה יש כתובת אחת שמכירה את התשתית, בודקת את הגיבוי ומטפלת בשחזור.
אם אינכם יודעים מתי בוצעה בדיקת השחזור האחרונה, זה זמן טוב לא לחכות לתקלה. שיחה קצרה ומיפוי של המידע החשוב יכולים להפוך יום שעלול להתחיל בלחץ לתהליך טיפול ברור, עם דרך מסודרת לחזור לעבודה.