הגדרת גיבוי בסיסי נתונים: PostgreSQL, MySQL, MongoDB

מדוע גיבוי PostgreSQL נשבר בפרודקשן

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

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

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

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

מה משתנה לאחר ההטמעה: זמני שחזור והשבתות

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

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

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

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

השוואת גישות לגיבוי: מה לבחור

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

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

שלבי ההטמעה: מסכימת הנתונים ועד מסירת הנהלים

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

1. ביקורת מסדי נתונים. מלאי של כל המופעים של PostgreSQL, MySQL ו-MongoDB: נפחים, קצב גדילה, פרופיל עומס, קריטיות הסביבה. כאן גם מתברר מה מגובה מתוך אינרציה ומה אינו מגובה כלל.
2. יעדים מדידים. עבור כל סביבה מתעדים את אובדן הנתונים המותר ואת זמן השחזור היעד — מהם תלויים התדירות של גיבויים מלאים ומצטברים ועומק ארכוב היומנים.
3. סכימת אחסון הגיבויים. היכן מאוחסנים הגיבויים, תקופת השמירה, כללי הרוטציה, הצפנה והפרדת הרשאות: לחשבון הגיבוי אסור שתהיה הרשאה למחוק פרודקשן.
4. הגדרה ואוטומציה. לוחות זמנים, גיבויים מלאים ומצטברים, ארכוב יומנים רציף, ניטור משימות עם התראות על שגיאה או החמצת הרצה.
5. שחזור בדיקה. פורסים את הגיבויים על סביבה נפרדת, מודדים את זמן השחזור בפועל ובודקים את שלמות הנתונים בנקודת זמן נבחרת, ולא את קיומו של הקובץ באחסון.
6. נוהל שחזור. סדר פעולות שלב אחר שלב, אחראים, נקודות קבלת החלטות; תרגול לפיו, כדי שהמסמך ייבחן בפועל ולא ישכב בתיעוד.
7. בחינה מחדש של הסכימה. עם גדילת הנפחים או שינוי בארכיטקטורה, לוחות הזמנים ועומק השמירה נבחנים מחדש, אחרת דרישות אובדן הנתונים מפסיקות להתקיים בשקט.

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

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

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

דוגמה מהפרקטיקה: שחזור בדקות במקום בשעות

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

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

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

מדדים אחרי: נקודת שחזור — 5 דקות במקום יממה, עלייה — 12-18 דקות לעומת 4-6 שעות, שיעור הגיבויים שנבדקו — 100%. החזרה אפשרית לכל נקודה בטווח של חודש, ולא רק ללילה האחרון. לנוהל נוספה התרעת תרגול חודשית: שחזור על סביבה בלי להודיע לצוות מראש.

מה לעשות אם מסד הנתונים כבר פועל באשכול עם רפליקציה?

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

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

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

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

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

ספקות טכניים: נפחי גיבויים, הצפנה והרשאות

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

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

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

האם הגיבויים יתפסו את כל הדיסק?

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

מי יקבל גישה לגיבויים?

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

נדון במשימה: שלחו את סכימת מסד הנתונים ואת הנוהל הקיים

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

מה לשלוח להערכה:

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

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

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