אסטרטגיית גיבוי לשרתים: RPO, RTO, ובדיקת שחזורים בפועל

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

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

התחילו עם RPO ו-RTO — לא עם תוכנת גיבוי

לפני שמגדירים cron job אחד, ענו על שתי שאלות:

• RPO (Recovery Point Objective): כמה אובדן מידע מקובל עליכם? אם מסד הנתונים מגובה פעם ביום וקורה כשל ב-11 בלילה, אתם עלולים לאבד כמעט 24 שעות של נתונים. האם זה מקובל על האפליקציה שלכם?
• RTO (Recovery Time Objective): כמה זמן השירות יכול להיות מושבת בזמן שחזור? אתר e-commerce אולי יסבול 30 דקות. אינטרנט ארגוני אולי יסבול 4 שעות.

שני המספרים האלה קובעים הכל מכאן ואילך — תדירות הגיבוי, מדיניות שמירה, מיקום אחסון, ואם בכלל צריך hot standby או שחזור רגיל. הגדירו אותם עם בעלי העניין לפני שנוגעים בהגדרות.

טעות נפוצה: צוותים מגדירים גיבוי יומי כי זה ברירת המחדל, ואז מגלים שה-RPO שלהם הוא בעצם 4 שעות. לוח הזמנים לגיבוי צריך להיות תשובה מכוונת לשאלת ה-RPO — לא מחשבה שניה.

גיבויים Full, Incremental ו-Differential

הבנת סוגי הגיבוי מאפשרת לבנות לוחות זמנים יעילים בלי שעלויות האחסון יתפחו.

גיבוי Full

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

גיבויי Full רצים בדרך כלל פעם ביום בשעת תעבורה נמוכה (בדרך כלל חצות). באחסון מנוהל, הגיבוי היומי הראשון הוא תמיד Full — זאת נקודת העוגן לכל השאר.

גיבוי Incremental

גיבוי Incremental לוכד רק את מה שהשתנה מאז הגיבוי האחרון — בין אם היה Full ובין אם Incremental אחר. הוא מהיר וקטן, מה שהופך אותו לאידאלי לתזמונים בתדירות גבוהה. הפשרה: השחזור דורש להפעיל קודם את הגיבוי המלא ואז כל Incremental ברצף. יותר חלקים נעים, יותר פוטנציאל לחסר משהו.

הנה גישת גיבוי Incremental פשוטה מבוססת rsync עם hard links:

#!/bin/bash DATE=$(date +%Y-%m-%d_%H-%M) DEST="/backups/incremental/$DATE" LINK="/backups/incremental/latest" rsync -az --link-dest="$LINK" /var/www/html/ "$DEST/" rm -f "$LINK" ln -s "$DEST" "$LINK"

הדגל --link-dest אומר ל-rsync ליצור hard-link לקבצים שלא השתנו מהגיבוי הקודם, כך שקבצים זהים לא תופסים מקום אחסון נוסף בין snapshots.

גיבוי Differential

גיבוי Differential לוכד הכל שהשתנה מאז הגיבוי ה-Full האחרון. הוא גדל עם הזמן ככל שנצברים שינויים, אבל השחזור דורש רק שני חלקים: הגיבוי המלא פלוס ה-Differential האחרון. פשוט יותר מ-Incremental chains, אבל דורש יותר אחסון מ-Incremental טהור.

תזמון לפי ה-RPO שלכם

ברגע שמיפיתם את ה-RPO, תרגמו אותו ישירות ללוח זמנים. כמה תבניות מעשיות:

• RPO של 24 שעות: גיבוי Full אחד ביום. פשוט, עומס נמוך. מתאים לאפליקציות עם מעט כתיבה כמו אתרי שיווק או תיעוד.
• RPO של 6–8 שעות: Full יומי אחד + 2–3 גיבויים נוספים (Incremental או חלקי). מכסים את היום המלא בארבע חלונות בלי להכפיל עלויות אחסון.
• RPO של 1–2 שעות: שילוב של גיבויים מתוזמנים עם streaming replication ברמת מסד הנתונים או WAL archiving (עבור PostgreSQL) או binary log shipping (עבור MySQL).

לצוותים שמריצים עומסי כתיבה גבוהים — חנויות WooCommerce, אפליקציות SaaS, כל מה שיש בו טרנזקציות תכופות — שווה להגדיל את תדירות הגיבוי הרבה מעבר ל-snapshot היומי הרגיל. אנחנו מאפשרים לשרתים להריץ עד ארבעה גיבויים אוטומטיים ביום, עם גיבויים חלקיים הניתנים להגדרה (קבצים בלבד או מסד נתונים בלבד) לחלונות האמצע יום, כך שלא שומרים עותקים מלאים של assets סטטיים שלא השתנו כל שש שעות.

אחסון מחוץ לשרת — זה לא אופציונלי

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

אפשרויות מעשיות:

• Object storage (S3, Backblaze B2, Wasabi): זול, עמיד, וקל לאוטומציה. השתמשו במדיניות lifecycle להסרה אוטומטית של גיבויים ישנים.
• VPS נפרד או שרת ייעודי: שימושי כשצריך גיבויים נגישים לשחזור מהיר בלי להוריד מאחסון בענן.
• מדיה פיזית מחוץ לאתר: רלוונטי לסביבות עם דרישות compliance כבדות. בדרך כלל בשילוב עם ענן, לא במקומו.

