הגדרת סיבוב גיבוי GFS (סבא-אבא-בן)

אנו מגדירים מדיניות סיבוב גיבוי GFS כבר למעלה מ-5 שנים. הניסיון שלנו — יותר מ-50 פרויקטים — מבטיח שלא תאבדו נתונים ותחסכו עד 70% בעלויות אחסון. מנהלים רבים עדיין משתמשים ב-crontab עם מחיקת קבצים פשוטה המבוססת על mtime — דבר שמוביל לאובדן נקודות שחזור קריטיות כאשר צריך לחזור שבועיים אחורה אך התמונות כבר לא קיימות. תכנית GFS (Grandfather-Father-Son) פותרת בעיה זו על ידי יצירת מבנה אחסון דטרמיניסטי. להלן כיצד אנו עושים זאת.

כיצד GFS פותר את בעיית איזון האחסון?

GFS מחלק את הגיבויים לשלוש שכבות: יומי (Son), שבועי (Father), וחודשי (Grandfather). זה מאפשר אחסון של שנה שלמה של היסטוריה באמצעות 24 נקודות שחזור בלבד במקום 365. חיסכון בשטח — עד 93% בהשוואה לאחסון יומי מתמשך. עבור מסדי נתונים עם דדופליקציה (Restic, Borg), הנפח בפועל קטן עוד יותר פי 10 על ידי אחסון רק בלוקים שהשתנו.

השוואה: עם אחסון יומי לשנה, מצטברים 365 גיבויים. GFS משאיר רק 24. הפחתת TCO לגיבויים מגיעה ל-70%. עבור מסד נתונים של 500 GB עם שינוי יומי של 5%, האחסון בפועל יהיה 500 × (1 + 23 × 0.05) = 1075 GB במקום 500 × 24 = 12 TB. חיסכון — יותר מ-90%. GFS טוב פי 15 מאחסון יומי פשוט מבחינת נקודות שחזור.

תכנית GFS קלאסית

סה"כ: 7 + 5 + 12 = 24 גיבויים המכסים שנה של היסטוריה. עבור ציות (פיננסים, בריאות), מתווספת שכבה שנתית עם שמירה של 5–7 שנים.

סקריפט יישום

#!/bin/bash
# /usr/local/bin/gfs-rotation.sh
set -euo pipefail

BACKUP_ROOT=/backups/databases
DATE=$(date +%Y%m%d)
DOW=$(date +%u)
DOM=$(date +%d)
DUMP_FILE="$BACKUP_ROOT/daily/mydb_${DATE}.sql.gz"

sudo -u postgres pg_dump mydb | gzip > "$DUMP_FILE"

# Son: ежедневные — хранить 7 дней
find "$BACKUP_ROOT/daily" -name "*.sql.gz" -mtime +7 -delete

# Father: еженедельный (воскресенье)
if [ "$DOW" -eq 7 ]; then
    cp "$DUMP_FILE" "$BACKUP_ROOT/weekly/mydb_week_${DATE}.sql.gz"
    find "$BACKUP_ROOT/weekly" -name "*.sql.gz" -mtime +35 -delete
fi

# Grandfather: ежемесячный (1-е число)
if [ "$DOM" -eq "01" ]; then
    cp "$DUMP_FILE" "$BACKUP_ROOT/monthly/mydb_month_${DATE}.sql.gz"
    find "$BACKUP_ROOT/monthly" -name "*.sql.gz" -mtime +366 -delete
fi

/backups/databases/
├── daily/
│   ├── mydb_YYYYMMDD.sql.gz
│   ├── mydb_YYYYMMDD.sql.gz
│   └── mydb_YYYYMMDD.sql.gz
├── weekly/
│   ├── mydb_week_YYYYMMDD.sql.gz
│   └── mydb_week_YYYYMMDD.sql.gz
└── monthly/
    └── mydb_month_YYYYMMDD.sql.gz

כלים עם תמיכה מובנית ב-GFS

רוב הכלים המודרניים (למשל, Restic) תומכים ב-GFS באופן מובנה. להלן השוואה בין פתרונות פופולריים.

