הגדרת גיבוי PostgreSQL עם pgBackRest כולל הכל

הגדרת pgBackRest: היכן נשבר הגיבוי של PostgreSQL

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

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

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

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

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

שחזור לנקודה הרצויה ובדיקת שלמות העותקים

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

נקודת שחזור ולוח זמנים

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

בדיקת שלמות ושחזורי בדיקה

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

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

השוואת מצבי גיבוי ושמירה

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

מאגר מקומי וחיצוני

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

שמירה ורוטציה

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

הגדרת pgBackRest: שלבי הטמעה ומסירה

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

הכנת התשתית

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

בדיקה על סביבת בדיקה

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

חפצי הטמעה: תצורות, נהלים, תיעוד

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

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

הרכב התיעוד

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

ניטור והתראות

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

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

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

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

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

מה השתנה בתפעול היומיומי

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

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

במה שונה סטנד חם מעותק מאומת?

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

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

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

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

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

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

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

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

מה עם שמירה, רוטציה ותקופות של עותקים?

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

למי יש גישה לעותקים והאם הם מוגנים?

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

נדבר על המשימה: מה נדרש מהתשתית בהתחלה

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

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

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