דלגו לתוכן
agentical

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

בקצרה: בכל אחד מחמשת הכלים אפשר לחזור לגרסה קודמת, אבל ברוב המקרים זו חזרה של הקוד, והנתונים נשארים כמו שהם. גיבוי של הנתונים עצמם, שאתם משחזרים ממנו לבד, יש ב-Lovable (פעם ביום, כשבועיים אחורה), ב-Replit (למסד הנתונים החי, משבוע ועד 28 יום לפי התוכנית), וב-Base44 רק מתוכנית Elite ומעלה. ב-Emergent הגיבויים לא פתוחים לשחזור שלכם, וב-Bolt לא מצאנו בתיעוד גיבוי של הנתונים. ובכל מקרה, הגיבוי של הכלי נשמר אצל הכלי, ובחלק מהכלים הוא לא כולל את הקבצים שהועלו. לכן כדאי להחזיק עותק משלכם מחוץ לכלי, ולשחזר ממנו פעם אחת כדי לדעת שהוא עובד. כאן: מה כל כלי שומר, איך משחזרים בו, שגרה חודשית לעותק משלכם, ואיך בודקים שחזור.

מאת , מייסד Agentical

פורסם ב- , עודכן ב-

שלושה דברים שונים שקוראים להם "גיבוי"

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

  • חזרה לגרסה קודמת. כל כלי שומר את ההיסטוריה של השינויים שה-AI עשה, ומאפשר לחזור אחורה. ברוב הכלים זו חזרה של הקוד והמסכים בלבד: ב-Lovable היא לא נוגעת בנתונים[2], ב-Emergent הרשומות נשארות כמו שהן[16], וב-Bolt חזרה לגרסה לא משנה את מסד הנתונים[20]. ב-Replit אפשר לכלול בה את מסד הנתונים של הפיתוח, אבל לא את זה שהלקוחות עובדים בו[11].
  • גיבוי של הנתונים בתוך הכלי. עותק של הטבלאות שהכלי שומר בעצמו, ומאפשר לכם להחזיר ממנו רשומות. הוא קיים רק בחלק מהכלים, לתקופה מוגבלת, ולפעמים רק בתוכניות מסוימות.
  • עותק משלכם, מחוץ לכלי. עותק של הנתונים, של הקבצים שהועלו, של רשימת המשתמשים ושל הקוד, שמור במקום ששייך לעסק. זה הגיבוי היחיד שלא תלוי בכלי, בתוכנית שלכם או בגישה לחשבון.

למה הגיבוי של הכלי לא מספיק לבד

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

וגם הגיבוי הטוב ביותר של כלי לא מכסה הכל. ב-Lovable הוא לא כולל את הקבצים שהועלו[1], וב-Base44 הוא לא כולל לא את הקבצים ולא את המשתמשים[6]. תמונה של מוצר, חשבונית שלקוח העלה או חוזה חתום לא יחזרו משם.

מה כל כלי שומר בשבילכם, במבט אחד

גיבוי ושחזור בחמשת הכלים
כליחזרה לגרסה קודמתגיבוי של הנתונים, ולכמה זמןמה לא בגיבוי
Lovableקוד בלבד[2]גיבוי יומי של מסד הנתונים, כ-14 יום אחורה. חוזרים לרגע של גיבוי, לא לשעה שביניהם[1]קבצים שהועלו[1]
Base44קוד ועיצוב. לנתונים יש גיבוי נפרד[6]רק ב-Elite (7 ימים) וב-Business וב-Enterprise (30 יום)[6]. בכל התוכניות רשומה שנמחקה נשמרת 30 יום[7]קבצים שהועלו, ומשתמשים[6]
Replitקוד, ואם בוחרים בזה גם מסד הנתונים של הפיתוח[11]למסד הנתונים החי: חזרה לכל רגע, עד 7 ימים ב-Core ועד 28 יום ב-Pro וב-Enterprise, וגיבוי יומי שמפעילים בהגדרות[10]קבצים באחסון של האפליקציה, שאין להם גרסאות קודמות[14]
Emergentקוד ומבנה מסד הנתונים, לא הרשומות[16]אין גיבוי שמשחזרים ממנו בעצמכם. הגיבויים קיימים לטובת הפלטפורמה[15], ולכמה זמן, התיעוד לא מפרטהכל, מבחינתכם
Boltהפרויקט, לא מסד הנתונים[20]לא מצאנו בתיעוד גיבוי של הנתונים. יש גיבויים מתוארכים של הפרויקט עצמו[21]הנתונים והקבצים

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

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

