הנה שאלה שרוב בעלי האתרים לא חושבים עליה עד שמאוחר מדי: אם השרת שלך היה מתמוטט עכשיו, כמה מידע היית מאבד?
התשובה הכנה תלויה לחלוטין במתי רץ הגיבוי האחרון שלך. אם הספק שלך מריץ גיבוי אחד ביום בחצות הלילה והשרת קורס ב-23:45, אתה עומד בפני כמעט 24 שעות של הזמנות אבודות, פוסטים, הגשות טפסים ורשומות לקוחות. זה לא סיכון תיאורטי — זה פשרה אמיתית שמובנית בצורה שבה רוב גיבויי האחסון עובדים.
להבין אסטרטגיית גיבויים פירושו להכיר שני מונחים שכדאי לדעת: RPO ו-RTO.
RPO ו-RTO: שני המספרים שמגדירים את הסיכון שלך
RPO הוא קיצור של Recovery Point Objective. הוא עונה על השאלה: כמה מידע אתה יכול להרשות לעצמך לאבד? אם ה-RPO שלך הוא 4 שעות, פירוש הדבר שאתה בסדר עם אובדן של עד 4 שעות שינויים בתרחיש כשל קיצוני. אם ה-RPO שלך הוא 24 שעות, אתה מקבל את העובדה שיום עבודה שלם עלול להיעלם.
RTO הוא קיצור של Recovery Time Objective. הוא עונה על שאלה אחרת: כמה זמן האתר שלך יכול להיות מושבת לפני שזה באמת פוגע בך? בלוג אישי אולי יכול לסבול כמה שעות של השבתה. חנות e-commerce שמעבדת הזמנות כל כמה דקות כנראה לא יכולה.
רוב האתרים הקטנים לא מגדירים את המספרים האלה במפורש. אבל הם בעצם מקבלים את ברירות המחדל שהספק שלהם קובע — שבדרך כלל זה גיבוי אחד ביום.
האם גיבוי אחד ביום מספיק?
עבור אתרים רבים, כן. פורטפוליו אישי, אתר תדמית, בלוג שמפרסם פעמיים בשבוע — לאבד כמה שעות של מידע בתקלה קטסטרופלית כואב אבל ניתן לשרוד אותו.
אבל שקול את התרחישים הבאים שבהם זה לא מספיק:
- חנות e-commerce שמעבדת עשרות הזמנות בשעה
- אתר מנויים שבו משתמשים יוצרים חשבונות ומגישים תוכן
- מוצר SaaS עם מסד נתונים שמשתנה כל הזמן
- כל אתר שמריץ משימה מתוזמנת או ייבוא שמשנה מערכי נתונים גדולים
במקרים כאלה, חלון גיבוי של 24 שעות הוא חשיפה אמיתית. הפתרון לא מסובך — פשוט צריך גיבויים תכופים יותר. אנחנו מאפשרים ללקוחות להגדיל את תדירות הגיבויים עד ארבע פעמים ביום, מה שמוריד את חלון אובדן המידע המקסימלי ל-6 שעות. עבור חנויות עם תנועה גבוהה, ההבדל הזה משמעותי מאוד.
גיבוי מלא מול גיבוי חלקי: מה בעצם נשמר
תדירות הגיבויים היא רק חלק מהתמונה. צריך גם להבין מה כל גיבוי בעצם לוכד.
גיבוי מלא מעתיק הכל: הקבצים שלך, מסדי הנתונים שלך, תצורת השרת שלך. זוהי תמונת מצב מלאה ככל האפשר. היא גם הדורשת הכי הרבה זמן ואחסון ליצירה.
גיבוי חלקי שומר רק רכיבים ספציפיים — בדרך כלל מסד הנתונים שלך, הקבצים שהעלית, או שניהם. אלה רצים מהר יותר ומשתמשים בפחות אחסון, ולכן ספקים רבים משתמשים בהם לחלונות הגיבוי באמצע היום תוך שמירת הגיבוי המלא לחלון הלילי.
המשמעות המעשית: אם אתה משחזר מגיבוי חלקי, אתה מקבל בחזרה את החלקים שנשמרו. גיבוי חלקי של מסד נתונים בלבד לא יעזור לך אם הבעיה היתה קובץ פגום בתבנית שלך. דע מה הגיבויים שלך כוללים לפני שתזדקק להם.
היכן מאוחסנים הגיבויים זה גם חשוב
גיבוי שמאוחסן באותו שרת כמו האתר שלך הוא לא באמת גיבוי — זו עותק שיעלם ברגע שהשרת עצמו יכשל. תמיד ודא שהגיבויים שלך מאוחסנים במיקום פיזי נפרד.
אותו הגיון חל על שמירת גיבויים. שלושים יום של גיבויים יומיים נותנים לך רשת ביטחון שימושית מפני בעיות שאינך מבחין בהן מיד — תוכנות זדוניות שישבו בשקט בקבצים שלך במשך שבועיים, פגיעה במסד נתונים שהתגנבה בהדרגה, עדכון תוסף גרוע שלא שמת לב אליו. חלונות שמירה ארוכים יותר עולים יותר אחסון אבל מספקים הרבה יותר גמישות כשמשהו משתבש.
אסטרטגיית גיבויים לפי סוג אתר
במקום להציע גישה אחת לכולם, הנה מסגרת מעשית לפי סוג אתר:
אתרים עם שינויים נמוכים (בלוגים, פורטפוליו, אתרי תדמית)
גיבוי מלא אחד ביום הוא כמעט בוודאות מספיק. התוכן שלך משתנה לעיתים נדירות, כך שסבילות ה-RPO שלך גבוהה. התמקד יותר בתהליך השחזור שלך — ודא שבדקת בפועל שחזור גיבוי לפחות פעם אחת, במקום להניח שזה עובד.
אתרים עם שינויים בינוניים (אתרי חדשות, פורומים פעילים, אתרי מנויים)
שני גיבויים ביום מצמצמים את חלון הגרוע ביותר ל-12 שעות. שקול האם הגיבוי הנוסף צריך להיות מלא או חלקי — גיבוי יומי של מסד נתונים בלבד לעיתים קרובות מכסה את הנתונים החשובים ביותר (רישומי משתמשים, הגשות תוכן) ללא העומס של גיבוי מלא.
אתרים עם שינויים גבוהים (E-commerce, SaaS, מערכות הזמנות)
ארבעה גיבויים ביום הוא נקודת ההתחלה הנכונה. מעבר לכך, כדאי לשקול גם אסטרטגיות ברמת האפליקציה: ייצוא הזמנות WooCommerce, לוגי טרנזקציות במסד הנתונים, או רפליקה משנית של מסד נתונים מחוץ לאתר בהתאם לסיכויים הכרוכים. אף לוח זמנים לגיבוי לא מחליף לחלוטין ארכיטקטורת נתונים טובה ברמת האפליקציה עבור מערכות קריטיות.
בדיקת גיבויים: השלב שכולם מדלגים עליו
גיבוי שמעולם לא שחזרת הוא גיבוי שאי אפשר לסמוך עליו. זה נשמע ברור מאליו, אבל הרוב המכריע של האנשים שמנהלים אתרים מעולם לא בדקו בפועל את תהליך השחזור שלהם.
הפתרון פשוט: תזמן בדיקת שחזור אחת לרבעון. רוב הספקים המנוהלים נותנים לך סביבת staging בדיוק למטרה זו. שחזר את הגיבוי האחרון שלך ל-staging, ודא שהאתר נטען כראוי, בדוק שמסד הנתונים שלם, וודא שהתצורה שלך במקום. כל התהליך בדרך כלל לוקח פחות מ-30 דקות — והוא מספר לך מיד אם משהו בתהליך הגיבוי שלך שבור.
הרגל שימושי אחד: כשאתה מקדם אתר staging לסביבת הייצור, התייחס לרגע כנקודת ביקורת. הפעל גיבוי טרי מיד לאחר המעבר, לפני שתנועה אמיתית כלשהי פוגעת בסביבה החדשה. זה נותן לך נקודת שחזור נקייה מהרגע שהאתר עלה לאוויר. (זו ההמלצה הסטנדרטית שלנו בכל פעם שמישהו משתמש בתהליך העבודה שלנו מ-staging לייצור — מחליפים, ואז מיד מאשרים שגיבוי רץ.)
העלות האמיתית של טעות בנושא הזה
אירועי אובדן נתונים הם לעיתים נדירות דרמטיים. שרתים לא מתפוצצים. מה שקורה בדרך כלל הוא שקט יותר: עדכון כושל מדרוס טבלת מסד נתונים, ייבוא תוסף גרוע משכפל ומפגע ברשומות, מפתח בעל כוונות טובות מוחק את הספרייה הלא נכונה. עד שמישהו מבחין, עלולים לחלוף ימים.
לכן אסטרטגיית גיבויים היא לא רק עניין של מניעת כשל קטסטרופלי — אלא עניין של שמירת אפשרויות כשדברים משתבשים בצורה עדינה. גיבויים תכופים יותר פירושם נקודות שחזור רבות יותר. נקודות שחזור רבות יותר פירושן שאתה יכול לחזור בדיוק לפני שהבעיה התחילה, לא לחצות הלילה שעבר.
הגדר את ה-RPO שלך לפני שתזדקק לו. בדוק מה הגיבויים שלך באמת כוללים. בדוק שחזור לפני שאתה תחת לחץ. אלה לא צעדים מסובכים — הם פשוט קלים לדלג עליהם עד לרגע שבו אתה לא יכול להרשות לעצמך שדילגת עליהם.
