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

האזינו לסקירה קולית:

0:00

רכיבי המידע הדורשים גיבוי נפרד ב-Monday.com

נתונים (Data): כל תוכן שמוזן למערכת – פריטים (Items) ושורות מידע, קבוצות (Groups) בלוחות, קבצים מצורפים, ותכתובות/תגובות (Updates) – מהווים את ליבת המידע התפעולי ודורשים גיבוי. Monday.com מאפשרת לייצא נתונים אלו: מנהל מערכת (Admin) יכול להוריד קובץ ZIP עם כל נתוני החשבון המכיל את כל הלוחות (כולל לוחות משותפים ופרטיים) ואת כל הקבצים שהועלו. הנתונים הללו קריטיים לגיבוי, שכן אובדנם יפגע ישירות בעבודת הארגון.

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

• מבנה הלוחות: שמות לוחות, מבנה עמודות וסוגיהן, קבוצות, ושדות מותאמים – אלו חלק מתצורת המערכת ויש חשיבות לשחזרם כדי להחזיר פעילות לקדמותה. ייצוא החשבון מ-Monday כולל את מבנה הלוחות והעמודות יחד עם הנתונים, אך יש לשים לב שלא כל סוגי המבנה נכללים בגיבוי (למשל תצוגות מותאמות).

• אוטומציות (Automations) ואינטגרציות (Integrations): אלה כללי העבודה האוטומטיים והחיבורים למערכות חיצוניות שהגדרתם בתוך Monday. הם אינם חלק מהנתונים הגולמיים, וחשובים לתהליכים העסקיים. נכון להיום, אין דרך מובנית לייצא או לגבות אוטומציות ואינטגרציות דרך הממשק או ה-API. מערכת Monday לא חושפת את הגדרות האוטומציה דרך ה-API, ולכן רכיבים אלה דורשים גיבוי ותיעוד ידני (יורחב על כך בהמשך).

