GH GambleHub

גיבויים והתאוששות אסון

גיבויים והתאוששות אסון

1) הגדרות ומטרות

גיבוי - עותק עקבי של נתונים/תצורות להתאוששות לאחר מכן (ממחיקות מקריות, באגים, מפענחי הצפנה, אסונות).
ד "ר (התאוששות אסון) - התהליך של השבת תשתיות/שירותים לעבודה ב-SLOS לאחר תאונה קשה (שריפה, אובדן אזור, פשרה מסיבית).
RPO (Recovery Point Objective) - איבוד נתונים מוקצן בזמן (לדוגמה, 15 דקות).
RTO (Recovery Time Objective) - יעד התאוששות בזמן שירות (לדוגמה, 30 דקות).

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

2) סיווג נתונים ורמות ביקורת

לחלק נכסים לשיעורים:
  • Tier-0 (חיוני): מסדי נתונים עסקיים, תשלומים, חשבון מאזן גיליון, סודות/PKI.
  • Tier-1 (קריטי): תצורות שירות, תורים, חפצי CI/CD, רישומי מכולות.
  • Tier-2 (חשוב): אנליטיקה, דוחות, אינדקסים משניים, ארכיון יומן.
  • Tier-3 (מסייע): מטמונים, נתוני זמן (ניתן לשחזר).

עבור כל מחלקה, הגדר את RPO/RTO, תקופת השמירה, דרישות אי-יכולת ומיקום.

3) אסטרטגיות שימור: כלל 3-2-1-1-0

3 עותקים של נתונים (prod + 2 גיבויים).
2 סוגי מדיה/אחסון שונים.
1 offsite העתק (אזור/ענן שונה).
1 ללא שינוי/פער אוויר (תולעת/נעילת אובייקט/טייפ).
0 טעויות בבדיקות התאוששות (בדיקות רגילות).

4) סוגי גיבויים

זכיון מלא. איטי/יקר אבל בסיס לכל האסטרטגיות.
ההבדל עם הגיבוי האחרון. אופטימלי בנפח.
הבדל - ההבדל עם האחרון מלא. התאוששות מהירה יותר, יותר מקום.
Snapshot - צילום של נפח/דיסק (EBS/ZFS/LVM). אנחנו צריכים תצלומי אפליקציה עקביים (quiesce).
(PITR (Point-in-Time Recovery - גיבוי בסיסי + logs (WAL/binlog עבור rollback כדי לדייק זמן/LSN.
אובייקט/קובץ/פיגורטיבי - עבור סוגי נתונים ספציפיים (תמונות VM, אובייקטים S3, DB ducps).

5) עקביות הגיבויים

קראש-עקבי: כמו אחרי כיבוי פתאומי - מתאים לחסר מעמד/כתב עת FS.
אפליקציה עקבית: היישום ”מקפיא” פעולות (fsfreeze/pree-post scripts).
עקביות בסיס הנתונים: API של כלי הגיבוי (BackCrest, XtraBackup), מצבי גיבוי חמים, נקודות ביקורת מקפיאות.

6) הצפנה, מפתחות וגישה

בזמן מנוחה והצפנת מעבר לכל העותקים.
מפתחות ב ־ KMS/HSM, סיבוב לפי מדיניות (90/180 ימים), מפתחות נפרדים לפי סביבה.
הפרדת חובות: מי יוצר/מסיר גיבויים למי שיכול לפענח/לקרוא אותם.
אל תשמור מפתחות פענוח באותו תחום אמון כמו העתקי המטרה.

7) עותקים בלתי ניתנים לשינוי והגנה על תוכנות כופר

Object Lock/WORM (ציות/ממשל) עם שימור והחזקה משפטית.
פער אוויר: אחסון מבודד/לא מקוון (הזנה, ענן/חשבון לא מקוון).
”הפעלה מעכבת” מדיניות מחיקה, MFA-Delete, חשבון נפרד לגיבוי דליים, איסור על גישה ציבורית.
אימות לתוכנות זדוניות/אינדיקטורים של פשרה לפני ההרכבה.

8) תדירות, לוח זמנים ושימור

GFS (סבא-אבא-בן): עליות יומיות, מלאות/דיף שבועיות, מלאות מדי חודש עם אחסון ארוך.
RPO מכתיב את תדירות השינויים ואת הארכיון של WAL/binlog (לדוגמה, כל 5-15 דקות).
אחסון: חיוני - 35-90 ימים + חודשיים במשך 12-36 חודשים (דרישות חוקיות).
פסגות עונתיות הן נקודות שליטה נפרדות (לפני קידום/שחרור).

