הגדרת גיבוי PostgreSQL באמצעות Barman

גיבוי Barman PostgreSQL: מדוע השחזור נכשל

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

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

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

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

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

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

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

אפקט מדיד של גיבוי מנוהל

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

איך לוודא שהמספרים אינם הצהרה

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

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

מצבי עבודה ומגבלות של סכימות גיבוי שונות

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

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

סדר ההטמעה: מסקר ועד מסירה לתפעול

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

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

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

תצורות, נהלים ותיעוד בסיום

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

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

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

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

לפני: דאמפ שאיש לא פרס

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

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

אחרי: גיבוי בזרימה ותרגולים סדירים

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

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

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

מה לעשות אם Barman כבר פרוס, אך הגיבויים לא נבדקו?

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

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

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

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

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

שאלות טכניות בנוגע לאחסון ולבדיקת גיבויים

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

כמה מקום יתפסו הגיבויים?

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

איך לדעת שהגיבוי באמת ישוחזר?

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

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

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

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