שירותי גיבוי נתונים והתאוששות מאסון

מדוע גיבוי נתונים הוא לעיתים קרובות לא אמין?

גיבוי קיים. הריצה האחרונה — לפני שלושה שבועות. מדיניות השמירה הסירה הכל מלבד שני העותקים האחרונים, שאחד מהם לא אומת. ה-RTO בתיעוד אומר "4 שעות", אבל אף אחד לא בדק מאז שנכתב לפני שנה על תשתית שונה. זה לא תרחיש היפותטי. הזמינו ביקורת של הסכימה הנוכחית שלכם — זה לוקח שעתיים. אנחנו נתקלים כל הזמן באשליית הגנה: לקוחות מגיעים עם משימת הגדרת גיבויים, אבל במציאות הם מקבלים סכימה שאינה מתאימה לשחזור. צוות ה-DevOps שלנו מתכנן ומיישם סכימות עמידות, מגיבויי קבצים ועד Kubernetes עם Velero וסביבות היברידיות עם Veeam. עם ניסיון של 10+ שנים ולמעלה מ-50 פרויקטי DR, אנחנו יודעים היכן כשלים מתחבאים.

מדוע רוב הגיבויים אינם אמינים?

בעיה #1 — חוסר אימות. מגדירים cron עם restic backup ושוכחים מזה. שישה חודשים לאחר מכן, מתברר שה-S3 bucket נמחק, המאגר פגום, או שהסיסמה אבדה. הטעות האופיינית השנייה — שמירה לא נכונה: מדיניות של "לשמור הכל לנצח" מובילה לגלישה, בעוד "לשמור את 7 הימים האחרונים" אינה מגנה מפני תוכנת כופר שהצפינה נתונים לפני חודש. השלישית — עותקים לא עקביים. גיבוי PostgreSQL באמצעות cp ללא pg_dump נותן snapshot שאינו מתאים לשחזור. אנחנו פותרים בעיות אלה באופן מקיף: ביקורת של הסכימה הנוכחית, בחירת מחסנית טכנולוגית לתשתית הספציפית, אוטומציה עם התראות, ובדיקות שחזור קבועות.

לפי כלל 3-2-1 (ויקיפדיה), המינימום שבו כשל בודד אינו משמיד את כל העותקים הוא שלושה עותקים על שני מדיה שונים, שאחד מהם מחוץ לאתר. ביישום מודרני, זה כולל אחסון immutable כדי להגן מפני גורמים זדוניים.

בפועל, הסכימה נראית כך:

• עותק 1 — על NAS באותו מרכז נתונים (שחזור מהיר)
• עותק 2 — אחסון אובייקטים באזור אחר (S3, Backblaze B2, Wasabi) עם מדיניות שמירה
• עותק 3 — אחסון immutable עם WORM (Write Once Read Many)

כיצד להגדיר גיבוי immutable?

עותקים immutable הם נקודת מפתח בתנאים הנוכחיים. S3 Object Lock במצב Compliance מונע מחיקת אובייקטים אפילו על ידי בעל ה-bucket לתקופה מוגדרת. זו ההגנה היחידה אם תוקף משיג גישה ל-AWS credentials: הוא אינו יכול למחוק גיבויים. ללא Object Lock, תוכנת כופר מסתובבת יכולה למחוק את כל העותקים ב-S3 עם קריאת API אחת של delete-objects.

# Включение S3 Object Lock на bucket (только при создании) aws s3api create-bucket \ --bucket my-backups-immutable \ --region eu-central-1 \ --create-bucket-configuration LocationConstraint=eu-central-1 aws s3api put-object-lock-configuration \ --bucket my-backups-immutable \ --object-lock-configuration \ '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}' 

לפי התיעוד הרשמי של AWS, Object Lock במצב Compliance מונע מכל משתמש, כולל חשבון root, למחוק או לדרוס אובייקטים למשך זמן קבוע. מצב GOVERNANCE מאפשר למשתמשים עם # Включение S3 Object Lock на bucket (только при создании) aws s3api create-bucket \ --bucket my-backups-immutable \ --region eu-central-1 \ --create-bucket-configuration LocationConstraint=eu-central-1 aws s3api put-object-lock-configuration \ --bucket my-backups-immutable \ --object-lock-configuration \ '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}' לשנות מוקדם. הבחירה תלויה בדרישות הציות.

כיצד אנו מיישמים 3-2-1?

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

מקרה: מתקפת כופר — שחזור תוך 8 שעות

חברה פנתה אלינו לאחר שתוכנת כופר הצפינה את כל הייצור וה-NAS. גיבויים מקומיים הוצפנו גם הם. רק עותק immutable ב-S3 עם Object Lock, שהוגדר על ידינו חודש לפני האירוע, שרד. הסכימה כללה:

• גיבוי restic יומי של שרתים קריטיים ל-S3 עם שמירה של 30 יום
• Velero עבור Kubernetes: גיבויים של כל ה-namespaces עם pre-hook עבור PostgreSQL
• S3 Object Lock במצב Compliance למשך 14 יום (תקופה מינימלית מספקת לגילוי)

לאחר המתקפה:

1. עצרנו VMs וקלאסטרים נגועים.
2. פרסנו קלאסטר Velero חדש עם אותה StorageClass.
3. שחזרנו PVC מ-snapshots — לקח שעתיים (5 TB של נתונים).
4. הפעלנו pods, אימתנו עקביות מסד הנתונים באמצעות pg_checksum.
5. במקביל שחזרנו שרתי קבצים באמצעות restic restore למופעים חדשים.

