הגנת נתונים לפי כלל 3-2-1: אוטומציה ואחריות לשחזור

הגנת נתונים לפי כלל 3-2-1: אוטומציה ואחריות שחזור

פעם, לקוח איבד 3 חודשים של נתונים עקב תקלת מערך RAID. הגיבוי נשמר על אותו שרת פיזי — שני העותקים אבדו. השחזור היה אפשרי רק מעותק בן שישה חודשים שנשמר על המחשב הנייד של המפתח. על פי סטטיסטיקות, 30% מהחברות לא בודקות גיבויים, ו-50% שומרות אותם על אותו אירוח כמו האתר הראשי. אובדן נתונים עולה לעסקים בממוצע $18k–26k. זהו מסלול ישיר להפסדים בלתי הפיכים שמסתכמים בעשרות ומאות של כ-$9–13 בחיסכון בזמן השבתה. אנחנו עוסקים בגיבויים כבר 10 שנים וטיפלנו ביותר מ-200 פרויקטים.

בניגוד לחברות רבות, אנחנו לא רק מגדירים סקריפטים — אנחנו מתכננים ארכיטקטורת גיבוי שעומדת בפני תקלות חומרה, טעויות אנוש, ואפילו התקפות ממוקדות. המהנדסים שלנו מוסמכים ב-AWS ו-PostgreSQL, מה שמבטיח הגדרה נכונה של S3 Lifecycle ו-pg_dump עם בדיקות אטומיות ועקביות.

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

למה גיבוי הוא לא אופציה אלא הכרח?

גיבוי על אותו שרת הוא ביטחון מדומה. אם RAID נכשל, שני העותקים אובדים. אנחנו מעבירים גיבויים ל-S3 ומגדירים Lifecycle — עכשיו הנתונים משוכפלים באזור אחר. עלות אחסון עבור 10 GB ב-S3 היא פחות מ-$1–1 לחודש, בעוד שאובדן נתונים יכול לעלות מיליונים. זו השקעה שמחזירה את עצמה בתקלה הראשונה. לדוגמה, עלות חודשית לאחסון 50 GB של גיבויים היא כ-$1–1. ושחזור נתונים לאחר תקלה יכול לעלות מאות של כ-$9–13 בחיסכון. החיסכון ברור. סקריפטים מותאמים אישית הם פי 10 גמישים יותר מתוספים מוכנים, במיוחד עבור מדיניות רוטציה מורכבת.

אילו נתונים אנחנו מגבים קודם

מסד הנתונים הוא מקור השינויים העיקרי. עבור WordPress עם 10k+ מבקרים יומיים, אנחנו מגדירים גיבויי DB כל 6 שעות. קבצי העלאה (uploads/, storage/) — פעם ביום. קבצי תצורה (.env, nginx.conf) — לאחר כל שינוי. הקוד נמצא ב-Git, אבל עותק גיבוי של המאגר על שרת נפרד לא יזיק.

הגדרת גיבוי אוטומטי תוך 2–4 שעות

אנחנו משתמשים ב-bash, pg_dump, rsync ו-S3. להלן תרחיש טיפוסי.

גיבוי DB אוטומטי ל-S3

#!/bin/bash
# /opt/scripts/backup-db.sh
set -euo pipefail

DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="mysite_prod"
BACKUP_DIR="/tmp/backups"
S3_BUCKET="s3://my-backups/database"

mkdir -p "$BACKUP_DIR"

# PostgreSQL
pg_dump -U postgres -d "$DB_NAME" -F custom \
  | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Upload to S3
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz" \
  "${S3_BUCKET}/${DB_NAME}_${DATE}.dump.gz" \
  --storage-class STANDARD_IA

# Clean local
rm "$BACKUP_DIR/${DB_NAME}_${DATE}.dump.gz"

# Remove old (30 days)
aws s3 ls "${S3_BUCKET}/" \
  | awk '{print $4}' \
  | while read key; do
      date=$(echo "$key" | grep -oP '\d{8}')
      if [[ $(date -d "$date" +%s) -lt $(date -d "30 days ago" +%s) ]]; then
        aws s3 rm "${S3_BUCKET}/${key}"
      fi
    done

echo "Backup completed: ${DB_NAME}_${DATE}.dump.gz"

Crontab: כל 6 שעות

0 */6 * * * /opt/scripts/backup-db.sh >> /var/log/backup.log 2>&1 

מדיניות S3 Lifecycle לרוטציה אוטומטית

{
  "Rules": [
    {
      "ID": "BackupRetention",
      "Filter": {
        "Prefix": "database/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 7,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 30,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 90
      }
    }
  ]
}

גיבוי קבצים באמצעות rsync + S3

# Syn uploads/ to S3
aws s3 sync /var/www/mysite/storage/app/public/ \
    s3://my-backups/files/ \
    --storage-class STANDARD_IA \
    --delete

# Without --delete (safer, but grows)
aws s3 sync /var/www/mysite/uploads/ s3://my-backups/uploads/

שלבי הגדרת הגיבוי

1. הערכת נפח נתונים: קביעת גודל DB, קבצים וקצב גידול.
2. בחירת אסטרטגיה: תדירות גיבוי, עומק שמירה, מחלקות אחסון S3.
3. כתיבת סקריפטים: pg_dump, rsync, aws cli.
4. הגדרת Crontab: עבור DB — כל 6 שעות, עבור קבצים — פעם ביום.
5. הגדרת S3 Lifecycle: רוטציה אוטומטית ומחיקת עותקים ישנים.
6. בדיקת שחזור: הדמיית תקלה ואימות שחזור.

נוהל בדיקת גיבוי

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

# Monthly restore test
aws s3 cp s3://my-backups/database/latest.dump.gz /tmp/test-restore.dump.gz
createdb mysite_restore_test
gunzip < /tmp/test-restore.dump.gz | pg_restore -d mysite_restore_test
psql -d mysite_restore_test -c "SELECT COUNT(*) FROM users;"
dropdb mysite_restore_test

אם השחזור מצליח — הגיבוי עובד. במקרה של שגיאה, נשלחת התראה ל-Telegram. גישה זו מבטיחה שהנתונים יהיו זמינים ברגע קריטי. אנחנו מבצעים אימות checksum ומדידת תפוקת I/O כדי להבטיח עמידה ב-WORM.

הרכב שירות הגיבוי

• פיתוח סקריפטי גיבוי (DB, קבצים, תצורות)
• הגדרת Crontab ו-S3 Lifecycle
• שחזור בדיקה בסביבה מבודדת
• ניטור עם בדיקת בריאות יומית והתראות
• תיעוד עם סכמה מלאה והוראות
• מסירת כל הסקריפטים, גישה ל-S3 bucket, ותקופת תמיכה של חודש לאחר ההשקה
• הדרכת צוות על נהלי שחזור ידניים

לפני מסירת הפרויקט, אנחנו מוודאים ש-crontab מוגדר עבור DB וקבצים, מדיניות S3 Lifecycle נוצרה, שחזור בדיקה בוצע, ניטור עם התראות הוגדר, ותיעוד נמסר ללקוח.

סקריפט מותאם אישית או תוסף מוכן: מה לבחור?

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

מדיניות שמירה מומלצת

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