גיבוי אתר וורדפרס: איך יודעים שאפשר באמת לשחזר את האתר?

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

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

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

מה בעצם צריך לגבות באתר WordPress?

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

1. קובצי האתר

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

2. מסד הנתונים

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

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

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

6 טעויות נפוצות בגיבוי אתרי וורדפרס

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

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

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

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

הסברתי איך עושים גיבוי נכון גם בסרטון קצר:

הצגת התמלול

ככה תמנעו מעצמכם עוגמת נפש.

למה פיקוד העורף אומר לשמור מים ואוכל לשעת חירום? אתם מבינים למה, נכון?

גם בעולם האתרים זה ככה.

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

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

יש שני סוגים של גיבויים.

הראשון הוא גיבוי דרך השרת. אם משהו משתבש באתר, אפשר לשחזר אותו דרך השרת.

הבעיה היא שאם יש פריצה או בעיה בשרת עצמו, יכול להיות שגם הגיבויים שנמצאים עליו ייפגעו.

הסוג השני הוא גיבוי חיצוני.

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

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

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

לפעמים כדאי להיות קצת פסימיים וללכת על בטוח.

2. מגבים רק את מסד הנתונים או רק את הקבצים

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

3. אף אחד לא בודק אם הגיבוי הסתיים

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

4. שומרים רק את הגיבוי האחרון

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

5. לא מנסים לשחזר אף פעם

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

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

6. לא יודעים מי אחראי על הגיבוי

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

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

כל כמה זמן צריך לגבות את האתר?

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

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

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

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

גיבוי חנות WooCommerce: כאן צריך להיות זהירים במיוחד

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

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

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

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

איך בודקים שגיבוי באמת מאפשר שחזור?

אני ממליץ לעבור על ארבע שאלות פשוטות:

האם אפשר לאתר את הגיבוי?

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

האם הוא כולל את כל המידע הרלוונטי?

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

האם אפשר לשחזר לסביבת בדיקה?

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

כמה זמן ייקח לחזור לעבוד?

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

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

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

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

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

גיבוי הוא רק חלק מתחזוקת אתר

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

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

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

שאלות נפוצות על גיבוי ושחזור וורדפרס

האם תוסף גיבוי חינמי מספיק?

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

אפשר לגבות אתר דרך חברת האחסון בלבד?

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

האם גיבוי יומי מבטיח שלא אאבד נתונים?

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

האם גיבוי כולל גם אימיילים מהדומיין?

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

האם צריך לשמור גיבויים לנצח?

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

ברגע האמת, הגיבוי צריך לעבוד

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

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