הגדרת תצלומי מצב ושחזור ב-Elasticsearch לגיבוי

Elasticsearch snapshot restore: היכן נשבר הגיבוי

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

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

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

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

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

אפקט מדיד: זמן שחזור ואובדן נתונים

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

כמה נתונים הולכים לאיבוד בין snapshots

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

שחזור מלא של האשכול לעומת שחזור סלקטיבי

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

חלון הגיבוי לא פוגע בעומס השיא

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

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

אפשרויות למאגרי snapshots ומתי הן מתאימות

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

דיסק מקומי של צומת

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

אחסון אובייקטים ושיתוף רשת

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

שלבי ההגדרה: ביקורת, תרשים, בדיקה, מסירה

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

ביקורת של תרשים הגיבוי הנוכחי

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

בדיקה באמצעות שחזור

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

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

מדיניות snapshots, משכי שמירה ותרשימי שחזור

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

תקנון תורנות וסדר שחזור

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

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

מקרה בוחן: שחזור אשכול לאחר כשל באתר

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

ברגע הכשל לא היה במה להעלות את האשכול: ה-snapshot השמיש האחרון — בן שבוע, והמאגר לא נגיש יחד עם האתר.

מה היה לפני ומה נהיה אחרי

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

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

במה שונה snapshot מרפליקה של אינדקס?

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

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

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

ספקות טכניים נפוצים לגבי snapshots ושחזור

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

איך לפרוס את מאגר ה-snapshots?

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

איך לוודא שה-snapshot תקין?

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

כמה מקום snapshots תופסים באחסון?

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

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

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

נדון במשימה: מה לברר לגבי האשכול שלכם

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

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

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

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