הגדרת PITR PostgreSQL: שחזור לנקודת זמן

PostgreSQL PITR: איפה אובדים נתונים בין הגיבויים

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

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

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

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

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

ארכוב רציף של היומן: מה משתנה בפועל

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

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

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

איזה סוג של כשל נסגר

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

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

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

גיבוי מלא, יומן טרנזקציות או רפליקציה: השוואה

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

מתי די בגיבוי מלא

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

מתי נדרשת סכימה משולבת

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

סדר ההטמעה של שחזור לנקודת זמן

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

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

בדיקה על סביבה נפרדת

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

מסירת התפעול והנוהל

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

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

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

הגדרות הארכוב ותקופות השמירה

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

תיעוד ותדריך לתורן

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

מקרה בוחן: שחזור אחרי מחיקה המונית של נתונים

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

כיצד היה לפני

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

מה השתנה אחרי

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

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

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

במה PostgreSQL PITR שונה מרפליקציה ומתמונות דיסק

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

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

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

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

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

מגבלות וכשלים נפוצים בשחזור לנקודת זמן

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

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

כיצד לוודא שהגיבוי כשיר לשחזור?

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

השחזור יפגע בסביבת הייצור? אפשר להרים טבלה אחת?

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

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

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

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

מה נדרש מכם:

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

מה נחזיר בשלב הראשון:

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

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