RTO סופי — 8 שעות, RPO — שעה אחת. ללא העותק immutable, כל הנתונים מהחודש האחרון היו אובדים — ערך מוערך של $250,000 בנתונים. עלות השחזור בפועל, כולל זמן הנדסה ומשאבי ענן, הייתה כ-$50,000. בדיקות שחזור קבועות (רבעוניות) מבטיחות שה-runbook עובד. צרו קשר כדי להגדיר הגנה דומה לתשתית שלכם.

Restic ו-BorgBackup: גיבוי ברמת קבצים לשרתים

Restic מאחסן נתונים במאגר כבלוקים מנוכי כפילויות ומוצפנים. Snapshots מצטברים באמצעות ניכוי כפילויות ברמת chunk: אם 1 MB משתנה בקובץ של 10 GB, רק ה-chunk שהשתנה מועתק.

תצורת Restic אופיינית עם העלאה ל-S3:

# Инициализация, бекап, retention и проверка export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/my-backups/server1" export RESTIC_PASSWORD="$(cat /etc/restic/password)" restic init # Бекап с exclude-паттернами restic backup /var/lib/postgresql /etc /home \ --exclude="*.log" \ --exclude="/var/lib/postgresql/*/pg_wal" \ --tag "daily" --verbose # Retention: 7 ежедневных, 4 еженедельных, 12 ежемесячных restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune # Еженедельная верификация (10% блоков) restic check --read-data-subset=10% 

BorgBackup מהיר יותר מ-Restic על נפחים גדולים (Cython לעומת Go), אבל המאגר קשור למארח יחיד ואינו תומך ב-S3 באופן טבעי. עבור גיבויי NAS מקומיים, BorgBackup עם borgmatic הוא בחירה מצוינת.

Velero עבור Kubernetes: צלילה עמוקה

Velero מגבה משאבי Kubernetes דרך API + snapshots של PVC דרך CSI. התקנה דרך Helm עם backend של S3:

velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.8.0 \ --bucket velero-backups \ --secret-file ./credentials-velero \ --backup-location-config region=eu-central-1 \ --snapshot-location-config region=eu-central-1 \ --use-volume-snapshots=true 

credentials-velero — הרשאות מינימליות: s3:BypassGovernanceRetention, # Инициализация, бекап, retention и проверка export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/my-backups/server1" export RESTIC_PASSWORD="$(cat /etc/restic/password)" restic init # Бекап с exclude-паттернами restic backup /var/lib/postgresql /etc /home \ --exclude="*.log" \ --exclude="/var/lib/postgresql/*/pg_wal" \ --tag "daily" --verbose # Retention: 7 ежедневных, 4 еженедельных, 12 ежемесячных restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune # Еженедельная верификация (10% блоков) restic check --read-data-subset=10% , velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.8.0 \ --bucket velero-backups \ --secret-file ./credentials-velero \ --backup-location-config region=eu-central-1 \ --snapshot-location-config region=eu-central-1 \ --use-volume-snapshots=true , s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket.

לוח זמנים עם TTL ו-pre-hook עבור PostgreSQL:

apiVersion: velero.io/v1 kind: Schedule metadata: name: daily-production namespace: velero spec: schedule: "0 2 * * *" # каждую ночь в 2:00 template: ttl: 720h # 30 дней includedNamespaces: - production - monitoring excludedResources: - events - events.events.k8s.io hooks: resources: - name: postgres-backup-hook includedNamespaces: - production labelSelector: matchLabels: app: postgresql pre: - exec: container: postgresql command: - /bin/sh - -c - pg_dump -U postgres mydb > /tmp/pre-backup.sql timeout: 5m 

מלכודות שחזור

שחזור Velero משחזר משאבים + PVC, אבל אינו נוגע ב-StorageClass וב-CRD הקיימים. אם לקלאסטר היעד אין StorageClass סטנדרטית, השחזור ייכשל. המלכודת השנייה: ImagePullBackOff עקב רישום פרטי. אנו ממליצים לשכפל תמונות קריטיות לרישום באזור אחר.

Veeam עבור VMware וסביבות היברידיות

Veeam נשאר הסטנדרט עבור VMware vSphere. Changed Block Tracking (CBT) מאפשר גיבויים מצטברים ברמת VM ללא סוכן. עבור Windows Server, 1C, MS SQL — כמעט אין אלטרנטיבה. בסביבות היברידיות (VMware + ענן) — קונסולה אחת של Veeam Backup & Replication.

תהליך

אנו מיישמים גיבוי מקצה לקצה תוך 2–4 שבועות, תלוי במורכבות.

1. ביקורת (1–2 ימים): איסוף הסכימה הנוכחית, בדיקת שמירה, אימות, גישה.
2. תכנון (1–3 ימים): בחירת מחסנית (Restic/Velero/Veeam), הגדרת RTO/RPO, ארכיטקטורת אחסון.
3. יישום (3–10 ימים): הגדרת סוכנים, לוחות זמנים, אחסון S3/מקומי, מדיניות immutable.
4. בדיקת שחזור (2–3 ימים): ביצוע שחזור בסביבה מבודדת, תיעוד זמן בפועל.
5. תיעוד והדרכה (יום אחד): מסירת runbook, תצורות, גישה, סכימת קשר.

מה כלול

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

רשימת בדיקה לביקורת גיבויים

• כל השירותים הקריטיים כלולים בלוח הזמנים.
• מדיניות השמירה תואמת את ה-RPO.
• קיים לפחות עותק immutable אחד.
• בוצע שחזור בדיקה ב-3 החודשים האחרונים.
• גישות הגיבוי מוגנות עם MFA.
• הוגדרו התראות לשגיאות גיבוי.

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

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

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