Lovable: גיבוי יומי של מסד הנתונים, והקבצים בנפרד

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

  1. פותחים את רשימת הגיבויים

    בפרויקט: More, אחר כך Cloud, Database ואז Backups. ליד כל גיבוי כתובה השעה שבה נלקח, לפי שעון UTC[1]. כדי לדעת מה השעה הייתה בישראל, מוסיפים שעתיים בחורף ושלוש שעות בקיץ.

  2. משחזרים

    לוחצים Restore to this backup ומאשרים. במשך כמה דקות מסד הנתונים לא זמין[1], וזה אותו מסד נתונים שהאפליקציה המפורסמת עובדת איתו, אז עדיף לעשות את זה בשעה שקטה.

  3. בודקים את האפליקציה

    אם מבנה הטבלאות השתנה אחרי הגיבוי, הקוד עלול כבר לא להתאים לו. Lovable ממליצה לבקש בצ׳אט שיבדוק את האפליקציה ויתקן אי-התאמות[1].

מה שנוסף אחרי הגיבוי, נמחק

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

העותק שלכם מ-Lovable

  • מסד הנתונים: ייצוא מלא מההגדרות המתקדמות של Cloud, עם מבנה הטבלאות, הנתונים וחשבונות המשתמשים, כולל הסיסמאות בצורתן המוצפנת. אפשר לבקש ייצוא אחד ב-24 שעות, עד מסד נתונים של 15GB וקובץ של 5GB, ורק כשצד השרת פועל[3]. הקישור מגיע במייל, והקובץ נשמר גם באחסון של הפרויקט, כלומר בתוך Lovable[3], אז מורידים אותו החוצה. הצעדים המלאים במדריך הייצוא מ-Lovable.
  • קבצים: הייצוא של מסד הנתונים לא כולל אותם. מורידים אותם מ-More, Cloud ואז Storage: בוחרים פריטים, וכמה פריטים יחד יורדים כקובץ ZIP[4].
  • קוד: חיבור ל-GitHub, ל-GitLab או ל-Bitbucket, שזמין בכל התוכניות[5], שומר עותק מעודכן של הקוד מחוץ ל-Lovable.
  • מה לא נכנס: הסודות של הפרויקט, כלומר המפתחות לשירותים חיצוניים, לא כלולים בייצוא[3]. רשמו אילו מפתחות יש ואיפה מנפיקים כל אחד, בלי להעתיק את המפתחות עצמם.

Base44: פח מחזור לכולם, גיבוי מלא רק בתוכניות הגבוהות

ב-Base44 יש שתי רשתות ביטחון לנתונים. הראשונה קיימת בכל התוכניות: רשומה שנמחקה נשמרת 30 יום, ואפשר להחזיר אותה מ-Recently deleted, בתפריט של הטבלה[7]. השנייה היא גיבוי אוטומטי שנשמר בכל פעם שהנתונים משתנים, ואפשר לחזור ממנו לנקודת זמן קודמת. הוא קיים רק בתוכנית Elite, שבעה ימים אחורה, ובתוכניות Business ו-Enterprise, 30 יום אחורה[6]. בתוכניות שמתחת ל-Elite, רשומה ששונתה בטעות או ייבוא שהשתבש לא מתוקנים מגיבוי של Base44.

  1. נכנסים לגיבויים

    Dashboard, אחר כך Data, ואז הלשונית Backup & Restore. הנקודות מסודרות מהחדשה לישנה, ולכל אחת כתוב כמה טבלאות השתנו בה[6].

  2. בוחרים: טבלה אחת, או הכל

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

  3. אם טעיתם, מבטלים

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

טוב לדעת

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

העותק שלכם מ-Base44

  • נתונים: קובץ CSV לכל טבלה, מ-Data, תפריט הטבלה ואז Export[7]. בתוכנית בלי גיבוי של Base44, זה העותק היחיד של הנתונים שלכם, אז עוברים על כל הטבלאות ולא רק על הגדולות.
  • משתמשים: מ-App Users, תפריט הפעולות ואז Export to CSV[8]. המשתמשים לא נכללים בגיבוי של Base44 בשום תוכנית[6]. מה יוצא מרשימת המשתמשים, ומה לא.
  • קבצים: בטבלה נשמרת רק הכתובת של כל קובץ, והקובץ עצמו לא בגיבוי[6]. איך מורידים את הקבצים עצמם.
  • קוד: סנכרון דו-כיווני עם GitHub, מתוכנית Builder ומעלה[9].

