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

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

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

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

מודל האחריות המשותפת, בשפה פשוטה

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

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

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

ממה בדיוק צריך להגן

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

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

גיבוי פשוט בחמישה צעדים

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

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

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

ידני, אוטומטי או כלי ייעודי

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

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

מתי לא

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

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

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

שאלות נפוצות

האם הספק לא חייב לשמור את הנתונים שלי?

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

כמה זמן נשמר פריט שנמחק?

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

מה ההבדל בין גיבוי לסנכרון?

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

איפה כדאי לשמור את קובצי הגיבוי?

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