הגדרת גיבוי PostgreSQL: pg_dump ו-pg_dumpall

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

טעות אופיינית היא אחסון הגיבויים על אותו דיסק שבו פועל מסד הנתונים. במקרה של כשל בדיסק, תאבדו גם את מסד הנתונים וגם את הגיבוי. אנחנו תמיד ממקמים גיבויים באחסון אובייקטים נפרד, לדוגמה S3, עם מדיניות מחזור חיים מוגדרת. הניסיון שלנו מראה ש-30% מתקריות הייצור עם PostgreSQL קשורות לגיבויים לא נכונים. אנחנו מבטיחים שאחרי ההתקנה שלנו תוכלו לשחזר את מסד הנתונים תוך שעה אחת עם RPO של לא יותר מ-24 שעות.

למה pg_dump נשאר הסטנדרט לגיבוי

pg_dump הוא כלי גיבוי לוגי שאינו דורש עצירת מסד הנתונים (תיעוד pg_dump). הוא עובד על כל גרסת PostgreSQL, והגיבוי נייד בין גרסאות (בתנאי שגרסת היעד >= גרסת המקור). עבור מסדי נתונים עד 100 GB, זו הבחירה האופטימלית. היתרון המרכזי הוא הגמישות: ניתן לשחזר באופן סלקטיבי טבלאות, סכמות או נתונים.

עם זאת, ל-pg_dump יש מגבלות: גיבוי גדול יכול לקחת שעות, ואם מתרחש כשל במהלך הביצוע, הגיבוי יהיה חלקי. לכן אנחנו משתמשים בפורמט המותאם אישית (-Fc): הוא דוחס נתונים, תומך בשחזור מקבילי ומאפשר בדיקת תקינות. הפורמט המותאם אישית (-Fc) קומפקטי בערך פי 5 מ-SQL רגיל, ושחזור עם pg_restore -j 4 מאיץ פי 3-4 בשרתים עם מספר ליבות.

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

השוואת פורמטי גיבוי

הפורמט המותאם אישית (-Fc) הוא הבחירה המועדפת שלנו: דחיסה פי 5-10, pg_restore רץ במספר תהליכונים, ואפשר לשחזר רק את הטבלאות הדרושות.

תיעוד PostgreSQL

השוואת pg_dump ו-pg_dumpall

איך אנחנו מגדירים גיבוי PostgreSQL: מקרה של מסד נתונים בגודל 50 GB

קחו פרויקט אמיתי: מסד נתונים בגודל 50 GB, גיבוי מלא יומי, שמירה ל-30 יום, S3 כאחסון מרוחק. דרישה: RTO < שעה, RPO < 24 שעות. שחזור מסד נתונים בגודל 50 GB בפורמט -Fc על סביבת בדיקה עם 4 ליבות לוקח 20 דקות.

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

קוד גיבוי:

#!/bin/bash
set -euo pipefail

DB_HOST="localhost"
DB_PORT="5432"
DB_USER="postgres"
DB_NAME="production"
BACKUP_DIR="/backup/postgresql"
S3_BUCKET="s3://backups-company/postgresql"
RETENTION_DAYS=30

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_${DATE}.dump"

mkdir -p "$BACKUP_DIR"

echo "Starting backup at $(date)" | tee "$LOG_FILE"

# Создание дампа
PGPASSFILE="${HOME}/.pgpass"
pg_dump \
  -Fc \
  -h "$DB_HOST" \
  -p "$DB_PORT" \
  -U "$DB_USER" \
  -d "$DB_NAME" \
  --no-password \
  -f "$BACKUP_FILE" 2>> "$LOG_FILE"

# Проверка целостности
pg_restore --list "$BACKUP_FILE" > /dev/null 2>&1 || {
  echo "ERROR: Backup integrity check failed" | tee -a "$LOG_FILE"
  exit 1
}