מחברים את GitHub כשהאפליקציה עובדת

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

Replit: שני מסדי נתונים, ולכל אחד דרך שחזור משלו

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

  • מסד הנתונים של הפיתוח חוזר יחד עם נקודות השמירה (Checkpoints) שהסוכן של Replit יוצר, עד שבעה ימים אחורה, בכל התוכניות[10]. כברירת מחדל, חזרה לנקודת שמירה לא נוגעת בו. כדי לכלול אותו, מסמנים Database תחת Additional rollback options[11].
  • את מסד הנתונים החי אפשר להחזיר לכל רגע בתוך חלון הזמן: עד שבעה ימים ב-Core, ועד 28 יום ב-Pro וב-Enterprise. כל תוכנית מתחילה בשבעה ימים, ואת החלון מאריכים בהגדרות של מסד הנתונים החי. חלון ארוך יותר צורך יותר אחסון, ולכן עולה יותר[10].
  • למסד הנתונים החי אפשר להוסיף גיבוי מלא פעם ביום: Database, בוחרים את מסד הנתונים החי, Settings, ואז Scheduled backups תחת Advanced. הגיבוי מתחיל לפעול רק כשבוחרים כמה זמן לשמור אותו[10].

הקוד והנתונים חוזרים בנפרד

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

העותק שלכם מ-Replit

  • מסד הנתונים החי: Replit מתארת העתקה בכלי הסטנדרטי של PostgreSQL, בפקודה אחת במעטפת (Shell) של הפרויקט. הפקודה כפי שהיא מופיעה מעתיקה את מסד הנתונים של הפיתוח, ולכן מחליפים בה את הכתובת בכתובת החיבור של מסד הנתונים החי, מהלשונית Settings שלו. את הקובץ שנוצר מורידים מעץ הקבצים, ולא שומרים ב-GitHub, כדי שהנתונים לא ייכנסו למאגר הקוד[12]. מי שלא נוח לו במעטפת, נותן את הצעד הזה למפתח. הצעדים המלאים במדריך ל-Replit.
  • משתמשים: כשהאפליקציה משתמשת ב-Replit Auth, כל משתמש נכנס עם חשבון Replit, ו-Replit יוצרת לו רשומה במסד הנתונים של האפליקציה[13]. הרשומות יוצאות עם העותק של מסד הנתונים. החשבונות עצמם נשארים אצל Replit. מה זה אומר כשעוברים.
  • קבצים: לאחסון הקבצים של Replit (App Storage) אין גרסאות קודמות ואין מדיניות שמירה[14], כך שקובץ שנמחק לא יחזור מגרסה קודמת. עותק שלהם דורש פעולה שמורידה אותם, ואותה מבקשים מהסוכן של Replit או ממפתח.
  • קוד: Download as zip מהתפריט שבראש עץ הקבצים, או סנכרון עם GitHub[12].

Emergent: הגיבויים קיימים, אבל לא בשבילכם

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

  • חזרה בצ׳אט (Rollback): מחזירה את הקוד, החבילות, ההגדרות ומבנה מסד הנתונים, אבל לא את הרשומות עצמן. היא מוחקת את ההודעות והשינויים שאחרי הנקודה שבחרתם, ואין דרך לחזור קדימה. לכן לפני חזרה כזו כדאי ליצור Fork, עותק של האפליקציה שנשאר כמו שהוא[16].
  • חזרה בגרסה המפורסמת: את האפליקציה החיה אפשר להחזיר לאחת משלוש הגרסאות המפורסמות האחרונות, והכתובת ומסד הנתונים נשארים כמו שהם[17].

קוד ישן, נתונים חדשים

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

העותק שלכם מ-Emergent

ב-Emergent יש מסד נתונים לסביבת העבודה ומסד נתונים למערכת המפורסמת, וההבדל ביניהם קובע. ההעתקה שהתיעוד מתאר צעד אחרי צעד, מהטרמינל של סביבת העבודה, מוציאה את הנתונים של סביבת העבודה[18], ועמוד השאלות הנפוצות כותב שייצוא של הנתונים החיים עוד לא זמין בשירות עצמי[19]. במדריך ל-Emergent: איך מגיעים לעותק של הנתונים החיים, ואיך מוציאים את הקבצים. את הקוד שומרים עם Save to GitHub, מתוכנית Standard ומעלה[19].

Bolt: הפרויקט מגובה, הנתונים לא

