גיבוי ושחזור מסדי נתונים - הבסיס שכל מפתח צריך להכיר¶
יש שני סוגים של צוותי פיתוח - כאלה שחשבו על גיבויים לפני שקרה אסון, וכאלה שחשבו על זה אחרי. אני מעדיף שתהיו בקבוצה הראשונה. גיבוי מסד נתונים נשמע כמו נושא משעמם ותפעולי, אבל זו אחת ההחלטות שהכי משפיעות על מה שקורה ביום שבו משהו משתבש - ומשהו תמיד משתבש בסוף.
למה בכלל צריך גיבוי, אם יש רפליקציה¶
זו בלבול נפוץ. רפליקציה (שכפול נתונים בזמן אמת בין כמה שרתים) מגנה עליכם מקריסת שרת בודד, אבל היא לא מגנה עליכם מטעות אנוש. אם מישהו מוחק בטעות טבלה שלמה, או מריץ עדכון שגוי שדורס נתונים, הטעות הזו משוכפלת מיידית לכל העותקים המשוכפלים. רפליקציה שומרת עליכם מתקלות חומרה, גיבוי שומר עליכם מכל השאר - כולל טעויות אנוש, קוד באגי, ותקיפות זדוניות.
שני סוגי הגיבוי הבסיסיים¶
גיבוי מלא (full backup). תמונת מצב שלמה של כל מסד הנתונים ברגע נתון. פשוט להבין ולשחזר ממנו, אבל תופס הרבה מקום אחסון וזמן להריץ, ולכן בדרך כלל לא מריצים אותו כל כמה דקות.
גיבוי אינקרמנטלי (incremental backup). גיבוי שמכיל רק את השינויים שקרו מאז הגיבוי הקודם. קטן ומהיר בהרבה, אבל שחזור ממנו דורש לשחזר קודם את הגיבוי המלא האחרון, ואז להחיל עליו את כל הגיבויים האינקרמנטליים שקרו אחריו לפי הסדר.
רוב המערכות בפועל משלבות בין השניים - גיבוי מלא פעם ביום, ואינקרמנטלי כל כמה שעות, כדי לאזן בין עלות אחסון לבין כמה מידע אתם עלולים לאבד.
מה זו נקודת השחזור, ולמה זה המספר החשוב באמת¶
הפרמטר החשוב ביותר בתכנון גיבויים נקרא RPO - Recovery Point Objective. זו בעצם השאלה - כמה מידע אתם מוכנים לאבד אם קורה אסון? אם אתם מגבים פעם ביום, ה-RPO שלכם הוא עד 24 שעות של נתונים - כל מה שקרה מאז הגיבוי האחרון ועד הרגע שהמערכת נפלה, פשוט אבד.
לצד זה יש RTO - Recovery Time Objective, כמה זמן לוקח לכם בפועל לחזור לפעילות מלאה אחרי שהחלטתם לשחזר. חברה שמעבדת תשלומים בזמן אמת צריכה RPO ו-RTO קרובים לאפס. פרויקט צד לצד קטן יכול להסתפק בגיבוי יומי ובכמה שעות שחזור.
הטעות הכי נפוצה - גיבוי שאף פעם לא נבדק¶
הטעות הזו הורסת יותר צוותים ממה שאתם חושבים. יש גיבוי, יש תהליך אוטומטי שרץ כל לילה, כולם רגועים - ועד היום שבו באמת צריך לשחזר, ומתברר שהגיבוי פגום, או שהוא לא כלל את כל הטבלאות, או שאף אחד בכלל לא יודע איך מריצים את תהליך השחזור בפועל.
הכלל הפשוט - גיבוי שאף פעם לא שוחזר בתרגול הוא לא באמת גיבוי, הוא רק תחושת ביטחון מזויפת. תרגול שחזור באופן קבוע, ולו רק פעם ברבעון, הוא ההבדל בין להירגע כשקורה תקלה לבין לגלות באמצע משבר שאין לכם דרך אמיתית לחזור אחורה.
כמה עקרונות מעשיים¶
- תשמרו את הגיבויים במיקום נפרד מהמערכת המקורית. אם הגיבוי נמצא על אותו שרת שקרס, הוא לא יעזור לכם בכלל.
- הצפינו את הגיבויים. הם מכילים בדיוק את אותו מידע רגיש שנמצא במסד הנתונים המקורי, ולכן צריכים להיות מוגנים באותה רמה.
- הגדירו מדיניות שמירה ברורה. לא כל הגיבויים צריכים להישאר לנצח - הגדירו כמה זמן שומרים כל סוג גיבוי, גם מסיבות עלות וגם מסיבות רגולציה.
איך לומדים לתכנן את זה נכון¶
תכנון גיבויים נכון הוא לא רק שאלה טכנית של "איזו פקודה מריצים" - זו שאלה של הבנת הסיכונים העסקיים האמיתיים של המערכת שלכם. בקורס צד שרת אנחנו עוברים על ניהול מסדי נתונים בפרויקט אמיתי, כולל האסטרטגיות האלה ומתי כל אחת מתאימה.
מתלבטים איזו אסטרטגיית גיבוי מתאימה למערכת שלכם? זה בדיוק סוג השאלה ששווה להעלות בדיסקורד לפני שקורה תקלה, לא אחריה.
לסיכום¶
גיבוי ושחזור זה לא נושא מרגש, אבל זה אחד הדברים שבאמת מפרידים בין מערכת אמינה למערכת שרק נראית אמינה עד היום הרע. תבינו את ההבדל בין גיבוי מלא לאינקרמנטלי, תגדירו לעצמכם כמה מידע וזמן אתם מוכנים לאבד, ובעיקר - תתרגלו שחזור בפועל לפני שהוא הופך להיות דחוף באמת.