# Загрузка в S3
aws s3 cp "$BACKUP_FILE" "${S3_BUCKET}/${DB_NAME}_${DATE}.dump" \
  --storage-class STANDARD_IA \
  --server-side-encryption aws:kms 2>> "$LOG_FILE"

echo "Upload to S3 completed" | tee -a "$LOG_FILE"

# Очистка локальных копий старше RETENTION_DAYS
find "$BACKUP_DIR" -name "*.dump" -mtime +${RETENTION_DAYS} -delete

echo "Backup completed successfully at $(date)" | tee -a "$LOG_FILE"

הדגל --no-password מאלץ את pg_dump לקרוא את הסיסמה מ-~/.pgpass, וזה מאובטח יותר ממשתנה סביבה. לקובץ .pgpass חייבות להיות הרשאות 600.

דוגמה לתוכן .pgpass: localhost:5432:production:postgres:yourpassword

ניטור גיל הגיבוי

כדי לתפוס את הרגע שבו הגיבויים מפסיקים להיווצר, אנחנו מוסיפים בדיקה ב-Nagios/Icinga:

#!/bin/bash
DB_NAME="production"
LAST_BACKUP_DATE=$(aws s3 ls s3://backups-company/postgresql/ \
  --recursive | grep "${DB_NAME}_" | sort | tail -1 | awk '{print $1" "$2}')
AGE_HOURS=$(( ($(date +%s) - $(date -d "$LAST_BACKUP_DATE" +%s)) / 3600 ))
if [ $AGE_HOURS -gt 25 ]; then
  echo "CRITICAL: Last backup is ${AGE_HOURS}h old"
  exit 2
elif [ $AGE_HOURS -gt 13 ]; then
  echo "WARNING: Last backup is ${AGE_HOURS}h old"
  exit 1
else
  echo "OK: Last backup is ${AGE_HOURS}h old"
  exit 0
fi

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

למה ניטור גיבויים חשוב

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

שחזור מסד נתונים מגיבוי עם pg_restore

שחזור מגיבוי מותאם אישית מתבצע בפקודה אחת:

pg_restore -j 4 -d new_db -U postgres -h localhost production_backup.dump 

הדגל -j 4 מריץ 4 תהליכונים מקבילים — זה מקצר את זמן השחזור ב-50-70% במערכות עם מספר ליבות. אם צריך לשחזר רק טבלה אחת, השתמשו ב--t table_name.

מה כלול בהתקנה מלאה

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

תהליך העבודה

1. ניתוח: הערכת גודל מסד הנתונים, דרישות RPO/RTO, אחסון זמין.
2. עיצוב: בחירת פורמט גיבוי, תוכנית אחסון (מקומי + S3), לוח זמנים.
3. יישום: כתיבת סקריפטים, הגדרת cron, אינטגרציה עם S3.
4. בדיקות: ביצוע שחזור בדיקה בסביבת staging, אימות תקינות.
5. פריסה: התקנה בייצור, הגדרת ניטור.
6. תיעוד: תיאור הליך השחזור, אנשי קשר אחראיים.

לוח זמנים ועלות

הגדרת תרחיש בסיסי (pg_dump + S3 + ניטור) אורכת בין יום ל-3 ימי עבודה, תלוי במורכבות. העלות מחושבת באופן אישי לפי היקף העבודה ודרישות היתירות. אנחנו מבטיחים שאחרי ההתקנה שלנו תוכלו לשחזר את מסד הנתונים לפי ההוראות תוך שעה אחת.

טעויות נפוצות בהגדרת גיבוי

• אחסון גיבויים על אותו דיסק כמו מסד הנתונים.
• שימוש ב-SQL רגיל ללא דחיסה (הגיבוי תופס הרבה מקום, משחזר לאט).
• חוסר אימות גיבוי.
• סיסמה בטקסט פשוט ב-cron (השתמשו ב-.pgpass).
• ללא ניטור גיל גיבוי.

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