Velero: גיבוי ושחזור עבור Kubernetes — מדריך מלא

גיבוי Velero Kubernetes: היכן נשבר השחזור

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

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

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

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

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

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

מה נותן גיבוי מנוהל של האשכול

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

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

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

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

Velero, snapshots ו-replication: מתי מה מתאים

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

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

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

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

שלבי ההטמעה: מביקורת אחסון ועד מסירה

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

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

מה נשאר לצוות שלכם לאחר ההטמעה

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

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

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

מקרה בוחן: שחזור בדקות במקום יממה

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

מה שינו

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

מה השתנה במספרים

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

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

מה לעשות אם האשכול כבר פרוס ומחולק

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

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

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

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

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

ספקות טכניים ומגבלות הגישה

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

האם סביבת הייצור תיחלש בזמן הגיבוי?

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

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

מי אחראי אם השחזור לא יעבוד?

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

היכן הגישה מפסיקה לעבוד?

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

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

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

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

בהמשך אנו מרכיבים תוכנית הטמעה:

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

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