גיבוי אתר, איך לגבות נכון לפני שמשהו נשבר

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

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

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

• 3 עותקים של המידע: המקור ועוד שני גיבויים.
• 2 סוגי אחסון שונים: למשל גיבוי בחברת האחסון וגיבוי בשירות ענן.
• 1 עותק מחוץ לאתר: לא על אותו שרת, ורצוי לא אצל אותה חברה.

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

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

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

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

לוורדפרס יש תוספי גיבוי מוכרים, כמו UpdraftPlus, BackWPup, Duplicator ו-All-in-One WP Migration, וגם שירותים חיצוניים שמגבים מחוץ לשרת. השיקולים בבחירה:

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

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

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

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

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

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

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

• שירותי אחסון קבצים בענן, כמו Google Drive או Dropbox: נוח לאתרים קטנים, עם מגבלות נפח.
• אחסון אובייקטים, כמו Amazon S3, Backblaze B2 או Wasabi: זול לכמויות גדולות, עם אפשרות לשמירת גרסאות.
• שירותי גיבוי ייעודיים לוורדפרס, ששומרים מחוץ לשרת ומנהלים שחזור.
• המחשב שלכם: עותק נוסף מדי פעם, לא כפתרון יחיד.

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

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

• כמה גיבויים יומיים אחרונים.
• כמה גיבויים שבועיים.
• גיבוי חודשי לכמה חודשים אחורה.
• גיבוי ידני לפני כל שינוי גדול, שנשמר בנפרד.

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

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

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

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

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