גיבוי 3-2-1 - איך לגבות שרתים כך שתמיד תוכלו לשחזר

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

מה זה כלל הגיבוי 3-2-1?

כלל 3-2-1 מגדיר את המינימום הדרוש כדי שגיבוי יחזיק מעמד מול תקלות אמיתיות. כל ספרה מגינה מפני סוג אחר של כשל:

• 3 עותקים - המידע המקורי ועוד שני גיבויים. עותק אחד יכול להיות פגום בדיוק ביום שצריך אותו; שניים מקטינים את הסיכון דרמטית.
• 2 סוגי אחסון - למשל דיסק השרת ומערכת אחסון אובייקטים (Object Storage), או אחסון אצל ספק אחד ואצל ספק אחר. כך תקלה במערכת אחת, בתוכנה אחת או באותה סדרת דיסקים לא פוגעת בכל העותקים.
• 1 מחוץ לאתר - עותק במרכז נתונים אחר, באזור אחר או אצל ספק אחר. הוא שמציל אתכם מאסון ברמת האתר - שריפה, הצפה, תקלה חמורה אצל הספק, או פריצה לחשבון.

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

מה זה 3-2-1-1-0 ולמה הוא נחוץ היום?

3-2-1-1-0 הוא הרחבה מודרנית של הכלל, שנולדה בעיקר בגלל מתקפות כופרה. היא מוסיפה שתי דרישות:

• 1 עותק בלתי ניתן לשינוי או מנותק - Immutable (נעילת אובייקטים לתקופה מוגדרת, כך שאי אפשר למחוק או לשנות אותם גם עם הרשאות) או Air-gapped (מנותק מהרשת ומפרטי הגישה של השרת). זה העותק שתוקף לא יכול להגיע אליו.
• 0 שגיאות - גיבויים שנבדקו בפועל, כולל שחזור, ונמצאו תקינים. גיבוי שלא נבדק הוא השערה.

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

מה ההבדל בין Snapshot לגיבוי?

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

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

מה צריך לגבות בשרת ענן?

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

• מסדי נתונים - באמצעות Dump עקבי (mysqldump עם --single-transaction, pg_dump) ולא רק העתקת קבצי ה-DB בזמן שהשירות רץ.
• קבצי האפליקציה והתוכן - למשל /var/www, תיקיות העלאות, קבצי משתמשים.
• הגדרות - /etc, הגדרות שרת ה-Web, משימות cron, קבצי סביבה (env) ותעודות SSL.
• סודות - מפתחות API וסיסמאות, מוצפנים ובנפרד, כדי שאפשר יהיה להפעיל את המערכת אחרי שחזור.
• תיעוד - גרסאות מערכת ההפעלה והתוכנות, ותהליך ההקמה. אם השרת מוגדר בקוד (Ansible, סקריפטים), הקוד הוא חלק מהגיבוי.

בשרתי Windows התמונה דומה: מסדי SQL Server בגיבוי מובנה, תיקיות משתמשים ושיתופים, והגדרות המערכת - לרוב עם כלי גיבוי ברמת המכונה כולה.

מה זה RPO ו-RTO ואיך הם קובעים את תוכנית הגיבוי?

RPO (Recovery Point Objective) הוא כמות המידע המקסימלית שהעסק מוכן לאבד, נמדדת בזמן - "מותר לאבד עד שעה של הזמנות". RTO (Recovery Time Objective) הוא הזמן המקסימלי שהמערכת יכולה להיות מושבתת - "החנות חייבת לחזור תוך 4 שעות". ה-RPO קובע את תדירות הגיבוי, וה-RTO קובע את שיטת השחזור.

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

איך נראה לוח זמנים לגיבוי שרת?

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

איך מגבים שרת לינוקס עם restic או rsync?

restic הוא כלי גיבוי חינמי שמצפין, מבצע De-duplication ותומך ביעדים רבים (SFTP, S3 ותואמי S3, ועוד) - בחירה מצוינת לשרתי לינוקס. דוגמה לסקריפט יומי:

