אימות אוטומטי של גיבויים (Backup Verification)

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

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות הגילוי ושלמות העותקים

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

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

מה הופך למדיד בדוח:

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

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

שיטות בדיקת עותקים: מהרצות ידניות ועד בקרה מלאה

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

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

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

סדר ההטמעה: מספירת מלאי ועד מסירת נהלים

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

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

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

חפצים בפלט: סכימות, נהלים, יומנים ודוחות

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

מה בדיוק נשאר לצוות הלקוח ובמה אפשר להשתמש ללא מעורבותנו:

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

תרגול הטמעה: שיעור העותקים הניתנים לשחזור לפני ואחרי

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

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

כיצד נבנתה הבדיקה מחדש

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

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

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

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

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

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

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

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

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

ספקות טכניים: מגבלות, סיכונים, תאימות

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

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

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

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

כיצד להתמודד עם פארק הטרוגני: שרתים פיזיים, מכונות וירטואליות, קונטיינרים?

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

מי וכיצד מקבל גישה לנתונים שנבדקו?

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

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

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

נדון במשימה: מהיכן נתחיל ומה נבהיר

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

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

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