גיבוי אתר לעסק: מה לגבות, מתי ואיפה.

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

למה "הספק מגבה" היא לא תשובה מספיקה

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

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

מה צריך לגבות, לפי סוג האתר

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

אתר וורדפרס או מערכת ניהול דומה

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

אתר סטטי שנכתב בקוד

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

אתר עם הזמנות, חנות או טפסים ששומרים מידע

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

ממה גיבוי מגן: ארבעה תרחישים

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

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

כל כמה זמן לגבות

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

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

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

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

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

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

מה לשאול את ספק האחסון

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

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

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

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

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

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

מה עוד שווה לגבות חוץ מהאתר

האתר הוא לא הדבר היחיד שקשה לשחזר. שמרו במקום מסודר גם:

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

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

צ'קליסט: האם הגיבוי שלכם מסודר

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

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

איך זה אצלי

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