Bolt שומרת גרסאות של הפרויקט, ואפשר לחזור אליהן מ-Version history, סמל השעון בתפריט העליון[20]. בנוסף יש גיבויים מתוארכים בהגדרות הפרויקט, תחת Backups. טעינה של גיבוי כזה יוצרת עותק חדש של הפרויקט (Fork), בלי לגעת בגרסה הנוכחית[21]. אבל כל אלה גיבויים של הפרויקט. לפי Bolt, חזרה לגרסה קודמת לא משנה את מסד הנתונים[20], והיסטוריית הגרסאות לא תומכת בשחזור שלו[22]. גיבוי של הנתונים שאפשר לשחזר ממנו לא מצאנו בתיעוד.

העותק שלכם מ-Bolt

  • נתונים: בכל טבלה מסמנים את כל השורות, בתיבת הסימון שבשורת הכותרת, לוחצים Export ובוחרים CSV או JSON. מי שמוגדר בפרויקט כצופה (Viewer) לא יכול לייצא[23]. עותק מלא של מסד הנתונים, עם המבנה שלו, אפשרי כשמעבירים אותו לחשבון משלכם בשירות מסד הנתונים ש-Bolt נשענת עליו, וזה דורש תוכנית Pro או Teams[24].
  • קבצים: במסך File Storage רואים את מאגרי הקבצים, אבל לפי התיעוד עוד אי אפשר לצפות משם בקבצים בודדים או לנהל אותם[25]. עותק שלהם דורש פעולה באפליקציה עצמה שמורידה אותם, ואותה מבקשים מ-Bolt או ממפתח.
  • משתמשים: במסך User Management רואים את המשתמשים האחרונים ומחפשים לפי מייל או מזהה[26]. ייצוא של הרשימה לא מצאנו שם.
  • קוד: מתפריט שם הפרויקט, Export ואז Download, יורדים כל קבצי הפרויקט כקובץ ZIP[20]. חיבור ל-GitHub שומר את כל ההיסטוריה של הפרויקט מחוץ ל-Bolt[27].

שגרה חודשית: עותק משלכם, מחוץ לכלי

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

  1. פותחים תיקייה עם התאריך

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

  2. נתונים

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

  3. משתמשים

    רשימת המשתמשים, אם הכלי מאפשר לייצא אותה. אם לא, רשמו כמה משתמשים יש ואיך הם נכנסים: מייל וסיסמה, חשבון Google, או חשבון של הכלי.

  4. קבצים

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

  5. קוד

    בודקים שהחיבור ל-GitHub פעיל ושהשינוי האחרון מופיע בו, או מורידים קובץ ZIP של הפרויקט.

  6. רשימת "מה לא בגיבוי"

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

קובץ גיבוי הוא מידע אישי

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

בדיקת שחזור: עותק הופך לגיבוי רק כשמשחזרים ממנו

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

  1. פותחים כל קובץ

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

  2. סופרים

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

  3. מחפשים שלוש רשומות מהימים האחרונים

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

  4. פותחים כמה קבצים

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

  5. שחזור לסביבת ניסיון

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

לא בודקים על המערכת החיה

שחזור לניסיון נעשה לסביבה נפרדת. שחזור למערכת החיה מחליף את הנתונים של הלקוחות, ובחלק מהכלים אי אפשר לבטל אותו. ב-Lovable, למשל, השחזור סופי[1].

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

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

  1. עוצרים. לא מבקשים מה-AI לתקן, לא מייבאים ולא משחזרים עדיין. כל שינוי נוסף מסבך את התמונה, ועלול להוסיף נתונים שיאבדו בשחזור.
  2. מבינים מה נפגע: הקוד (מסך שנשבר, כפתור שנעלם) או הנתונים (רשומות שנמחקו או השתנו). בעיה בקוד פותרים בחזרה לגרסה קודמת. בעיה בנתונים לא נפתרת כך.
  3. אם נמחקו רשומות ב-Base44, מחפשים קודם ב-Recently deleted, שם הן נשמרות 30 יום[7].
  4. לפני שחזור של נתונים, מורידים את המצב הנוכחי של הטבלאות שנפגעו, כדי לא לאבד את מה שנוסף מאז הגיבוי.
  5. משחזרים רק את מה שצריך: ב-Base44 אפשר טבלה אחת[6], ב-Replit בוחרים רגע מדויק במסד הנתונים החי[10], וב-Lovable חוזרים לגיבוי יומי שלם[1]. בכלי שאין בו גיבוי של הנתונים, מחזירים מהעותק שלכם, וזו עבודה למפתח.
  6. עוברים על התהליכים החשובים, כמו הרשמה, הזמנה ותשלום, ומחזירים ביד את הרשומות החדשות מהקובץ שהורדתם בצעד הרביעי.