9) מודלים ותרחישים של ד "ר

פעיל-פעיל: שני האזורים מגישים תנועה. מינימום RTO, קריסת נתונים דורשת מדיניות קונפליקט קפדנית.
אקטיבי-פסיבי (חם/חם): חם - לא מקושר ומסונכרן (דקות RTO), חם - מוכן חלקית (שעות RTO).
קר: לאחסן עותקים ו ־ Terraform/Ansible/images, להעלות לפי דרישה (RTO day +).
DRAS: תזמור ספק של VMs/רשתות/כתובות באזור אחר.

10) תזמור פיילובר וסדרי עדיפויות לשיקום

עדיפות התחלה: רשת/VPN/DNS * סודות/KMS # מסדי נתונים/אשכולות * תורים/מטמון * יישומים * היקפיים/CDN * אנליטיים.
אוטומציה: סקריפטים/פעולות ריצה, Terraform/Ansible/Helm/ArgoCD עבור סביבת DR.
Data: DB PITR * reindex/reception lach pache ache * משיק שירותים עם דגלי תאימות.
DNS/GSLB: TTL הורד את הדירוג מראש, החלף תרחישים עם אימות.

11) בדיקות אימות גיבוי

שחזר בדיקות בלוח זמנים: דגימה של N% מהגיבויים, פריסת ארגז חול, סכימה אוטומטית/בדיקות אינווריאנטיות.
DR-תרגיל מלא (יום משחק): ביטול אזור/AZ, בדיקת RTO/RPO על תנועה חיה (או צללי תנועה).
מבחני יושרה: ספריות חשיש, צ 'קים, מנסים לקרוא את כל השכבות (שרשרת מלאה +).
דו "ח מסמכים: זמן, צעדים, חריגות, גודל פער ממטרות, תיקונים.

12) תרגול טכנולוגיות ליבה

מסדי נתונים

PostGreSQL: גיבוי בסיס + ארכיון WAL (PITR), כלים Firgrest/Barman; חריצי שכפול, ניטור 'in' sin.
MySQL/MarateDB: Percona XtraBackup/Enterprise Backup, binlog archiving.
MongOdB: 'mongodump' עבור העתק לוגי + צילום עבור סטים גדולים; Oplog עבור PITR.
רדיס: RDB/AOF עבור קריטי (אם Redis הוא לא רק מטמון), אלא לעיתים קרובות יותר - שחזור לוגי מתוך המקור + תצלום עבור תאונות.
קפקא/פולסר: גיבוי metadata (ZK/Kraft/Bookeeper), תצלומי דיסק, שיקוף נושא/רישום.

Kubernetes

תצלום etcd + Velero עבור משאבים/כרכים (תצלומי CSI).
סודות גיבוי/PKI בנפרד (תצלום כספת).
רשימה נפרדת של תמונות: תגיות בלתי ניתנות לשינוי.

VMS ומערכות קבצים

ZFS: ”zfs snapshot” + ”zfs' send | zstd | sund-recv”, בדיקת ”scrub”.
תמונות LVM/EBS עם תסריטי פרה/פוסט (אפליקציה עקבית).
חנויות אובייקטים - גרסאות + נעילת אובייקטים.

13) קטלוג ושליטה בגרסה של גיבויים

ספרייה (קטלוג metadata): מה, איפה, מתי, מתי, מאשר לעשות, חשיש, מפתח KMS, בעלים, תקופת שימור.
nv = prod' stage ',' מערכת '= db' 8s 'vm', 'tier=0|1|2', 'retention=35d|1y'.
נקודות ביקורת זהב: לפני נדידה/DDL/שחרור בקנה מידה גדול.

14) יכולת תצפית ומדדים

אחוזי הצלחה בעבודה:% הצלחה/כישלון, סיבות.
גיבוי/שחזור זמן, רוחב חלון.
רישום ארכיון (WAL/binlog) p95.
שלמות: פרופורציה של שרשראות שנבדקו, טעויות פיוס חשיש.
עלות: יכולת אחסון לפי רמה, יחס שכפול/דחיסה.
DR-מוכנות: תדירות ותוצאה של תרגילים (pass/fass).

15) מדיניות גישה וציות