Restic:

restic forget \ --keep-daily 7 \ --keep-weekly 5 \ --keep-monthly 12 \ --keep-yearly 3 \ --prune 

Veeam Backup & Replication — בהגדרות העבודה: #!/bin/bash # /usr/local/bin/gfs-rotation.sh set -euo pipefail BACKUP_ROOT=/backups/databases DATE=$(date +%Y%m%d) DOW=$(date +%u) DOM=$(date +%d) DUMP_FILE="$BACKUP_ROOT/daily/mydb_${DATE}.sql.gz" sudo -u postgres pg_dump mydb | gzip > "$DUMP_FILE" # Son: ежедневные — хранить 7 дней find "$BACKUP_ROOT/daily" -name "*.sql.gz" -mtime +7 -delete # Father: еженедельный (воскресенье) if [ "$DOW" -eq 7 ]; then cp "$DUMP_FILE" "$BACKUP_ROOT/weekly/mydb_week_${DATE}.sql.gz" find "$BACKUP_ROOT/weekly" -name "*.sql.gz" -mtime +35 -delete fi # Grandfather: ежемесячный (1-е число) if [ "$DOM" -eq "01" ]; then cp "$DUMP_FILE" "$BACKUP_ROOT/monthly/mydb_month_${DATE}.sql.gz" find "$BACKUP_ROOT/monthly" -name "*.sql.gz" -mtime +366 -delete fi , תיבות סימון שבועי/חודשי/שנתי.

BorgBackup/Borgmatic ב-/backups/databases/ ├── daily/ │ ├── mydb_YYYYMMDD.sql.gz │ ├── mydb_YYYYMMDD.sql.gz │ └── mydb_YYYYMMDD.sql.gz ├── weekly/ │ ├── mydb_week_YYYYMMDD.sql.gz │ └── mydb_week_YYYYMMDD.sql.gz └── monthly/ └── mydb_month_YYYYMMDD.sql.gz :

retention: keep_daily: 7 keep_weekly: 5 keep_monthly: 12 keep_yearly: 3 

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

תהליך הגדרת GFS

אנו פועלים לפי תכנית זו:

1. ביקורת נתונים והערכת RPO. אנו מעריכים נפחים, תדירות שינויים, ודרישות נקודות שחזור.
2. בחירת כלי. Restic עבור Linux, Veeam עבור Windows, Borg עבור אשכולות גדולים.
3. הגדרת מדיניות. הגדרת תקופות שמירה לכל שכבה, תוך התחשבות בדרישות ציות.
4. בדיקות. אימות שחזור מגיבויים בכל שכבה.
5. ניטור. הגדרת התראות ב-Prometheus/Grafana בעת הפרת טריות.

יתרונות יישום GFS

בהשוואה לאחסון יומי פשוט, GFS מפחית את מספר הגיבויים מ-365 ל-24 — פי 15 פחות. עבור עסקים, זה אומר הפחתת TCO של עד 70% על גיבויים. אנו מבטיחים שלאחר ההגדרה, הסיבוב יפעל אוטומטית, ותקבלו תיעוד וסקריפטים לניטור. הזמינו הגדרה — קבלו ייעוץ ותקופת ניסיון.

מה כלול

• ניתוח תשתית הגיבוי הקיימת
• בחירת כלי אופטימלי (Restic, Borg, Veeam, סקריפטים)
• הגדרת מדיניות GFS תוך התחשבות ב-RPO/RTO
• סקריפטים לאימות והתראות
• תיעוד הליך שחזור
• הדרכת צוות זמין
• מהנדסים מוסמכים (AWS, HashiCorp)

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

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

כיצד לוודא טריות גיבוי?

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

check_freshness /backups/daily 25 "Daily"
check_freshness /backups/weekly 169 "Weekly"
check_freshness /backups/monthly 745 "Monthly"

הרצה דרך cron עם מדדים שנשלחים ל-Prometheus. אנו כוללים בדיקות כאלה במדיניות.