הבדלים בין Snapshot לגיבוי
במקומות רבים ברשת אפשר לראות דיונים רבים בעניין שמירת קבצים, גיבויים וכו’ כשאחת המנטרות שחוזרות שוב ושוב בתגובות של אנשים היא ש-“snapshot זה לא גיבוי”. האם הטענה הזו נכונה? כן ולא. תלוי במימוש.
על מנת להדגים זאת, ניקח שני מימושים שונים שיהיו מוכרים לרוב הגולשים:
- מימוש ראשון VMWare Snapshot
- מימוש שני – AWS Snapshot
נאמר שיש לנו VM שיש בתוכו קובץ טקסט שבו כתוב “חץ קנה פיתה”. נשמור את הקובץ וניצור Snapshot. עתה, נפתח את הקובץ הנ”ל ונשנה את הטקסט כך שיהיה כתוב “חץ קנה פיתה עם פלאפל”. נשמור את הקובץ באותו שם.
עכשיו נעקוב אחר התהליך הנ”ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות “מבפנים” אם משתמשים במערכת ZFS, שהיווה “השראה” ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.
המימוש השני של snapshot לשם הדוגמא יהיה AWS EBS Snapshot: הקמנו Instance (כלומר VM) עם מערכת ההפעלה שבחרנו, ולאחר מכן ביצענו מספר שינויים בהגדרות, הוספנו אפליקציות ועוד, וכעת אנחנו יוצרים Snapshot ב-AWS. ה-Snapshot הראשון שניצור ישמור את השינויים מהקמת ה-VM עד לרגע זה. אם ניצור Snapshot נוסף, הוא ישמור את השינויים שנוצרו מאז ה-Snapshot הראשון, כלומר כל שינוי שביצענו אחר ה-Snapshot הראשון ישמר בדיסק EBS ולא ב-snapshot ורק אם ניצור snapshot נוסף, השינויים יועתקו אליו.
המימוש של AWS Snapshot מאוד דומה לגיבוי אינקרמנטלי שאפשר ליצור עם תוכנת גיבוי לטייפ או VTL – אנחנו קודם כל יוצרים גיבוי מלא, ולאחר מכן כל גיבוי אינקרמנטלי מגבה בעצם את השינויים (Delta) מאז הגיבוי המלא האחרון.
מכאן נעבור לנקודה היותר “פילוסופית” – האם snapshot יכול להחליף את מקומו של הגיבוי? זה תלוי.
במקרים כמו VMWare התשובה היא “לא ממש” הואיל ויצירת Snapshot הוא דבר שצריך לבצע “ידנית”. המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע”י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.
בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ”שלדים” (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.
ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם “להשתולל” עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו”ל משתמשים בשיטה הזו).
לסיכום: “snapshot אינו מחליף גיבוי” – זו הצהרה שאינה נכונה תמיד. יש מקרים שזו הדרך היחידה שלך לגבות (עננים ציבוריים), ויש מקרים שמימוש ה-Snapshots (כמו ב-ZFS) אינו מצריך גיבוי לקלטת כל יום. לגיבוי יש מקום חשוב ול-snapshot יש גם מקום חשוב וביטול אחד ו”הילול” הדרך השניה אינה בהכרח התשובה הנכונה.