• תצוגות ודשבורדים (Views & Dashboards): תצוגות לוח מותאמות אישית ודשבורדים המסכמים נתונים מכמה לוחות – לא נכללים בייצוא המובנה. Monday אף מציינת שדשבורדים לא כלולים ביצוא חשבון, אך המידע שמוצג בהם מגיע מהלוחות שכן מגובים בקובץ ה-ZIP. כלומר, הנתונים הבסיסיים יהיו קיימים, אך אם היו דשבורדים מורכבים, יהיה צורך לשחזר ידנית את מבנה הדשבורד (ווידג'טים) לאחר שחזור הנתונים.

• מסמכי Workdocs: מסמכים שיתופיים בתוך Monday (כגון Workdocs) אינם נכללים בגיבוי החשבון המובנה. יש להתייחס אליהם כרכיב נפרד – מומלץ לייצא מסמכים חשובים כ-PDF באופן ידני לצורך גיבוי (נכון לעכשיו לא ניתן לייצא מסמכים בעברית), בטרם מבצעים ייצוא כולל של החשבון, כדי להימנע מאובדן מידע במסמכים אלה.

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

נקודה חשובה: יחסי גומלין בין לוחות – למשל עמודות המקושרות ללוח אחר (Connect Boards) – עלולות שלא להשתמר במלואן בגיבוי פשוט. משתמשים העירו שייצוא הנתונים הקלאסי אינו שומר תמיד על הקשרים בין לוחות. לכן, אם יש תלות בין לוחות (כגון Mirror Columns), יש לקחת בחשבון שהקשרים האלה יידרשו שיחזור או עדכון חוזר כשבונים את המערכת מחדש.

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

אפשרויות גיבוי למשתמשים ללא ידע טכני (No-Code)

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

גיבוי ידני באמצעות הכלים המובנים של Monday.com

1. ייצוא כולל של חשבון ה-Monday: כמנהל מערכת, ניתן בכל עת לבצע ייצוא ידני של כל נתוני החשבון דרך ממשק הניהול. פעולת “Export Account Data” יוצרת קובץ ZIP הכולל את כל הלוחות (לוחות ראשיים, שיתופיים ופרטיים) וכל הקבצים המצורפים בלוחות. הייצוא זמין אחת ל-24 שעות (אי אפשר לייצא בתדירות גבוהה יותר). לאחר הבקשה, בתוך כמה שעות מתקבל אימייל עם קישור להורדת ה-ZIP, התקף ל-24 שעות. יתרונות: שיטה זו חינמית (כלולה בתוכנת Monday) ולא דורשת התקנת שום כלי נוסף. היא נותנת גיבוי מקיף של כל הנתונים (פריטים, עדכונים, קבצים וכו’) בפורמט לפתיחה (קבצי Excel/CSV לכל לוח וקבצי המדיה). חסרונות: מדובר בפעולה ידנית – יש לזכור לבצע אותה באופן תקופתי (למשל פעם בשבוע/חודש, בהתאם לכמות השינויים) ולשמור את הקובץ במקום מאובטח (חשוב לציין שמי שיש להם גישה לקובץ יוכלו לגשת למידע שאולי לא היה להם דרך המערכת, כי ה-ZIP כולל גם בורדים פרטיים שכרגע חשופים לכל מי שיש להם גישה אליו). כמו כן, הייצוא לא כולל אוטומציות, אינטגרציות, דשבורדים, Workdocs ולוחות בארכיון – כך שיש רכיבים שיהיה צורך לגבות בדרכים אחרות. בנוסף, שחזור מתוך ה-ZIP אינו אוטומטי (דורש ייבוא קבצים ידני ללוחות חדשים, ראו בהמשך). למרות זאת, ייצוא זה מהווה “רשת ביטחון” בסיסית וזמינה לכל לקוח Pro, וכדאי לנצל אותה באופן קבוע.

2. ייצוא לוחות בודדים או תצוגות: בנוסף לייצוא הכולל, Monday מאפשרת לייצא נתוני לוח יחיד לקובץ Excel. אפשר להשתמש בכך כגיבוי נקודתי – למשל, לפני מחיקת לוח או ביצוע שינוי גדול, להוריד את תוכן הלוח כ-Excel. כמו כן, ניתן לייצא גם תצוגות (View) מסוימות לטבלאות או PDF, בהתאם לסוג התצוגה. גיבוי ברמת הלוח יכול להיות יותר תכוף (למשל לוח קריטי – לייצא ידנית פעם ביום). עם זאת, שימו לב שייצוא כזה לרוב לא כולל את כל הפרטים (ייתכן ולא כולל תגובות, או סטטוסים צבעוניים כערכים טקסטואליים בלבד וכד'). זו עדיין דרך מהירה למדי להוציא מידע ללא כלים חיצוניים.

3. שימוש ב-“Recycle Bin” (פח האשפה) של Monday: זהו פתרון שחזור קצר-טווח יותר מאשר גיבוי ארוך-טווח, אך חשוב להזכירו. Monday שומרת כל פריט, קבוצת פריטים, לוח שלם, עמודה או דשבורד שנמחקו בטעות ב”סל מחזור” למשך 30 יום. בתוך 30 יום ממחיקה, אדמין או משתמש יכול לפתוח את ה-Recycle Bin (מתפריט הפרופיל) ולשחזר בלחיצת כפתור את מה שנמחק. כך שאם מישהו בטעות מחק מידע ולא הבחנתם מיד – יש חלון הזדמנויות של חודש לשחזר לפני שהמחיקה תהפוך לסופית. ה-Recycle Bin הוא כלי מובנה ונוח, אך מוגבל בזמן. לכן, הוא לא תחליף לגיבוי – אלא שכבת הגנה ראשונה. למשל, אם מתגלה כעבור שבועיים שרשומה קריטית נמחקה – אפשר לשחזרה משם בקלות. אבל אם רק לאחר שלושה חודשים גיליתם שמידע חסר, ה-Recycle Bin כבר לא יעזור, ותזדקקו לגיבוי חיצוני או סיוע מתמיכת Monday (ראו בהמשך).

4. שימוש בגרסאות לוח וארכיון לוחות כ"צילום מצב": Monday אינה תומכת ב-"היסטוריית גרסאות" מלאה של לוחות (אין יכולת בילט-אין לחזור בזמן ללוח כפי שהיה בתאריך X), ולכן ניתן ליישם פתרון ידני: לקחת "צילום מצב" תקופתי של לוחות חשובים. איך עושים זאת? אחת לשבוע/חודש (או לפני אירוע גדול) – לשכפל (duplicate) את הלוח ולתת ללוח המשוכפל שם עם תאריך (למשל: "פרויקט X - מצב ל-01/06/2025"). את השכפול הזה אפשר להעביר ל_workspace_ נפרד שנקרא "Snapshots" או אפילו לארכב (Archive) אותו. בדרך זו, גם אם מישהו ערך או מחק נתונים בטעות, יהיה לכם עותק של הלוח במצב הקודם. חשוב: בשכפול לוח, מערכת Monday מאפשרת לבחור האם לשכפל רק את מבנה הלוח או גם את הפריטים והעדכונים. לצורך "גיבוי" יש לבחור לשכפל עם כל הפריטים, וכך הלוח המשוכפל משמר את כל המידע נכון לרגע ההעתקה. רוב הגדרות הלוח יעברו אף הן בשכפול (כולל הרשאות, תצוגות), כולל רוב האוטומציות. כאשר משכפלים לוח במלואו, פרטי מתכוני האוטומציה והתראות אמורים לעבור ללוח החדש. עם זאת, ייתכנו אוטומציות שלא ישוכפלו (במיוחד אוטומציות בין-לוחות או אינטגרציות חיצוניות שמצריכות הגדרות ייחודיות). לכן, גיבוי בדרך של שכפול לוחות מועיל בעיקר לשימור הנתונים, ופחות להבטחת כל האוטומציות.

5. כלי “Undo” ו"היסטוריית פעולות": Monday מספקת היסטוריית פעילות (Activity Log) בכל לוח, בה אפשר לראות מה שונה ומתי, על ידי מי. אפשר למשל לזהות מי מחק פריט או שינה ערך. אמנם אין אפשרות “CTRL+Z” אוניברסלית לכל השינויים, אך ניתן לעקוב אחר שינויים ולשחזר נקודתית – למשל אם פריט נמחק, לשחזרו מה-trash; או אם ערך שדה שונה, להיכנס לפריט ולראות היסטוריה של ערכים (זמין בסוגי עמודות מסוימים כמו "Status"). ה-Activity Log שימושי לביקורת, אך אינו כלי גיבוי כשלעצמו (לא ניתן לשחזר ישירות ממנו מצב קודם). לכן הוא בעיקר משלים את אסטרטגיית הגיבוי בכך שמאפשר לזהות מה השתנה וכך להתמקד במה לשחזר.

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

טיפים לביצוע גיבוי ידני יעיל:

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

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

• בדיקת תקינות: מדי פעם, פתחו את קובץ ה-ZIP ובדקו שאתם מבינים את מבנהו ושהנתונים שם. ה-ZIP בדרך כלל בנוי בתיקיות לפי לוחות, עם קובץ CSV/Excel לכל לוח. ודאו שכל לוח חשוב מופיע ושאפשר לקרוא את התוכן. כך, במקרה חירום, לא תתקלו בהפתעה לא נעימה.

• ייצוא Workdocs ודשבורדים: כיוון שאלה אינם נכללים אוטומטית, הגדירו נוהל שבמסגרתו מישהו מוריד PDF/Excel של כל Workdoc חשוב וכל דשבורד/דוח חשוב על בסיס חודשי או רבעוני. למשל, מסמך מעקב חודשי – להוריד כ-PDF בסוף כל חודש ולשמור בתקיית הגיבויים. חשוב לציין - פתרון הייצוא המובנה של Monday לא תומך עדיין בעברית לכן ניתן ליצור קובץ PDF ע"י "הדפסה" לקובץ PDF. חשוב לנסות ולבדוק את הנושא בשגרה. דשבורד עם נתוני מוטבים – ניתן לבדוק אפשרות ייצוא ל-PDF (אופציה חדשה יחסית של Monday), אולי לצלם מסך של ההגדרות של הווידג'טים, או להוציא דו"ח נתונים גולמיים. מטרת נוהל זה היא לוודא שלא תופתעו מכך שפריט מידע קריטי היה רק בדשבורד/Workdoc ולא גובה.

שירותי גיבוי אוטומטיים צד-שלישי (Backup SaaS)

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

• מערכת ProBackup – פתרון פופולרי לגיבוי Monday.com (וגם אפליקציות ענן אחרות). ProBackup מבצע גיבוי יומי אוטומטי של כל הלוחות, הפריטים, התגובות, הקבצים והעמודות שלכם. הוא שומר היסטוריה של מספר חודשים (6 חודשים בתוכנית הבסיס, עד 2 שנים ויותר בתוכניות מתקדמות) ומאפשר שחזור גרנולרי, כלומר ניתן לשחזר פריט בודד, קובץ ספציפי, או לוח שלם בלחיצה. יתרון נוסף – ניתן לסנכרן את הגיבוי לענן שלכם, למשל ל-Google Drive: השירות ישמור עותקי גיבוי בגוגל שיטס וקבצים מצורפים בדרייב שלכם, אם תרצו. ProBackup מדגיש אבטחה (החברה בעלת הסמכת SOC2, תואמת GDPR). עלות: החל מ-$25 לחודש (בערך 90 ש"ח) בתוכנית לשנה עבור החברה כולה (נפח 10GB, היסטוריה 6 חודשים). יש תוכניות יקרות יותר אם צריכים יותר נפח/היסטוריה ותכונות נוספות. עבור ארגון קטן-בינוני, העלות סבירה ביחס לערך – ויש להם גם תקופת ניסיון חינמית. חסרונות: מגבלות כיסוי עקב מגבלות API – ProBackup לא מסוגל לגבות את כל הרכיבים. לפי התיעוד, לא מגובים: תצוגות מותאמות, לוג פעילות (Activity Log), דשבורדים, אוטומציות ו-Monday Docs . כלומר, בדיוק אותם רכיבי הגדרה שציינו קודם בגיבוי ZIP המובנה. כמו כן, תהליך השחזור אינו מושלם ב-100%: יש עדויות (בקהילת מאנדיי ברשת), שבשחזור פריטים עם עמודת Mirror, השירות לא תמיד הצליח לשחזר את העמודה המקושרת באופן מלא. ייתכן שתקלות כאלה תוקנו מאז, אבל חשוב לדעת ששחזורים מורכבים (במיוחד עם קשרי לוחות) עלולים לדרוש תיקון ידני קטן. למרות זאת, ProBackup זוכה לחוות דעת טובות על קלות השימוש והאמינות במחיר סביר לפי ביקורת משתמשים.

• מערכת Rewind – שירות גיבוי ענן ותיק (מוכר בעיקר לגיבוי Shopify, GitHub וכו’) שמציע גם גיבוי ל-Monday. ה- Rewind פועל כיישום בתוך Monday (דרך ה-App Marketplace הרשמי) ומספק גיבוי רציף (Continuous backup) של כל המידע בחשבון, עם יכולת לשחזר כל פריט, לוח או אפילו את כל חשבון העבודה לנקודת זמן מסוימת – ישירות מתוך ממשק Mondayrewind. היתרון של Rewind הוא באמינות ובדגש על תקנים: החברה עומדת בתקני SOC 2 Type II, ותומכת בדרישות רגולציה (ISO 27001, HIPAA, GDPR ועוד) כולל אפשרות להגדרת שמירת נתונים עד 365 יום ואפילו בחירת מיקום דאטה (Data Residency) בהתאם לצורך. השירות שומר Workspaces, לוחות, פריטים ותתי-פריטים, עמודות ועוד – למעשה את מרבית נתוני הליבה של Monday, אך גם כאן ללא כל ההגדרות (אוטומציות, Workdocs, דשבורדים...). עלות: 45 דולר לחודש לחשבון עם 10 משתמשים. אפשר לבדוק האם יש הנחה לעמותות. חסרונות: כמו ProBackup, גם Rewind כנראה אינו מכסה אוטומציות ואינטגרציות (מגבלת API כללית). הממשק והדוחות של Rewind באנגלית, וייתכן שהתקנת האפליקציה דורשת הרשאות מנהל ומעט הבנה טכנית (אך ללא כתיבת קוד). חשוב לציין ש-Rewind שומר מידע בענן שלהם – יש לוודא שזה תקין מבחינתכם (חתימת הסכם עיבוד נתונים וכו’).

• שירותים נוספים: ישנם עוד פתרונות בשוק: למשל FluentPro Backup for Monday.com (מבוסס ענן, מיועד לארגוני Enterprise, מציע גיבוי אוטומטי של כל מה שעודכן כולל משתמשים וצוותים, עם שחזור בלחיצה), או HYCU R-Cloud for Monday.com – מודול גיבוי של חברת HYCU שמתממשק ל-Monday כחלק מפלטפורמת הגיבויים שלהם. שירותים אלה בדרך כלל מכוונים לחברות גדולות, ועלותם בהתאם. עבור ארגון חברתי בגודל קטן-בינוני, הפתרונות שלעיל (ProBackup/Rewind) יהיו כנראה נגישים יותר.

מה משותף לכל שירותי הגיבוי החיצוניים? הם נותנים שקט נפשי מול התרחישים הקשים ביותר – מחיקה זדונית או תקלה רחבה – ע"י שמירת עותקים מחוץ למערכת. כפי שצוין בסקר גלובלי, ספקי SaaS כמו Monday, אינם נושאים באחריות לגיבוי המידע של הלקוחות באופן מלא (זה חלק ממודל אחריות משותפת). Monday.com אמנם עושה גיבויים משלה לשרתי AWS (פלטפורמת מחשוב ענן של Amazon), כדי להגן על הנתונים ברמת התשתית, אך אם הלקוח עצמו מוחק מידע, או מאבד גישה, האחריות לשחזור היא במידה רבה עליו. שירותים כמו ProBackup/Rewind ממלאים את ה"פער" הזה ומספקים שכבת הגנה נוספת. כמו כן, זמן השחזור מהיר – במקום לבנות ידנית לוחות ולהעתיק מידע, ניתן בלחיצה להחזיר לוח שלם על תכניו כפי שהיה אתמול. בהיבט עלות-תועלת, יש לחשוב: כמה זמן וכסף יעלה לארגון לשחזר ידנית חודש של עבודה שהתפקששה? כמה נזק תפעולי וכספי ייגרם אם לא תוכלו לעבוד יומיים בשל אובדן נתונים? בהשוואה לכך, עשרות דולרים בחודש הם "פרמיית ביטוח" סבירה כדי להקטין סיכון זה.

אפליקציות Marketplace וכלים משלימים בתוך Monday

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

• אפליקציית "Board & Doc Backups": אפליקציה שהוכרזה בשנת 2025 ומפותחת על ידי שותף (Deview Studios). ייעודה לספק פתרון גיבוי בתוך Monday עצמה – ללא העברת מידע החוצה. האפליקציה מאפשרת ליצור צילום מצב (Snapshot) של לוחות ו/או Workdocs ולשמור אותם כגיבוי, ואז לשחזר בקלות מתוך אותם Snapshot בעת הצורך. למעשה הי הפתרון היחיד שמציע גיבוי ל-Wordocs. זוהי דרך לנהל גרסאות ללוחות בתוך המערכת: ניתן לקחת snapshot של לוח מלא, קבוצה מסוימת, פריט יחיד או מסמך – ולשמור כמה גרסאות לאורך זמן, כדי שיהיה לאן לחזור. יתרון גדול הוא שמירה מקומית – “No Third-Party Risks” כפי שמתואר – המידע לא יוצא למערכת חיצונית, אלא נשמר בתוך חשבון Monday שלכם (כנראה בלוחות/מבנה ייעודי מוצפן). כך נמנעים מסיכוני פרטיות נוספים. האפליקציה מתאימה לכל סוג חשבון (גם חשבון Pro). עלות: לא צוינה במפורש בהכרזה, ייתכן שיש עלות מנוי דרך המרקטפלייס (או גרסה חינמית בסיסית). בהנחה שזה שירות פרימיום, סביר שתהיה עלות אך אולי נמוכה מה-SaaS החיצוניים, כי האחסון הוא על חשבון נפח Monday שלכם. חסרונות: מאחר שהפתרון חדש, יש לבדוק עד כמה הוא מקיף את כל סוגי הנתונים. הוא כן טוען ל-"No data left behind", כלומר כולל לוחות, פריטים, מסמכי workdocs. נכון ליוני 2025 האפליקציה אינה מגבה “תצוגות” (Views, Dashboards) ולא את מתכוני האוטומציה / האינטגרציות, מכיוון שהיא משתמש בכלים של Monday עצמה. לכן סביר שתצטרכו עדיין לגבות/לתעד אוטומציות ידנית. עם זאת, מדובר בכלי שמקל מאוד על יצירת נקודת שיחזור בתוך המערכת, ויכול להיות פתרון נהדר למי שלא רוצה להתעסק עם הורדת קבצים או שירות חיצוני. הוא גם יכול לשמש לצרכים נוספים – למשל ביקורת ורגולציה: לשמור "צילום מצב" של פרויקט בסוף כל חודש לצורכי דוחות שקיפות.

• אפליקציית "Board Email Reports": זהו כלי נוסף הזמין במרקטפלייס שנועד בעצם לצרכי דיווח, אך אפשר לרתום אותו כפתרון גיבוי עקיף. הרעיון: האפליקציה שולחת באופן אוטומטי דוחות אקסל של שינויים בלוח לפי לו"ז קבוע למייל. ניתן להגדיר, למשל: "כל שבוע, ביום שישי, שלח אליי במייל גיליון Excel עם כל הפריטים בלוח X ומצבם". הדוח מכיל מידע על הערכים המקוריים והחדשים, זמני שינוי, וכו’, והוא מגיע למייל כקובץ. בכך, הארגון מקבל קובץ תקופתי אוטומטי שתועד בו מצב הלוח או השינויים בו. אף שזה לא "גיבוי מלא" של כל הנתונים (יותר מעקב שינוי), אפשר להגדיר אותו בצורה מקיפה כך שבכל דוח יופיעו כל הפריטים עם כל שדות המפתח. השימוש בכלי זה דורש מעט הגדרה חד-פעמית, אבל לא קידוד, ויכול להוות חלק מאסטרטגיית הגיבוי – במיוחד לצורך מעקב אחר שינויים לאורך זמן ולצרכי ביקורת. למשל: נניח ויש לכם לוח של מלאי תרופות עבור מוטבים. תוכלו לקבוע שכל יום ראשון תקבלו במייל אקסל עם רשימת כל המוטבים והתרופות המעודכנת, וכך לשמור עותק יומי/שבועי אצלכם בלא מאמץ. במקרה חירום (ניתוק אינטרנט), תוכלו לפתוח את המייל האחרון ולמצוא שם את המידע.

בנוסף לשתי אלה, במרקטפלייס Monday קיימת גם האפליקציה הרשמית של ProBackup (אם מעדיפים להתקין דרך שם) ושל Rewind, כך שניתן לשלב אותן דרך ממשק Monday. יש גם כלים ייעודיים לפונקציות ספציפיות – למשל אפליקציה לשמירת גיבוי של גרסאות Workdocs או סנכרון לוחות לגוגל שיטס (שגם יכול להוות גיבוי חי - כל שינוי מסתנכרן לגיליון חיצוני). שילוב כלים אלו יכול לספק פתרון ללא כתיבת קוד אבל עם אוטומציה של הגיבוי.

שחזור חשבון או לוחות במקרה של אובדן מידע

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

1. שחזור מלוח הזמנים הקצר (עד 30 יום): אם מדובר במחיקה/אובדן שארע לאחרונה (בתוך 30 יום):

• ראשית, יש להשתמש בכלי המובנה - שחזור מה-Recycle Bin של Monday. כאמור, ניתן לשחזר משם פריטים, קבוצות, לוחות ואפילו דשבורדים שנמחקו בטעות. הפעולה מהירה (מיידית) ומשחזרת את המידע למקומו המקורי.

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

• במקרה בו אובדן הגישה לחשבון הוא הבעיה (למשל, המנהל היחיד עזב ואין גישה לאדמין, או שכחתם סיסמה ואין איפוס), הפתרון המיידי הוא לפנות לתמיכת Monday כדי לשחזר גישה. כדאי להימנע מתרחיש כזה מראש ע"י כך שתמיד יהיו לפחות שני אדמינים לחשבון (כדי שאם אחד לא זמין, השני יוכל לעזור), ולשמור במקום בטוח את פרטי ההתחברות ו/או קודי גיבוי של MFA אם הופעל.

2. שחזור מגיבוי ידני (קובץ ZIP או יצוא Excel): נניח שקרה תרחיש חמור (מחיקה המונית, או תקלה מערכתית) וגיליתם זאת מאוחר מ-30 יום או שה-trash לא עוזר. אם יש בידיכם קובץ ZIP שייצאתם (או אקסלים של לוחות):

• שחזור לוחות ונתונים: תצטרכו לייבא מחדש את הנתונים ל-Monday. הדרך הפשוטה: ליצור לוח חדש ולבחור באפשרות Import (ייבוא) מתוך Excel/CSV. Monday יודעת לקרוא קובץ וליצור ממנו לוח עם עמודות אוטומטית, אך כדאי לבדוק את התוצאה. תידרשו לבצע זאת עבור כל לוח שתרצו לשחזר. זהו תהליך ידני שלוקח זמן, אך לפחות הנתונים עצמם בידיכם. קבצים מצורפים שהיו בלוחות – יהיו בתיקיות ב-ZIP; תצטרכו לאחר שייצרתם את הפריטים בלוח, להעלות שוב את הקבצים הרלוונטיים (יתכן שתסתפקו בשמירתם במחשב גיבוי אם אין זמן להעלות הכל).

• שחזור מבנה הלוחות: אם הייצוא כלל את מבנה העמודות, הלוחות מיובאים פחות או יותר נכונים. אבל אוטומציות, תצוגות, עמודות רבות שכללו הגדרות שונות - אינם ברי שחזור - ראו בסעיף הבא איך לשחזרן. אם הייתה לכם מערכת גדולה, עדיף להתמקד בשחזור תחילה של הנתונים הקריטיים (לדוגמה, טבלת המוטבים והמידע הרפואי שלהם), כדי לחזור לתפעול בסיסי, ואת שאר הלוחות או הפיצ'רים לשקם בהמשך. אפשר גם לנקוט אסטרטגיית ”Manual Disaster Recovery”: במצב חירום, אולי אין צורך לשחזר הכל למערכת מיד – מספיק להוציא את המידע הדרוש בדחיפות (נניח, להדפיס מהרשימות מה-Excel) כדי להמשיך עבודה, ואז במקביל צוות טכני יכול להמשיך להעלות נתונים ללוחות ביום-יומיים הבאים.

• שחזור Workdocs: אם גיבינו אותם בנפרד (הדפסה ל-PDF), ניתן בשחזור פשוט להעלות את ה-PDF למערכת או להעתיק תוכנם למסמך חדש. אם היו אלה מסמכים קריטיים (כמו נהלים, דו"חות), לפחות המידע לא אבד.

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

3. שחזור באמצעות שירות גיבוי חיצוני: אם בחרתם להשתמש ב-ProBackup, Rewind או דומיהם – בעת אסון, יש לגשת לכלי שלהם:

• ב-ProBackup: מתוך ממשק הווב שלהם, בוחרים גרסת גיבוי (לפי תאריך) ואת היישות שרוצים לשחזר (לוח, פריטים וכו’) ולוחצים Restore. השירות דרך API ישחזר לתוך חשבון ה-Monday שלכם את הנתונים. למשל, אפשר לשחזר לוח שלם שנמחק – ProBackup פשוט ייצור לוח חדש בחשבון שלכם עם כל הפריטים, העמודות והמידע כפי שהיו בגיבוי הנבחר. עבור פריטים בודדים – הוא יוצר אותם מחדש בלוח (כלומר, אם פריט נמחק, הוא יתווסף שוב עם התוכן הישן). תהליך זה יכול לקחת דקות ועד שעות (תלוי בנפח), אבל עדיין מהיר בהשוואה להזנה ידנית. זכרו שתיתכן עבודה ידנית משלימה – למשל, לשחזר חיבורים ללוחות אחרים באופן ידני אם ה-API מוגבל. ProBackup כולל גם דוח "Deleted Items" לזיהוי מה נמחק לאחרונה, וכן התראות חכמות: אם הוא מזהה מחיקה מאסיבית הוא יכול לשלוח התרעה - כך שתדעו מיד להפעיל שחזור.

• ב-Rewind: האפליקציה בתוך Monday אמורה להציג לכם היסטוריית גרסאות ולתת לבחור נקודת זמן לשחזור. ניתן לשחזר ברמת פריט, לוח או חשבון. לדוגמה, אם לוח קרס, משחזרים אותו כפי שהיה אתמול ב-17:00. Rewind מצטיינת ביכולת Search – תוכלו לחפש בפריטי הגיבוי כדי לאתר נתונים שאבדו (נניח שם מוטב מסוים), ואז לבחור לשחזרם. השחזור מתבצע בפועל ע"י יצירת אותו אובייקט מחדש ב-Monday. Rewind אף יכולה לשחזר Workspace שלם (אוסף לוחות) אם כל workspace נמחק או נפגם, וכך לחזור לעבודה מהר מאוד.

• בשירותים אחרים התהליך דומה. הכינו מבעוד מועד: ודאו שאתם יודעים כיצד להפעיל שחזור, ושיש לפחות שני אנשים בצוות שמכירים זאת (כדי שבשעת חירום לא יהיה עיכוב).

4. שחזור בסיוע תמיכת Monday.com: Monday עצמה מחזיקה כאמור גיבויים פנימיים של כל הנתונים ל-25 יום אחרונים לצרכי שחזור מערכת. במקרים חריגים, צוות Monday יכול לסייע ללקוח לשחזר מידע מהגיבויים הללו, אך האפשרות הזו אינה מובטחת לכל לקוח באופן שוטף. למעשה, לקוחות Enterprise נהנים מתמיכת שחזור מוגברת: לפי הפורומים, עבור מנויי Enterprise, Monday מוכנה לנסות ולשלוף מלוחות הגיבוי שלה נתונים שאבדו אם פונים אליהם בזמן. אלו לא כלים בשירות עצמי, אלא תהליך דרך פנייה לתמיכה ובדרך כלל מוגבל למקרים קריטיים (למשל איבוד מידע עקב תקלה טכנית או באג). אם אתם מנויי Pro (לא Enterprise), ייתכן שבמקרה אסון גדול (נניח כל החשבון נמחק או נפרץ) – תמיכת Monday תנסה לעזור כמיטב יכולתה, אך אין על כך התחייבות מפורשת בשירות. לכן, אל תסתמכו על כך כתוכנית ראשית. עם זאת, תמיד מומלץ במקרה חירום ליצור קשר עם התמיכה של Monday, במיוחד אם אין לכם גיבוי אחר: ייתכן שיסייעו באופן חד-פעמי לשחזר לוח קריטי מתוך הגיבוי שלהם (אם הפנייה נעשתה בתוך 25 יום מהמחיקה). צוות Monday פעיל 24/7, כך שבאירוע חמור - פתחו קריאת תמיכה דחופה, הסבירו את שאירע ובקשו שחזור. היו מוכנים לספק מזהי לוחות/פריטים ספציפיים לאיתור.

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

• אם יש לכם קובצי אקסל/ZIP עדכניים מהגיבוי הידני האחרון – ניתן לפתוח אותם במחשב לא מקוון ולמצוא את המידע הנחוץ.

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

• אם אתם משתמשים בכלים כמו Board Email Reports לשליחת דוחות למייל – שימרו עותק מקומי (ניתן להוריד מראש למחשב נייד את המיילים האחרונים עם הקבצים או לסנכרן את תיקיית ה-Inbox לשימוש אופליין). כך גם אם השרתים רחוקים, במחשב שלכם המידע קיים.

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

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

מגבלות בגיבוי של אוטומציות, אינטגרציות ותצוגות – והתמודדות איתן

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

• אוטומציות פנימיות (Recipes): אלו "החוקים" שהגדרתם (IF/THEN וכד’) בתוך Monday. אין אפשרות לגבות ולשחזר את האוטומציות כדי להחזיר את המערכת למצב מתפקד. עד לא מזמן גם לא ניתן היה לייצא את האוטומציות והיה צריך לנהל רישום ידני מה עושה כל אוטומציה ואיך. ממש לאחרונה, Monday הוסיפה את האפשרות לייצא לקובץ csv את כל האוטומציות מכל בורד. אם יש לכם מאות בורדים, תצטרכו לעשות זאת אחד-אחד ולשמור קובץ אקסל עבור כל בורד. אפשר כמובן לייבא את הקבצים לבורד שתיצרו בשם "האוטומציות שלנו" ואותו לייצא לאקסל אחד, כך שהכל יהיה בתוכו, אך עדיין זה מחייב ברמה יום-יומית לנהל יצוא של אוטומציות לאקסלים כדבר שבשגרה. ה-API של Monday אינו מאפשר לקרוא את פירוט האוטומציות של לוח. המשמעות: אם תאבדו לוח, ותבנו אותו מחדש, תצטרכו לבנות מחדש ידנית את כל האוטומציות שלו. יתרה מזאת, גם בשכפול לוח או יצירת תבנית של לוח – לא תמיד כל האוטומציות עוברות (אוטומציות שמשלבות לוחות אחרים, או אינטגרציות חיצוניות עם הגדרות ייחודיות). לדוגמה, אם יש לכם בורד עם 44 אוטומציות, יתכן ורק 39 ישוחזרו ויהיו פעילות לאחר יצירה מתבנית או שכפול.

  • כיצד נתמודד? :

    • הדרך העיקרית שתקפה לאחרונה היא ייצוא רשימת האוטומציות ל-csv. ניתן לייבא את האקסלים לבורד מאנדיי (כפי שהזכרתי מקודם "האוטומציות שלנו"). כל שורה היא אוטומציה, עם עמודות: באיזה לוח, מי יצר, מה הטריגר ומה הפעולה, והערות (כמו "למה נועדה האוטומציה"). זה יכול להיות חלק ממסמך נוהלי המערכת. כלומר יש להשתמש בלוח Monday עצמו כדי לנהל את רשימת האוטומציות (אירוני, אך יעיל) – לוח שבו כל פריט הוא אוטומציה, כולל קישור ללוח המקור, תיאור מילולי שלה, תאריך יצירה וכד’. כך המידע על האוטומציות הופך לגלוי ושיתופי ולא "קבור" בתוך הגדרות הלוח. כמובן שגם את הלוח התיעודי הזה צריך לגבות, אבל לפחות כל המידע מרוכז בקובץ אחד.

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

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

• אינטגרציות חיצוניות: הכוונה לחיבורי Monday לאפליקציות אחרות (דרך ה-Integration Center, כמו אינטגרציה ל-Gmail, ל-Slack, לזאפייר וכו'). גם הן מוגדרות כמתכונים (Recipes) ולעיתים משולבות באוטומציות. אלו לא מגובות בשום צורה, כי הן למעשה סוג של אוטומציה. תצטרכו לתעד אותן גם כן (בשיטות שהוזכרו קודם ואף בצילום מסך של הגדרות כל אינטגרציה – לדוגמה, חיבור ללוח שנה: צילום המפה איזו שדה הולך לאיזה שדה).

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

• תצוגות (Views) מותאמות: Monday מאפשרת להציג את נתוני הלוח בצורות שונות (לוח שנה, גנט, Kanban, פילטרים שמורים וכו'). התצוגות והפילטרים שהגדרתם לא ניתנים לגיבוי ישיר. אם לוח נמחק ותיצרו חדש, תצטרכו להגדיר שוב את כל התצוגות המיוחדות (למשל תצוגת לוח שנה עם סינון מסוים).

  • מה אפשר לעשות? לשמחתנו, זה כנראה החלק הפחות מסובך לשחזור – כי ברגע שהנתונים קיימים, יצירת תצוגה זה פעולה ידנית מהירה (לא כמו להזין 100 פריטים). אבל אם יש לכם תצוגות מאוד מורכבות (לדוגמה, Table עם 5 פילטרים וחלוקה לפי חודשים), אולי כדאי לצלם את הגדרות הפילטר/תצוגה (צילום מסך של ה-Filter bar וכו'). כמו כן, דשבורדים לא מגובים, אז אם השקעתם הרבה בבניית דשבורד – תעדו אילו ווידג'טים ומסננים היו בו כדי שתוכלו לבנותו מחדש.

• טפסים (Forms) ו-Workdocs: טפסים שנבנו על גבי לוח (לשיתוף חיצוני) הם חלק מהגדרת התצוגה של הלוח ורוב הסיכוי שהם לא מגובים. רצוי לשמור את הקישור לטופס או צילום של מבנה הטופס. Workdocs כבר הזכרנו – אותם יש לייצא כ-PDF (אם התוכן בעברית - ע"י הדפסה ל-PDF), או להעתיק לתוכנה אחרת (Google Docs למשל) כדי שישמר תוכנם.

לסיכום סוגיה זו, ניתן לומר: הנתונים מובטחים – ההגדרות פחות. נכון ל-2025, זהו פער שמכיר גם צוות Monday; יש דרישות לשפר זאת בעתיד. ייתכן שבעתיד יפותח API לתיעוד אוטומציות או “export settings”, אך עד אז הארגון צריך לפתח משמעת תיעוד. אמנם זה לא חכם כלכלית כמו גיבוי אוטומטי, אך חשבו על מצב שבו המערכת קורסת והצלחתם להחזיר את הנתונים, אך כל התהליכים האוטומטיים שבורים – התיעוד יאפשר לצוות הטכני לשחזר תוך יום עבודה את כל הFlow-ים. ללא תיעוד, יהיה צורך לשחזר מהזיכרון, מה שגוזל זמן רב יותר ועלול לגרום לפספוסים.

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

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

• סיכון תפעולי וארגוני: בראש ובראשונה, איבוד מידע יכול לשתק את פעילות הארגון. דמיינו עמותה שאיבדה את רשימת הפונים ועבודתה מתנהלת דרך Monday - השירותים למוטבים יעצרו, משימות ייפלו בין הכיסאות, עובדי הארגון יתקשו לקבל החלטות ללא נתונים. בסקר מנהלים אחד 57% ציינו שפגיעה בנתונים תגרום לנזק למוניטין המותג ולפגיעה תפעולית משמעותית. אפילו אובדן חלקי (נניח, איבוד חודש של עדכונים) יכול לגרור כפילויות עבודה, חוסר אמון במערכת וירידה בפרודוקטיביות. מעבר לכך, אובדן נתונים פוגע במורל: הצוות מרגיש ש"הלך לו" המאמץ, מה שמשפיע על המוטיבציה.

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

• סיכון משפטי ורגולטורי: תלוי בסוג המידע שב-Monday, עשויות לחול חובות רגולטוריות לשמור עליו. למשל:

  • רגולציות פרטיות (GDPR, חוק הגנת הפרטיות הישראלי): חוקים אלה דורשים מן הארגון כ"בעל מאגר מידע" לנקוט אמצעי אבטחה סבירים להגן על המידע. אובדן מוחלט של נתונים אישיים עלול להיחשב כהפרת חובת האבטחה, גם אם זה לא דליפה אלא מחיקה. לדוגמה, GDPR מדבר על שלמות (Integrity) וזמינות (Availability) של מידע אישי. אם אין לכם גיבוי ולכן המידע אינו זמין עוד לנושא המידע, זה עלול להוות בעיה. כמו כן, אם נמחקו לכם נתונים שאמורים להישמר לפרק זמן מינימלי בחוק – לא עמדתם בחובת שמירת הרשומות. במקרים קיצוניים, רגולטור יכול לראות בכך רשלנות.

  • רגולציות סקטוריאליות: בארגוני בריאות, פיננסים, חינוך וכו’, יש דרישות המשכיות עסקית. למשל, תקן HIPAA (לגופי בריאות בארה"ב, ייתכן שרלוונטי אם יש מידע רפואי), מחייב תוכנית גיבוי ושחזור חירום של נתונים רפואיים. גם בתקנות אבטחת מידע בישראל (תחת חוק הגנת הפרטיות) מוטלת חובה על בעל מאגר מידע בינוני/גבוה לקיים נוהל גיבוי תקופתי ולבדוק אותו. אי-עמידה בזה עלולה לחשוף את הארגון לסנקציות מנהליות במקרה של ביקורת.

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

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

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

דרכי התגוננות מראש

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

• בניית תוכנית המשכיות עסקית (BCP): אפילו ארגון קטן יכול להפיק מסמך קצר שמנתח תרחישי סיכון ומגדיר תוכנית פעולה. יש לזה גם ערך רגולטורי: למשל ISO 22301 (תקן לניהול המשכיות), או דרישות רגולטוריות כמו של בנק ישראל - דורשים תוכנית כזו. בתוכנית תתואר: מה נעשה אם מערכת SaaS קריטית אינה זמינה? כמה זמן נוכל לשרוד בלי? מי מקבל החלטות? איפה הגיבויים? וכד’. עצם הכנת התוכנית תחשוף חולשות (אולי תגלו שאין גיבוי לנתון X, ואז תוסיפו אותו). התוכנית גם תקצה אחריויות – מי אחראי לבצע גיבוי, מי אחראי לבדוק אותו, מי ישתתף בשחזור במקרה אסון וכו'.

• יישום פתרונות גיבוי ושחזור כפי שפירטנו: הטמעת הכלים שציינו (ידניים או אוטומטיים) היא הגנה ראשונה במעלה. העיקר שיהיה לפחות עותק אחד של הנתונים מחוץ לסביבת הייצור של Monday – בין אם בענן גיבוי, במייל שלכם או על דיסק – כך שאם Monday נופל, יש לאן לפנות. חוק מקובל בעולם הגיבויים הוא כלל 3-2-1: לשמור 3 עותקים של הנתונים בשני מדיות שונות, ואחת מהן off-site (מחוץ לאתר). שימוש ב-SaaS גיבוי + שמירת ZIP אצלכם כבר ממלא את הכלל הזה.

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

  • הגדרת הרשאות משתמשים שקולות (לא כל אחד צריך לקבל הרשאת אדמין או יכולת מחיקה).

  • הפעלה של אימות דו-שלבי (2FA) בחשבון, כדי למנוע פריצה של גורם חיצוני שיכול למחוק מידע בזדון.

  • ניטור לוגים (Logs): אדמין צריך לסקור מדי פעם את Audit Log (בחשבון Enterprise), או לשים לב לעדכונים חריגים. שירותי גיבוי כמו ProBackup יכולים לשלוח התראה על מחיקה המונית - כלי כזה הוא למעשה מנגנון הגנה: יידע אתכם מיידית כדי שתפעלו.

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

• הסכמי שירות והבנות מול ספקי SaaS: חלק מההגנה הוא לקבל הכרה בסיכונים גם מצד הספק. למשל, Monday.com מספקת הסכם רמת שירות (SLA) ותנאי שימוש, אך הם כנראה מסירים אחריות לאובדן נתונים עקב שימוש לקוי. אם אתם לקוחות Enterprise, אפשר לעתים לנהל מו"מ להבטחות טובות יותר. ארגון בישראל אולי ירצה לוודא (בחוזה או מול הנהלת Monday) שסביבת הנתונים מוגנת. Monday עצמה עומדת בתקני אבטחה מחמירים (ISO27001, SOC2), כך שההסתברות לאירוע קטסטרופלי בשרתי Monday נמוך מאוד. הבעיה העיקרית היא בצד שלכם - ולכן ההסכם החשוב הוא מה תעשו אתם.

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

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

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

ארגון חברתי ייתכן שאין לו מומחה סייבר במשרה מלאה, אך הוא עדיין צריך (ורוצה) לוודא שהפתרונות שנבחרו לגיבוי ושחזור תואמים סטנדרטים בין-לאומיים כגון SOC 2, ISO 27001, ואחרים כמו GDPR, HIPAA אם רלוונטי. איך עושים זאת?

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

• חברת Monday עצמה מחזיקה באישורי ISO/IEC 27001 ו-27018 (אבטחת מידע והגנת מידע בענן), וכן עברה ביקורות SOC 2 Type II ו-SOC. משמעות הדבר שאפשר לבטוח יחסית בתהליכי האבטחה שהם מיישמים (הצפנת מידע, בקרות גישה, תוכניות המשכיות וכו'). כאשר אתם משתמשים בכלי מובנה של Monday (כמו Board & Doc Backups), אתם נשארים בתוך סביבה מאושרת זו.

• אם פונים לספק חיצוני – ודאו שגם הוא מציג עמידה בתקנים. למשל, ProBackup מצהירים שהם חברה עם תאימות SOC2 ו-GDPR. מערכת Rewind כאמור מצהירה על SOC2/3 ויכולת לתמוך ב-HIPAA ו-ISO27001 (למשל עם תכונות SSO, בחירת Data center, לוגים וכו'). מידע כזה לרוב מפורסם באתרי הספקים (בדפי “Trust” או security). בחירת ספק גיבוי שאינו מוסמך בשום תקן עלולה להציב אתכם בשאלה מיותרת בעת ביקורת. לעמותות בישראל אולי אין דרישה פורמלית ל-SOC2, אבל אם בעתיד תצטרפו ליוזמה ממשלתית או תפעלו עם גוף גדול, סביר שישאלו אתכם על כך. אז עדיף מראש לעבוד עם פתרונות בעלי חותמות מוכרות.

היבטי אבטחת מידע בפתרון הגיבוי עצמו: עמידה בתקנים אינה רק תעודה – זה גם אופן השימוש:

• הצפנת מידע רגיש: אם אתם שומרים את קובצי הגיבוי באופן עצמאי (נניח, על כונן או בענן פרטי), השתדלו להצפינם או לפחות להגן בסיסמה. תקני אבטחה דורשים שהמידע ב-at rest (באחסון) יהיה מוגן. Monday ושותפיה עושים זאת אוטומטית (למשל, כל גיבויי Monday ב-AWS מוצפנים, וכך גם בתוכנות גיבוי רציניות). אך אם אתם מורידים ZIP ושמים ב-Google Drive האישי – הצפנה תלויה בכם. ניתן להשתמש בכלי כמו 7-Zip להצפין את הארכיון, או לאחסן בתוך כונן וירטואלי מוצפן.

• בקרת גישה: ודאו שרק אנשים מורשים יכולים לגשת לגיבויים. למשל, את ה-ZIP שהורדתם – אולי עדיף שלא יהיה זמין לכל חברי הצוות, אלא רק למנהל המערכת או מנמ"ר. כך מצמצמים סיכון דליפה. זכרו - קובץ ה-ZIP מכיל גם את כל הבורדים הפרטיים, אלו שרק עובדים מורשים הוזמנו אליהם ועכשיו הכל פתוח ונגיש ברמת אקסל. אם משתמשים בשירות גיבוי SaaS, לרוב הוא יאפשר לך ליצור חשבון מנהל אחד; הגבילו את מי שמקבל גישה אליו. חלק מהשירותים (ProBackup ברמות גבוהות, Rewind) תומכים ב-SSO ובניהול משתמשים – מה שמקל לעמוד במדיניות גישה.

• שמירה על Data Residency ורגולציית פרטיות: עבור ארגון ישראלי, יתכן שיעלה נושא מיקום הנתונים – במיוחד אם עובדים עם מידע רגיש. Monday מציעה כיום אחסון באירופה (גרמניה) או בארה"ב, לעיתים לפי בחירת הלקוח (כשיוצרים חשבון זה נקבע בעצם מבלי להיוועץ עם הלקוח), כדי לעמוד למשל בדרישות GDPR. בדקו שהגיבוי לא סותר זאת. לדוגמה, הגדרה ב-ProBackup לשמירת הנתונים ב-Google Sheets – המשמעות שהיא תעביר נתונים לשרתי גוגל (שגם הם בד"כ באירופה או ארה"ב). עבור רוב העמותות זה תקין (GDPR-wise, יש הסכם עיבוד נתונים וכו’), אבל אם יש חומר ממש רגיש אולי תעדיפו פתרון שמשאיר הכל באירופה. Rewind לדוגמה מאפשר בחירת Data Residency לאזור מסוים, ו-HYCU/Keepit מתגאות בכך שהן שומרות נתונים בענן נפרד ללא sub-processors. בקיצור, אם יש לכם דרישה רגולטורית (נאמר, שחייבים לשמור מידע רפואי בשרתי EU) – ודאו מראש שספק הגיבוי תומך בכך, או בחרו בגיבוי פנימי (למשל Board & Doc Backups שיישאר על Monday EU).

• המשכיות עסקית של הספק: קצת אירוני, אבל כדאי לשאול – מה יקרה אם ספק הגיבוי עצמו חווה כשל? למשל, אם בחרתם בפתרון X, האם יש לו תוכנית המשכיות, SLA לזמינות, גיבוי משלו? ספקים גדולים כמו Rewind ו-HYCU בוודאי, סטארטאפים קטנים – מומלץ לבדוק. יש בזה היבט משפטי: קראו את תנאי השירות שלהם, כדי להבין אחריות. אם הם SOC2, סימן שעשו עבודה גם בפן הזה.

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

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

• לנצל משאבים קיימים: ארגונים רבים חולקים ידע; אולי יש מדריך ייעודי לעמותות בישראל בנושא המשכיות עסקית. אפשר גם לקרוא את דוחות SOC2 של הספקים (בד"כ זמינים תחת NDA) – ולראות מה הם מכסים. Rewind לדוגמה מציעה במפורש פתרונות כדי לעמוד ב-ISO27001 ו-HIPAA - כלומר, אם אתם צריכים להציג לעמותה שעומדים בתקנים, אפשר לכלול את השימוש בכלי כזה כחלק מהראיות לכך.

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

לבסוף, נזכיר שספק כמו Monday.com בעצמו עומד ב-SOC2, ISO, GDPR וכו’, אך מודל האחריות המשותפת אומר: הם מתחזקים תשתית מאובטחת וזמינה, אתם צריכים לטפל בהגנה על הנתונים עצמם (ממחיקה או שימוש לרעה). התקנים מגדירים זאת: למשל ISO27001 דורש שיהיו נהלי גיבוי ושחזור – ופה תיארנו כיצד ליישמם הלכה למעשה.

המלצות ישימות לארגונים בישראל – תרחישי קיצון ועלות-תועלת

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

1. לאמץ גישת Backup Hybrid: השתמשו בשילוב של גיבוי מובנה ידני וגיבוי אוטומטי SaaS, בהתאם למשאבים שלכם. לדוגמה:

• בצעו יצוא חשבון מלא אחת לחודש כבסיס (עלות 0 ש"ח, זמן מנהל – אולי חצי שעה בחודש).

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

  • לקטנים מאוד (פחות מ-10 משתמשים): ייתכן שתוכלו לנצל את Rewind בחינם (לבדוק הטבה לעמותות). זו אופציה מצוינת – תקבלו 365 ימי היסטוריה ללא עלות, רק הקפידו להגדירו נכון.

  • לארגון 10-50 משתמשים: ProBackup בתוכנית Plus (עלות ~$300 לשנה) או Rewind (כ-$200 לחודש, אולי פחות במספר מועט של משתמשים) – שניהם יתנו לכם שקט נפשי. בהיבט עלות-תועלת: סכום זה הוא מזערי ביחס לשכר עבודה שיבוזבז על שחזור ידני אם לא תגבו. למשל, אם תקרוס מערכת ותצטרכו 5 עובדים שישחזרו מידע במשך שבוע – זה כבר עלות של אלפי ש"ח. לעומת זאת, מנוי גיבוי בשנה עולה כמה אלפים בודדים.

  • אם הארגון גדול (100+ עובדים על Monday) – ודאי להשקיע בכלי אוטומטי, אולי אפילו כלים מתקדמים כמו Keepit/FluentPro המאפשרים אינטגרציה עם נהלי הארגון. העלות שם גבוהה יותר, אך לארגון גדול יש גם דרישות רגולציה מחמירות יותר בד"כ (ואולי ביטוח שמחייב).

• למי שבכל זאת דל בתקציב ואינו זכאי לחינמיים: ניתן לנסות לנצל את Marketplace – למשל, התקנת Board & Doc Backups (כ-180 דולר לשנה ל-10 משתמשים). היא יכולה לתת לכם לפחות פתרון פנימי לא מאוד יקר.

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

2. נהלו "קלסר חירום" עם מידע חיוני: נוכח המציאות בארץ (כמו מלחמה / מגפה או אסון טבע), הכינו באופן ייעודי גיבוי אופליין למקרי חירום קיצוניים:

• זה יכול להיות קלסר מודפס המכיל רשימות של מוטבים, רשימות ציוד חיוני, אנשי קשר וכד’. עדכנו אותו לפחות אחת לחודש. אפשר להפיק את הרשימות הללו ישירות מ-Monday (ייצוא/הדפסה של לוחות רלוונטיים).

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

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

3. מנעו "Single Point of Failure": ברוח זו, דאגו שתמיד יהיו שני אנשים לפחות שמכירים את נוהלי הגיבוי/שחזור, ושיש להם הרשאות מתאימות. למשל, ש-לא רק מנהל אחד יודע איך לגשת לשירות הגיבוי בענן – מה אם הוא בחופש בעת אירוע? חלק מהמשכיות עסקית היא גיבוי של תפקידים ולא רק של מידע.

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

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

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

• ודאו שיש לכם התראות כניסה חריגה (MFA כאמור) ושהצוות ידע לזהות התנהגות מוזרה.

• במקרה של חשד לאירוע סייבר, יש להתמודד עמו מיד: נתקו גישה (שנו סיסמאות), תקשרו פנימית, הפעילו שחזור מהגיבויים שלכם בהקדם. שירותי גיבוי כמו Rewind/ProBackup יכולים לשחזר חשבון שלם תוך שעות – אולי אפילו לפני ש-Monday עצמה הייתה עושה זאת עבורכם.

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

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

סיכום: כדי להבטיח המשכיות עסקית מלאה ב-Monday.com, ארגון בישראל צריך לשלב טכנולוגיה ותהליכים: גיבוי קבוע של נתונים (בלחיצת כפתור או אוטומטי), שחזור מהיר דרך הכלים המתאימים, תיעוד של מה שלא מגובה אוטומטית, ותכנון מבעוד מועד של תרחישי קיצון כמו מלחמה או קריסת שרתים. החדשות הטובות הן שיש היום פתרונות זמינים וקלים לשימוש – גם ללא מומחיות טכנולוגית – שיכולים להציל את הארגון ממקרה אסון. ההשקעה בגיבוי מניבה החזר גבוה מאוד במונחי סיכון. אמון במערכת SaaS כמו Monday הוא מצוין – אבל יש תמיד לשאול עד כמה נתוני הארגון באמת בטוחים. תאונות קורות. יש להגן על הארגון מכל אסון או אובדן נתונים באמצעות תוכנית גיבוי ושיקום. במילים אחרות, עם ההכנה הנכונה – תוכלו לישון בשקט בידיעה שגם אם ייפול עלינו טיל איראני או חות'י... הנתונים העסקיים של הארגון ישמרו מוגנים וזמינים, והארגון ימשיך לתפקד ולסייע למי שתומך בו.

הערה: מאמר זה הוכן ע"י אהוד שם טוב תוך הסתייעות ב-Deep Research של ChatGPT ו-Gemini.