אסטרטגיות גיבוי ושכפול

תקציר

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

מונחים ויעדים

RPO - כמה נתונים ניתן לאבד (לדוגמה, 5 דקות).
RTO - כמה זמן מותר לשחזר (למשל, 15 דקות).
התאוששות ”רגע X” עם רישום חוזר.
Data SLO הוא חוזה רמת שירות עבור RPO/RTO והצלחת משימות גיבוי.

דוגמא למטריקס:

שיעור נתונים	RPO	RTO	הערות
עסקאות/ארנק	לוקה 1-5 דקות	מנה 5-15 דקות	יומנים + העתק ליבה סינכרוני
דיווח/PII	”שעת 1”	”שעת 1”	תולעת/חוסר תזוזה, ארכיונים
יומנים/אירועים גולמיים	פינת 24 ח '	land4 h	אובייקט, אופני חיים

פגמת סובלנות ומודלים שכפול

אפשרויות טופולוגיה

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

סינכרוני נגד אסינכרוני

סינכרוני: RPO venture 0, מעל latency, גבול המרחק.
אסינכרון: קרוב לאפס RTO ב RPO נמוך (דקות), עומד אזורים/עננים.
היברידי: סינכרוני בתוך אזור, אסינכרוני לאזור מרוחק.

העתק גיבוי

ההעתק נושא שגיאות/מחיקות לאחר המקור. גיבוי - העתק מחוץ לנתיב עם ורסינציה, בדיקות ובידוד.

מדיניות 3-2-1-1-0 וחוסר תזוזה

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

תרגול:

אפשר מנעול אובייקטים (Complication/Government) עבור אובייקטים בעלי גיבויים קריטיים.
עבור NAS/blocks - תמונות בלתי ניתנות לשינוי עם שימור ואיסור על מחיקה עד המועד האחרון.

סוגים של גיבויים ולוחות זמנים

עותק מלא.
שינויים מצטברים - רק מהגיבוי הקודם.
שינויים - שינויים מאז השלמת האחרון.
עם GFS-תוכנית (General-Father-Son): עליות יומיות, שבועיות וחודשיות של ”מלא סינתטי”.

המלצה (דוגמה):

Prod DB: מלא יומי (או מלא סינתטי), מרווחים/רישומים כל 5-15 דקות (PITR).
שרתי קבצים: שבוע מלא, יום מצטבר, ארכיון חודשי.
אובייקט: אופן חיים + גרסאות; קר לאחסון ארכיון שיעור/קלטת.

יישומים ומסדי נתונים: פרקטיקות PITR

PostgreSQL

אפשר גיבוי ארכיון ובסיס של WAL; PITR באמצעות ”recover _ command”.
כלים: 'Backrest',' wal-g '(אובייקט),' pg _ basebackup 'להשלמה.
כרכים מפוצלים: נתונים ו ־ WAL; כתוב WAL על NVME מהיר עם PLP.

MySQL/MaraterDB

רישום בינארי עבור PITR, הושלם באמצעות 'Percona XtraBackup' (גיבוי חם).
שכפול GTID; לד "ר אסינכרוני לאזור/ענן.

MongoDB

Oplog for PITR; צילומים של סטורז '+ רמת ”מונגדאפ” לעותקים לוגיים.
בדוק את עקביות ההעתק לפני הגיבוי.

רדיס/Caches

לא נחשב כגיבוי: שמור על RDB/AOF + מחוץ לאתר; לשחזר כמטמון חם או ממקור של אמת.

קוברנטס ומכולות

אשכול etcd - מטרה קריטית נפרדת (תצלומים תכופים, מחוץ לאתר).
Velero: רשימת גיבוי/משאבים + תצלומי CSI/PV; אחסון בדלי S3-compatible (עם נעילת אובייקט).
הורדות סטטוטוריות: תמונות עקביות אפליקציה (טרום/פוסט ווקס), אחרת - התרסקות עקבית.
ורסינציה של חפצי עצם (מודלים/מדיה) ברמה של דליים.

וירטואליזציה ושרתי קבצים

תצלומי VM: השתמש ב-CBT (Stranged Block Tracking), לאחסן מחוץ לאתר, באופן תקופתי לעשות quiesce (VSS עבור חלונות).
שרתי קבצים (NAS): תמונות + העתק ומבחנים רגילים לשחזור הקטלוג (דגימת קבצים).

ביטחון גיבוי

הצפנה במנוחה (LUKS/ZFS/Cloud KMS/Vault) ובמהלך שידור (TLS/mTLS).
ניהול מפתח: תפקידים אישיים, שליטה כפולה, סיבוב, אחסון לא מקוון של מפתחות מאסטר.
בידוד: חשבונות תוכנת גיבוי ללא זכויות למחוק עותקים בלתי ניתנים לשינוי; רשתות בודדות/קורות חיים.
Ransomware-resistance: ללא שינוי, פער אוויר (קלטות/חשבון/מעבדה מבודדת).
ביקורת: רישום פעולות מערכת גיבוי, הודעות על מחיקה/הפחתה של השמירה.