בדיקה עצמית: יש לכם גיבוי שאפשר לסמוך עליו?

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

מה המספר אומר

  1. אף משפט, אחד או שניים

    עוד אין גיבוי שאפשר לסמוך עליו

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

  2. שלושה עד חמישה

    יש התחלה, ויש חור

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

  3. כל השישה

    יש לכם גיבוי

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

ואם המערכת עוברת לתשתית משלכם

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

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

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

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

איך הכנו את המדריך

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

נבדק מול התיעוד הרשמי ב-.

מקורות

  1. Database (Backup and restore) Lovable · נבדק ב-
  2. Revert and restore your project with version history Lovable · נבדק ב-
  3. Advanced settings (Export Lovable Cloud data, Pause Cloud, Remove Lovable Cloud) Lovable · נבדק ב-
  4. Storage Lovable · נבדק ב-
  5. Sync your Lovable project code with GitHub, GitLab, or Bitbucket Lovable · נבדק ב-
  6. Backup & Restore Base44 · נבדק ב-
  7. Managing your app data (Exporting data, Recently deleted) Base44 · נבדק ב-
  8. Deleting your app's user data (Giving someone their data) Base44 · נבדק ב-
  9. GitHub Integration Base44 · נבדק ב-
  10. Data recovery Replit · נבדק ב-
  11. Checkpoints and Rollbacks Replit · נבדק ב-
  12. Manually copy a project to another workspace (Copy the database) Replit · נבדק ב-
  13. Replit Auth Replit · נבדק ב-
  14. App Storage Replit · נבדק ב-
  15. Your data & ownership (Backups & data safety) Emergent · נבדק ב-
  16. Checkpoints: undo anything Emergent · נבדק ב-
  17. Publishing types Emergent · נבדק ב-
  18. Database (MongoDB) Emergent · נבדק ב-
  19. FAQs Emergent · נבדק ב-
  20. Backups, restore, and version history Bolt · נבדק ב-
  21. Project settings (Backups) Bolt · נבדק ב-
  22. Database (Version history and database restores) Bolt · נבדק ב-
  23. Database: Tables (Export or copy table data) Bolt · נבדק ב-
  24. Database: Advanced settings Bolt · נבדק ב-
  25. Database: File storage settings Bolt · נבדק ב-
  26. Database: User Management Bolt · נבדק ב-
  27. GitHub for version control Bolt · נבדק ב-

שאלות על גיבוי ושחזור במערכת שנבנתה בכלי AI

לא מצאתם תשובה? פשוט תשאלו אותנו
הגיבוי של הכלי כולל את התמונות והמסמכים שהועלו למערכת?

ב-Lovable וב-Base44 לא: הגיבוי מכסה את הטבלאות, והקבצים שמורים בנפרד[1][6]. לאחסון הקבצים של Replit אין גרסאות קודמות[14], ב-Emergent אין גיבוי שאתם משחזרים ממנו בעצמכם[15], וב-Bolt לא מצאנו בתיעוד גיבוי של הנתונים. לכן את הקבצים מורידים בנפרד, כחלק מהעותק שלכם, ובודקים שהם נפתחים.

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

בדרך כלל לא. ב-Lovable, ב-Emergent וב-Bolt חזרה לגרסה מחזירה את הקוד ולא את הנתונים[2][16][20]. ב-Base44 לנתונים יש גיבוי נפרד[6], וב-Replit חזרה לנקודת שמירה יכולה לכלול רק את מסד הנתונים של הפיתוח, ורק אם בחרתם בזה[11]. רשומות שנמחקו מחזירים מגיבוי של הנתונים, לא מהיסטוריית הגרסאות.

כל כמה זמן כדאי לשמור עותק משלי?

פעם בחודש כשגרה, ובנוסף לפני כל שינוי גדול, כמו ייבוא נתונים או שינוי במבנה הטבלאות. במערכת שנכנסות אליה הרבה הזמנות או פניות כל יום, כדאי שמפתח יקים ייצוא אוטומטי בתדירות גבוהה יותר. שימו לב שב-Lovable אפשר לבקש ייצוא מלא אחד בכל 24 שעות[3].

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

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

מה מכל זה אפשר לעשות בלי לדעת לתכנת?

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

רוצים לדעת איך המעבר ייראה אצלכם?

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

בואו נדבר וואטסאפ