גיבוי WAL-G PostgreSQL: מה נשבר
דאמפ מלא בלילה מסתיים בקוד 0, הדוחות ירוקים, אבל אחרי פגיעה בנתונים הקלאסטר עולה מגיבוי בן יממה. את הפעולות של היממה האחרונה — הזמנות, תשלומים, עריכות בספרי העזר — צריך לאסוף ידנית ממערכות חיצוניות. הטעות בגיבוי מתגלה רק ברגע התקלה, כשאין כבר זמן לנתח אותה.
השורש הוא בפער בין הגיבויים. דאמפ לוגי מתעד את המצב ברגע הצילום, וכל מה שקרה אחריו לא נכנס אליו. שחזור בסיס הנתונים אפשרי רק לנקודת הצילום האחרונה: אין במה לבחור נקודה בין הדאמפים, והדאמפ עצמו על קלאסטר גדול נמשך שעות.
<cite>WAL-G</cite> סוגר את הפער הזה: גיבוי בסיס נעשה לעיתים רחוקות, וארכיון יומן הטרנזקציות מתמלא ברציפות. נקודת השחזור זזה מיממה לשנייה מסוימת — אפשר לחזור למצב שלפני עדכון שגוי. הגדרת WAL-G כוללת במקרה כזה מדיניות שמירה, הצפנה והעלאה לאחסון אובייקטים.
חלק נפרד של העבודה הוא בדיקה סדירה: הארכיון נפרס על סטנד נפרד, נבדקת שלמות הנתונים, נמדד זמן השחזור. בלי זה הארכיון קיים, אבל להעלות ממנו קלאסטר לא מצליחים.
בהמשך נפרט היכן התוכנית הזו נשברת לרוב ואיך נראה גיבוי PostgreSQL ששורד תקלה.
מה נותן ארכיון רציף של יומן הטרנזקציות
דאמפ מלא יומי עונה על השאלה "איך לשחזר עד הבוקר", אבל לא מכסה את שעות העבודה האחרונות. תקלה או מיגרציה כושלת באמצע היום מחזירות את בסיס הנתונים לגיבוי הלילי, וכל מה שהיה אחריו צריך לאסוף ידנית מיומני האפליקציות.
גיבוי רציף על WAL-G סוגר את החור הזה: מקטעי יומן הטרנזקציות נשלחים לאחסון אובייקטים עם התמלאותם, ולא לפי לוח זמנים.
נקודת השחזור מצטמצמת מיממה לדקות — למעשה למרווח העלאת המקטע. השחזור מתבצע בשני שלבים: פורשים את גיבוי הבסיס הקרוב, ומעליו משחזרים את היומן עד לנקודת הציון הרצויה. זה מאפשר לעצור שנייה לפני מיגרציה כושלת או מחיקה שגויה, ולא "בלילה האחרון".
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דאמפ מלא לפי לוח זמנים | בסיסי נתונים קטנים, שחזור לתחילת היממה מקובל | אובדות שעות עבודה, ההעלאה תופסת חלון ומעמיסה על השרת |
| גיבויי בסיס ברקע | נפחים גדולים עם שינויים נדירים | בין הגיבויים נדרש ארכיון יומן, אחרת אי אפשר לסגור את הפער |
| ארכיון יומן רציף | שירותים עם כתיבה מתמדת ודרישות מחמירות להגנת נתונים | נדרש אחסון אובייקטים ובדיקה סדירה של שלמות הארכיון |
זמן השחזור של בסיס הנתונים נעשה צפוי: גיבויי בסיס נעשים בתדירות נמוכה יותר וברקע, בלי חלון לילי שבו השרת עסוק בהעלאה. הגנת הנתונים מפסיקה להיות תלויה בלוח זמנים אחד — הארכיון נבדק בפריסה ניסיונית על סטנד נפרד, כך שמקטע פגום מתגלה לפני התקלה ולא במהלכה.
בסופו של דבר נעלם סוג שלם של כשלים — "אובדן שעות העבודה האחרונות", והחזרה לנקודת ביקורת הופכת לפעולה שגרתית.
מצבי ארכוב של WAL-G PostgreSQL: השוואת גישות
WAL-G מבצע שתי פעולות בלתי תלויות: מעלה ברציפות מקטעי יומן כתיבה-מראש לאחסון אובייקטים, ובאופן תקופתי מצלם תמונת מצב מלאה של בסיס הנתונים.
השחזור תמיד נשען על התמונה, והיומן רק משלים את השינויים עד לנקודה הרצויה — לכן בחירת מצב הארכוב היא בראש ובראשונה שאלה של חלון אובדן נתונים מותר ושל צפיות זמן החזרה לפעילות.
בפועל משווים ארבע תוכניות. ההבדל מתגלה לא ברגע ההגדרה, אלא ברגע התקלה, כשצריך להעלות את בסיס הנתונים בתוך חלון מוקצב.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ארכיון יומן רציף | מערכות קריטיות, נדרשת נקודת שחזור בתוך שעה | בלי תמונת בסיס אין מה לשחזר; האחסון גדל, נדרשים תקופת שמירה ורוטציה |
| תמונת מצב מלאה תקופתית של בסיס הנתונים | בסיסי נתונים קטנים, אובדן נתונים במרווח שבין התמונות מותר | אי אפשר לחזור לנקודה שרירותית; זמן השחזור גדל יחד עם הנפח |
| תוכנית היברידית: תמונת מצב יחד עם יומן רציף | האפשרות העיקרית לבסיסי נתונים בייצור עם דרישה לנקודת שחזור | דורשת בקרה על תקופת השמירה ובדיקות שחזור סדירות |
| רפליקה לקריאה כתוספת | הקלה מהעומס על בסיס הנתונים הראשי וחזרה מהירה לעבודה בעת כשל של צומת | לא מחליפה גיבוי: פעולה שגויה משוכפלת אליה |
תוכנית גיבוי היברידית מכסה את רוב המשימות: תמונת מצב לפי לוח זמנים נותנת בסיס אמין, ארכיון רציף — נקודה בתוך המרווח, ורפליקה לקריאה מסירה חלק מהעומס ומקצרת את זמן ההשבתה בעת כשל.
נדגיש בנפרד: רפליקה אינה גיבוי. מחיקה שגויה או השחתת נתונים משוכפלות בה באופן מיידי, ולכן עותק עצמאי באחסון עם ניהול גרסאות והרשאות נפרדות נשאר חובה. איזה מצב ארכוב מתאים לכם — תלוי בנקודת השחזור הנדרשת; נבחן זאת בדיון על המשימה.
הטמעה: מהאודיט של הקלאסטר ועד מסירת הנהלים
סדר העבודה בנוי כך שברגע הפעלת הארכוב בקו הייצור הצוות כבר יודע שהשחזור עובד. מתחילים באודיט: נפח הקלאסטר, עוצמת הכתיבה, רפליקות, מצב התיעוד ביומן הנוכחי. את תוכנית האחסון מתכננים לפני שינויים בתצורת הפרודקשן — אחרת ההרצה הראשונה נתקלת באחסון מלא או ביומנים שנמחקו.
-
אודיט של הקלאסטר. גרסה, טופולוגיית הרפליקות, קצב יצירת היומנים, הסקריפטים הקיימים ולוח הזמנים שלהם. התוצר — רשימת הפערים שבגללם אין כיום ארכוב רציף.
-
תוכנית אחסון. אחסון אובייקטים, פריסת גיבויי הבסיס והיומנים, שמירה וכללי מחיקה — המאגר לא גדל ללא בקרה, והחזרה לנקודה הרצויה נשארת אפשרית.
-
הגדרת הארכוב. פרמטרי היומן, הרשאות גישה, הצפנה, רוטציה. את אספקת היומנים וגיבויי הבסיס לאחסון מספק WAL-G, והוא גם בודק את שלמות הארכיונים.
-
בדיקה על סטנד נפרד. פורשים עותק מהארכיון, מודדים את זמן השחזור המלא ואת זמן החזרה לנקודה בזמן, ומשווים סכומי ביקורת.
-
אוטומציה של הבקרה. שחזור בדיקה יומי, התראות על קטיעה בשרשרת היומנים ועל עותק מיושן, דוח על עדכניות הארכיון.
-
הדרכת המשמרת התורנית. מתרגלים תרחישים: שחזור מלא, שחזור לנקודה, החזרת טבלה בודדת, התנהגות כשהאחסון אינו זמין.
-
מסירת הנהלים. תרשים, תצורות, הוראות שלב-אחר-שלב, רשימות בדיקה, מטריצת אחריות — התורן משחזר את הקלאסטר בלי להתקשר למפתח.
סט תצורות, תרשימים ונהלים בתוצר הסופי
אחרי ההטמעה נשאר אצל הלקוח לא אוסף של פקודות מפוזרות, אלא סט משוחזר: לפיו אפשר להעלות את הגיבויים מחדש על צומת חדש, לבדוק אותם בכוחות המשמרת התורנית ולהעבירם לצוות אחר בלי לפרש התכתבויות. להלן ההרכב שאנחנו מתעדים בכתב.
- קבצי הגדרות של ארכוב יומנים וגיבויי בסיס — עם הערות לכל פרמטר: עומק השמירה, לוח זמנים, רוטציה, טיפול בכשלי כתיבה למאגר.
- תרשים תשתית: היכן יושבים בסיסי הנתונים, לאן נכתבים העותקים, אילו צמתים ואזורי כשל מעורבים, היכן מתבצעת ההצפנה ואיך נשמרים המפתחות.
- מדיניות גישה: תפקידים לקריאה ולכתיבה במאגר, מי רשאי להפעיל שחזור, הפרדת תחומי אחריות וסדר מתן ושלילת הרשאות.
- נוהל גיבוי: סוגי עותקים, תדירות, תקופת שמירה, נקודות שחזור לזמן נתון ופעולות כשחסר מקום.
- יומן בדיקות שחזור: תאריך, נפח, הזמן עד לכשירות בסיס הנתונים, תוצאת השוואת סכומי הביקורת ורשימת הפערים שהתגלו.
- סדר פעולות בעת תקלה: תרחיש שלב-אחר-שלב עם נקודות קבלת החלטה, קריטריונים למעבר לעותק ותוכנית חזרה לאחור.
- הוראה למשמרת התורנית והתראות: אילו מדדי ארכוב מנוטרים, באילו ספים מופעל האות ולמי הוא מופנה.
הסט מתעדכן בכל שינוי בתצורה — אחרת התיעוד של הגיבוי מתפצל מהמציאות בתוך חודשיים. תארו את הסביבה הנוכחית, ונחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: שחזור אחרי פגיעה במערך הדיסקים
בלילה התקלקל הבקר של מערך הדיסקים, ובסיס הנתונים עבר למצב קריאה בלבד. הדאמפ הלוגי האחרון נלקח כמעט יממה לפני התקלה, ולכן לפי ההערכה אבדו כ-20 שעות של פעולות: הזמנות, סטטוסים של תשלומים, עריכות בקטלוג.
השירות היה מושבת תשע שעות בזמן שהעותק עלה מהדאמפ, ואת הפערים מול המערכות החיצוניות בררו ידנית עוד כמה ימים.
עברנו להעלאה רציפה של יומני הכתיבה-מראש לאחסון אובייקטים: תמונת בסיס יומית, ומעליה מקטעי יומן כל כמה דקות, מדיניות שמירה נפרדת ובקרת שלמות לפי סכומי ביקורת.
WAL-G מצפין את הארכיון בצד בסיס הנתונים, ממשיך את השרשרת אחרי קטיעה בתקשורת ומאפשר לשחזר מצב לנקודת זמן שרירותית, ולא לנקודת התמונה. עותקים ישנים אינם מצטברים: כלל מחזור החיים משאיר את מספר הדורות הנדרש ומנקה את השאר, ולכן הארכיון לא גדל ללא בקרה.
נקודת השחזור הצטמצמה מיממה לדקות, והעלאת בסיס הנתונים — מתשע שעות ל-25 דקות בקו נפרד. אחת לרבעון אנחנו עורכים תרגיל: מעלים עותק מהארכיון, משווים את מספר הרשומות ואת המדדים המצטברים המרכזיים, ומודדים את הזמן עד לכשירות השירות.
מקטעים פגומים ופערים אנחנו תופסים בתרגילים, ולא ברגע התקלה — שלמות הנתונים מאושרת בבדיקות, ולא בהנחות.
במה נבדל ארכיון יומן משכפול לוגי?
לעיתים מבלבלים בין רפליקה לבין גיבוי, אף שהאופק שלהן שונה. הרפליקה מיישמת ללא הרף שינויים מהצומת הראשי ושומרת על מצב לרגע הנוכחי: כמה שניות אחרי שינוי שגוי ללא תנאי יהיה בה אותו מערך נתונים פגום. היסטוריה היא לא שומרת — אי אפשר להחזיר אותה אחורה, כי פשוט אין בה עבר.
ארכיון היומן בנוי הפוך: זוהי שרשרת רציפה של שינויים שנצברה לאורך זמן. שחזור לנקודה בזמן פורש את גיבוי הבסיס ומשחזר את השינויים עד לנקודת הציון הרצויה — מצב דקה לפני התקלה, לפני עריכה כושלת של הסכמה או לפני השחתת נתונים בהעלאה.
את עומק החזרה קובעת תקופת שמירת הארכיון, ולא רגע הסנכרון האחרון, ולכן זמינות כל נקודות העבר בתוך החלון הזה.
שכפול לוגי פותר משימה שלישית — מעביר שינויים כפעולות מפורקות ומאפשר להחזיק רפליקה לקריאה. דוחות ושאילתות כבדות יורדים מהצומת הראשי בלי להפריע לכתיבה, והמעבר בעת כשל נמשך שניות. אבל רפליקה כזו מכסה רק את המצב הנוכחי, ושגיאה לוגית מתפשטת דרכה לכל הצמתים באותה מהירות.
לכן המנגנונים לא מחליפים זה את זה אלא משלימים: הרפליקה מכסה זמינות ועומס קריאה, הארכיון — שמירת הנתונים וחזרה לכל נקודה בעבר. איסוף היומן נבנה מעל אחסון אובייקטים, ו-WAL-G מוסיף לו גיבויים אינקרמנטליים ובדיקת שלמות לפני הפריסה — השחזור מפסיק להיות תלוי בכך שהצומת שרד.
ספקות טכניים: שלמות, תאימות, בדיקה
לפני המעבר לארכוב רציף מהנדסים שואלים את אותה קבוצת שאלות: מה עם התאימות, איך בודקים עותק, מי רואה את הארכיון וכמה זמן הוא חי. להלן תשובות ישירות — והן גם הופכות לסעיפי קבלה.
האם זה תואם לענף ה-PostgreSQL שלנו?
WAL-G נשען על המנגנון המובנה של יומני הכתיבה-מראש ועובד עם הענפים הנתמכים העדכניים של PostgreSQL, ולכן עדכון של גרסת מינור לא מנתק את הגיבוי. לפני המעבר אנחנו מריצים תרחיש מלא על סטנד עם התצורה שלכם.
איך לוודא שהעותק באמת ישוחזר?
עותק שלא נבדק הוא תקווה, לא ערובה. אנחנו פורשים את הארכיון על סטנד נפרד לפי לוח זמנים, משווים את שלמות הנתונים ומשחזרים מצב לנקודת זמן שרירותית. תוצאת ההשוואה האחרונה נרשמת ביומן — רואים מתי העותק באמת עלה.
האם הארכיון מוצפן ומי יש לו גישה?
ההצפנה מופעלת לפני השליחה לאחסון, המפתח חי מחוץ לדלי בענן: בלעדיו תוכן הארכיון אינו קריא גם עם גישה לאובייקטים. מפתחות אנחנו מסובבים ושומרים בנפרד מהעותקים עצמם.
כמה זמן העותקים חיים ומה קורה בקטיעת תקשורת עם האחסון?
התקופה נקבעת במדיניות השמירה: עותקים טריים נשמרים בצפיפות, ישנים מדוללים, ומשם האובייקטים נמחקים אוטומטית. בקטיעת התקשורת הארכיון לא הולך לאיבוד — היומנים נצברים מקומית ונשלחים לדלי כשהקשר מתחדש, ורק הפיגור גדל.
נדון במשימת הגיבוי ונחזור עם תוכנית
השלב הראשון הוא להבין מה כבר קיים. שלחו את גרסת השרת, את הנפח המשוער של בסיס הנתונים, את נוהל הגיבוי הנוכחי ואת הדרישות לחלון אובדן הנתונים: זה מספיק כדי להעריך את מאמץ העבודה ולהציע תוכנית עובדת. אם העותקים לא נעשים כלל או נעשים ידנית — גם זו נקודת התחלה סבירה.
ההערכה לא דורשת גישה לקו הייצור: קודם ניתוח לפי התיאור והיומנים. אם נצטרך לראות תצורות בפועל והיסטוריית עותקים, נתאם חלון והרשאות מינימליות, כדי לא לגעת בדבר במערכת החיה.
מה נכלל בעבודה:
- אודיט גיבוי: בודקים שהעותקים באמת נלקחים, נקראים ונפרסים, ולא רק תופסים מקום;
- הגדרת גיבוי על WAL-G: כתיבה רציפה של יומנים יחד עם גיבויי בסיס לאחסון אובייקטים;
- תוכנית שחזור: תרחיש שלב-אחר-שלב לנקודת זמן שרירותית עם בדיקה על עותק של בסיס הנתונים בייצור;
- מדיניות שמירה ולוח זמנים: כמה עותקים מלאים ויומנים אנחנו מחזיקים, מתי ומה מוחקים;
- ניטור עם התראות על כשלים, פיגור ביומנים ואי-התאמה בסכומי ביקורת;
- תיעוד ומסירה למשמרת התורנית: פקודות שחזור, נקודות בקרה, סדר הסלמה;
- ליווי בסיסי נתונים: בדיקות סדירות לפי לוח זמנים, שחזור בדיקה אחת לרבעון, תגובה לאירועים.
תארו את המשימה ואת המצב הנוכחי — ונחזור עם הערכה, תרשים ותוכנית עבודה בשלבים.