תכנון חלון ורוחב פס

חלון גיבוי נגד טעינה: מצערת אל/או/רשתות, שכפול, דחיסה.
רשת: כל N דקות, ערוצים נפרדים/VPN, העתק בלילה או באופן קבוע עם QOS.
שינוי בלוק מעקב/CDC כדי להפחית את התנועה.
בסיסים גדולים: זרמים/זרימה מקבילים, רב ערוצים רב-ערכיים לאובייקט.

ניטור, Metrics ו ־ SLO

מדדים טכניים:

הצלחה של משימות גיבוי/שכפול (%), משך, מהירות, רישום לאג (WAL/binlog/oplog).
שטח אחסון גיבוי, מקדם דידאפ, הוצאות אחרות.
זמן והצלחה של שיקום מבחנים.

SLO (דוגמה):

ההצלחה של גיבויים 99. 9 %/30 ימים.
RPO פגשה 99% מהזמן (log lag lard target).
(RTO (test-recover 15 min לארנק, דוח 1 h לדיווח.
מקדחה חודשית: 100% מהתרחישים השגרתיים הושלמו.

התראות:

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

תרגילי DR ובדיקות התאוששות

שולחן עליון: תיאום תפקידים, אנשי קשר, תקשורת.
טכני: התאוששות ארגז חול, מדידת RTO, השוואת checksum/data.
התחלה שחורה: ברזל חשוף מלא/התאוששות אשכול נקייה.
קטלוגים של נתונים: שלבי שחזור מתוארים מראש (ספרי ריצה) עבור כל כיתת מערכת.
אוטומציה: ”קנרית” תקופתית לשחזור ואימות של בדיקות.

תבניות מעשיות

1) ארכיון PostGreSQL (Backrest + WAL לארכיון אובייקט)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (דוגמה ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - אובייקט + אי ־ תזוזה של הדלי)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) מדיניות נעילת אובייקט (דוגמה 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) דוגמה ללוח הזמנים של GFS (מושג)

מדי יום: כל 15 דקות (כתבי עת), מלאות באופן סינתטי יומי.

שבועי: אחד ”מלא” (סינתטי), חנות במשך 8 שבועות

חודש: מלא, לאחסן 12-24 חודשים (ארכיון/קלטת).

רשימת יישומים

[ ] כיתות מידע מוגדרות, בעלים, RPO/RTO/SLO.

[ שכפול ] (sync/async) וטופולוגיה (AZ/Region/Cloud) נבחרו.

[ ] גיבויים מוגדרים: מלא/אינקרמנטלי/PITR, לוחות זמנים, ספריות.

[ ] כולל אימפולסיביות (תולעת/נעילת אובייקט/תמונות בלתי ניתנות לשינוי) ופער מחוץ לאתר/אוויר.

[ ] הצפנה ו KMS/Vault, תפקידים נפרדים וסיבובי מפתח.

[ ניטור ]: הצלחה במשימה, רישום פיגור, מקום, שחזור בדיקה; התראות.

[ ] Runbooks התאוששות ופילובר; אנשי קשר, הסלמה, תבניות תקשורת.

[ ] חודשית של ד ”ר תרגילים + דו” ח, התאמת תוכניות.

[ תקציב ] ו-FinOps: עלות אחסון/יציאה, ארכיון/קריעה פרויקט.

שגיאות נפוצות

”יש העתק - אין צורך בגיבוי”: מחיקות לוגיות ותוכנות כופר יעזבו עבור ההעתק.
אין בדיקות התאוששות - גיבוי קיים ”תיאורטית”.
העדר אי-מידתיות וחוסר-מידתיות היא נקודת סיכון אחת.
אותו חשבון/מפתחות למכירות וגיבויים - פשרה = אובדן של הכל.
חלונות גיבוי ארוכים מדי מסוכסכים עם פסגות; בלי חנק וקיו-או-אס.
PITR ללא בקרת רישום לג.
התעלם מתמונות עקביות אפליקציה - כרכים גמילה מלוכלכים.

iGaming/fintech ספציפי

ארנק/ליבת תשלום: RPO 1-5 דקות, RTO 15 דקות; רישום (WAL/binlog) לעצם עם תולעת; סינכרוני באזור + אסינכרוני.
דיווח/רגולציה: מחסומים בלתי ניתנים לשינוי, שימור ארוך (שנים), שלמות ניתנת לאימות, נהלים ברורים להנפקת נתונים לרגולטורים.
יומנים/אירועים גולמיים/אנטי הונאה: אחסון זול וארוך חיים (אובייקט) + אופן חיים; אינדסים וחנויות - בנפרד.
פסגות (גפרורים/טורנירים): חלונות גיבוי מחוץ לפסגות, מצערת; DR-תוכניות לתקופת האירוע; קנרית משחזרת לפני מניות.

סך הכל

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