אוטומציה של העלאה ל-S3 אחרי כל גיבוי מקומי פשוטה עם AWS CLI:

aws s3 sync /backups/daily/ s3://your-bucket/server-backups/ \ --storage-class STANDARD_IA \ --delete

STANDARD_IA (Infrequent Access) מפחית משמעותית את עלויות האחסון עבור גיבויים שמשחזרים לעתים רחוקות. הדגל --delete משקף מחיקות, כך שה-bucket ב-S3 מתאים למדיניות השמירה המקומית שלכם.

מדיניות שמירה: כמה זמן שומרים על מה

יותר שמירה לא תמיד עדיפה. שמירת 90 יום של גיבויי Full יומיים לשרת פעיל זה יקר ולרוב לא שימושי — רוב השחזורים קורים בתוך 7–14 הימים הראשונים מרגע שזוהה אירוע.

מודל שמירה מדורג עובד טוב לרוב מערכות הפרודקשן:

• גיבויים יומיים: שמירה ל-7–14 יום
• Snapshots שבועיים (אחד לשבוע): שמירה ל-4–8 שבועות
• Snapshots חודשיים: שמירה ל-6–12 חודשים (לצורכי compliance או rollback ארוך טווח)

כללי S3 lifecycle יכולים לאכוף זאת אוטומטית בלי ניקוי ידני:

aws s3api put-bucket-lifecycle-configuration \ --bucket your-bucket \ --lifecycle-configuration file://lifecycle.json

כאשר lifecycle.json מגדיר כללי מעבר ותפוגה לפי prefix. תיעוד AWS מכסה את הסכמה המלאה — שווה להשקיע שעה להגדיר זאת נכון פעם אחת במקום לשלם שנים על snapshots שנצברים.

בדיקת שחזורים: החלק שכולם מדלגים עליו

גיבוי שלא נבדק הוא השערה. אתם חושבים שהוא יעבוד. אתם לא יודעים שהוא יעבוד.

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

• שחזרו קבצים לסביבת staging מבודדת — לעולם לא לפרודקשן
• אמתו את תקינות הקבצים עם checksums אם כלי הגיבוי שלכם תומך בכך
• שחזרו את מסד הנתונים והריצו שאילתת בדיקה — ספירת שורות, timestamps של שינוי אחרון
• ודאו שהאפליקציה עולה ומשרתת בקשות כראוי מהנתונים המשוחזרים
• תעדו את הזמן שלקח מתחילת השחזור ועד מצב עבודה מאומת — זה ה-RTO בפועל שלכם

הריצו את התרגיל הזה רבעונית לכל הפחות. הריצו אותו פעם לאחר כל שינוי תשתית משמעותי. אם זמן השחזור בפועל עולה באופן עקבי על ה-RTO המטרה שלכם, זה האות להשקיע באחסון מהיר יותר, כלים טובים יותר, או סביבת warm standby.

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

גיבויי מסדי נתונים ראויים לתשומת לב מיוחדת

גיבויים ברמת מערכת הקבצים של מסד נתונים שרץ עלולים לייצר snapshots לא עקביים — אתם עלולים ללכוד כתיבה באמצע טרנזקציה. השתמשו במקום זאת בכלים ייעודיים למסד הנתונים:

עבור MySQL/MariaDB:

mysqldump --single-transaction --routines --triggers \ --all-databases | gzip > /backups/db/$(date +%Y-%m-%d_%H-%M).sql.gz

--single-transaction משתמש ב-snapshot עקבי לטבלאות InnoDB ללא נעילה. הורידו את זה ואתם מסתכנים ב-dump פגום על מסד נתונים עמוס.

עבור PostgreSQL:

pg_dumpall | gzip > /backups/db/$(date +%Y-%m-%d_%H-%M).sql.gz

למסדי נתונים גדולים שבהם mysqldump או pg_dumpall איטיים מדי, בדקו את Percona XtraBackup (MySQL) או pg_basebackup עם WAL archiving (PostgreSQL). שניהם תומכים בגיבויים hot עם השפעה מינימלית על הביצועים.

הדבר האחד שבאמת חשוב

אתם יכולים לבנות את pipeline הגיבוי המתוחכם ביותר בעולם — רפליקציה multi-region, ארכיבים מוצפנים, object storage עם גרסאות — ועדיין לאבד נתונים אם מעולם לא אימתתם שחזור מלא מקצה לקצה.

בנו את לוח הזמנים. תפעלו את העברת הגיבויים החיצוניים אוטומטית. קבעו תזכורת רבעונית ביומן לבדוק שחזור ב-staging. הצעד האחרון הזה הוא מה שמפריד בין צוותים שמתאוששים מהר לצוותים שמבלים 72 שעות בחדר מלחמה מנסים לשחזר מסד נתונים מלוגים של האפליקציה.

גיבויים הם ביטוח. בדקו אותם לפני שצריך להגיש תביעה.