חשבונות/פרויקטים נפרדים לאחסון גיבוי; גישה לפי עקרון ה-NAC (איננו מאפשרים מחיקה/הצפנה מחשבונות הייצור).
לוגים של גישה/שינויים (שביל ביקורת), התראות למחיקות/שינויים המוניים של retshn.
ציות: GDPR (נכון למחיקת vs. archives), PCI DSS (הצפנה, מפתחות, קטגמנטציה), רגולטורים מקומיים.

16) אנטי דפוסים

”יש העתק, מה שאומר שאתה לא צריך גיבוי”.
אין פער בלתי ניתן לשינוי: שגיאה/תוכנה זדונית אחת מוחקת הכל.
גיבויים באותו חשבון/אזור כפרוד.
לעולם אל תבדוק התאוששות (גיבוי ”מת לפני הבדיקה”).
אין קיטלוג ושליטה בגרסה. כאוס בתאונה.
מפתחות הצפנה משותפים לכל הסביבה.
תמונות ללא מצב עקבי אפליקציה עבור מסד נתונים.
חלון הגיבוי מצטלב עם פסגות (משפיע על p99 ו-SLO).

17) רשימת מימושים (0-60 יום)

0-10 ימים

מלאי של מערכות/נתונים, שיעורי ביקורת.
הגדר מטרות RPO/RTO לפי רמה.
אפשר אינקרמנטלית מלאה עבור Tier-0/1, ארכיון WAL/binlog.
פוסט גיבויים: הפרד אזור/חשבון + אפשר הצפנת KMS.

11-30 ימים

הגדרות בלתי ניתנות לשינוי (Object Lock/WORM) עבור עותקים קריטיים.
הזן קטלוג, תגיות, דיווח; התראות לכישלונות ומגזינים.
ראשית ד "ר מקדחה: לשחזר שירות נפרד מגיבוי בסביבה מבודדת.

31-60 ימים

ספר הזמנות אוטומטי: Terraform/Ansible/HELM profiles DR

בדיקות שחזור רגילות (שבוע/חודש) + תרחיש רבעוני מלא DR.
ייעול עלויות שכפול/דחיסה/אחסון חיים.

18) מדדי בגרות

שחזור מבחנים: 1/שבוע עבור Tier-0 (סלקטיבי), 1/חודש - תרחיש מלא.
כיסוי בלתי ניתן לשינוי Tier-0/1 = 100%.
יעד RPO-בפועל P95 (לדוגמה: 15 דקות).
RTO-בפועל על DR-תרגילי יעד (למשל 30 minin).
ספרייה שלמה = 100% (כל גיבוי מתואר ונבדק).
תקרית לשחזור זמן מהגילוי לתחילת ההתאוששות.

19) דוגמאות (קטעים)

מדיניות PostGreSQL - PITR (רעיון):
bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"
MySQL - לולאה מצטברת:
bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02
קוברנטס - ולרו (רעיונות מניפסט):
yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable
נעילת אובייקטים S3 (מדיניות אופן חיים לדוגמה):
json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) אמצעי תקשורת ותפקידים מבצעיים

מפקד אירוע, תקשורת עופרת, Ops Lead, DB להוביל, אבטחה.
תבניות הודעה לבעלי עניין/רגולטורים/משתמשים.
לאחר המוות עם פעולות: איפה הם איבדו דקות, איפה לשפר אוטומציה.

21) מסקנה

לולאה אמינה של גיבויים ו-DR היא לא ”הכן עותק”, אלא מחזור: סיווג ”מטרות” RPO/RTO = עותקים רב-רמות ובלתי ניתנים לשינוי. דבוק ל-3-2-1-1-0, שכפול נפרד מגיבויים, הצפן ובודד מפתחות, מסמך ואימות. ואז אפילו ”הברבור השחור” יהפוך לתהליך בר-שליטה עם השבתה צפויה ואובדן מידע מינימלי.

Contact

צרו קשר

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

התחלת אינטגרציה

Email הוא חובה. Telegram או WhatsApp — אופציונליים.

השם שלכם לא חובה
Email לא חובה
נושא לא חובה
הודעה לא חובה
Telegram לא חובה
@
אם תציינו Telegram — נענה גם שם, בנוסף ל-Email.
WhatsApp לא חובה
פורמט: קידומת מדינה ומספר (לדוגמה, +972XXXXXXXXX).

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