#!/bin/bash
# /usr/local/bin/backup.sh - גיבוי יומי עם restic
set -euo pipefail
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-backups"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="..."       # מפתח ייעודי לגיבוי, לא חשבון הניהול
export AWS_SECRET_ACCESS_KEY="..."

# 1. Dump עקבי של מסד הנתונים
mysqldump --single-transaction --all-databases | gzip > /var/backups/db.sql.gz

# 2. גיבוי מוצפן ומצטבר
restic backup /etc /var/www /var/backups --exclude-caches

# 3. מדיניות שמירה
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# 4. בדיקת תקינות של חלק מהנתונים
restic check --read-data-subset=5%

מתזמנים עם cron (למשל 30 2 * * * /usr/local/bin/backup.sh), ושולחים התראה כשהסקריפט נכשל. מי שמעדיף כלי פשוט יותר יכול להעתיק עם rsync לשרת גיבוי נפרד, למשל rsync -aAX --delete /var/www/ backup@backup-host:/srv/backups/site/ - אבל שימו לב ש-rsync לבדו לא שומר גרסאות היסטוריות ולא מצפין, ולכן כדאי לשלב אותו עם Snapshots בצד היעד.

איך מגנים על הגיבויים מפני כופרה?

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

• פרטי גישה נפרדים - פרטי הגישה שעל השרת לא צריכים לאפשר מחיקת גיבויים ישנים - למשל restic rest-server במצב Append-only. את ה-prune מריצים משרת או חשבון אחר.
• Object Lock / Immutable - נעילת אובייקטים לתקופה מוגדרת ברמת האחסון.
• MFA לחשבון הענן - כדי שפריצה לסיסמה לא תאפשר מחיקת Snapshots וגיבויים.
• היסטוריה ארוכה מספיק - הדבקה מתגלה לפעמים אחרי שבועות; שמירה של 7 ימים לא תספיק.
• ניטור חריגות - קפיצה חדה בנפח הגיבוי היומי יכולה להעיד על הצפנה המונית של קבצים.

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

למה חייבים לבדוק שחזור?

כי הסיבה הנפוצה לכישלון בשחזור היא לא היעדר גיבוי - אלא גיבוי שאף אחד לא בדק. תיקייה שלא נכללה, Dump ריק בגלל הרשאה שהשתנתה, סיסמת הצפנה שאבדה, או שחזור שלוקח 20 שעות כשה-RTO הוא 4. תרגיל שחזור טוב כולל:

1. הקמת שרת זמני ושחזור מלא אליו מהגיבוי החיצוני (לא מה-Snapshot).
2. בדיקה שהאפליקציה עולה, שמסד הנתונים שלם, ושהנתונים מהיום האחרון קיימים.
3. מדידת הזמן מתחילת התהליך ועד מערכת עובדת, והשוואה ל-RTO.
4. תיעוד: מה עבד, מה חסר, מה צריך לשנות בתוכנית.
5. מחיקת השרת הזמני.

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

מהן הטעויות הנפוצות בגיבוי שרתים?

• גיבוי על אותו שרת או אותו דיסק - מגן מטעות אנוש בלבד, לא מקריסה, פריצה או כופרה.
• סנכרון במקום גיבוי - תיקייה מסונכרנת מעבירה גם מחיקות והצפנות. גיבוי אמיתי שומר גרסאות היסטוריות.
• אין התראות על כישלון - סקריפט שנכשל בשקט חודשיים רצופים מתגלה רק ביום שצריך אותו.
• שמירה קצרה מדי - שבוע אחד של היסטוריה לא מספיק כשתקלה או הדבקה מתגלות באיחור.
• סיסמת הצפנה שנמצאת רק על השרת - אם השרת אבד, גם הגיבוי אבד.
• שכחת מערכות "קטנות" - שרת ה-DNS, חומת האש, הגדרות ה-VPN או סביבת הפיתוח שמכילה את הקוד היחיד.

איך מתחילים?

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