הגדרת גיבויי MongoDB באמצעות mongodump עם אחריות לשחזור

למה mongodump לא מציל מאובדן נתונים ואיך לתקן את זה

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

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

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

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

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

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

מה נותן גיבוי MongoDB על פי נוהל: זמן, שלמות, צפיות מראש

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

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

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

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

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

מצבי גיבוי: mongodump, תמונת מצב של ווליום ושכפול רציף

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

איך המצבים משתלבים

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

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

איך אנחנו מיישמים נוהל גיבויים: שישה שלבים מביקורת ועד מסירה

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

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

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

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

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

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

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

סקריפטים, סכימות, מדיניות שמירה ונוהל שחזור

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

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

מקרה בוחן: איך נוהל גיבויים קיצר שחזור מיממה לשעה

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

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

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

מדדים לפני ואחרי

• זמן העלאת בסיס הנתונים: מיממה לשעה — לפי סדר מתועד, בלי לחפש את הארכיון.
• בדיקת עותקים: מאפס ל-100% — עוברת כל דאמפ, ולא באופן סלקטיבי.
• נפח המאגר: הצטמצם פי שלושה עם אופק שמירה של חודש.
• השבתת השירות באירוע: מכ-20 שעות ל-40–60 דקות.

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

במה mongodump נבדל מתמונת מצב של ווליום ומשכפול רציף

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

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

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

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

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

ספקות טכניים: שלמות, עומס ובדיקת עותקים

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

עומס בזמן הגיבוי: האם בסיס הנתונים ייפגע?

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

בסיס נתונים מחולק (sharded): האם העותק ייאסף במלואו?

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

בדיקת שחזור: איך משתכנעים שהעותק עובד?

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

אחסון עותקים: כמה להחזיק ואיפה?

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

נדון במשימה: נחזור עם אומדן ותוכנית יישום

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

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

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