הנושא המשעמם ביותר בעולם: גיבויים

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

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

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

עכשיו להרחבות 🙂

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

חברות קטנות

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

תשתיות ענן

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

ב-EC2 למשל – שזו מכונה וירטואלית בענן – לא מעטים מפעילים את הגיבוי של snapshot, אבל הגיבוי של snapshot לא תמיד טוב מספיק כי הוא מגבה את ה-EBS בלבד. אם אנחנו רוצים לגבות את המכונה כולה – אז צריך להשתמש ב-AMI (כאן יש קישור למסמך הסבר רשמי של אמזון). למה זה טוב? כי גיבוי AMI מאפשר לי לייצר מכונה חדשה הרבה יותר מהר – אגב, לא רק אם המכונה הקודמת אובדת בקטסטרופה זו או אחרת אלא גם אני רוצה לייצר פתאום עוד כמה מכונות מאותו סוג.

למבדות בכלל לא מגובות ולמרבה הצער יש מקומות שאין בהם תשתיות של IaC (תשתיות כקוד – מ-CDK ועד טראפורם) והיו זוועות שראיתי מיד ראשונה כאשר למבדות נמחקו והקוד שהריץ אותן אבד לגמרי עם כל מיני תוספות שמתכנתים הכניסו.

במסדי נתונים עם Amazon RDS – יש גיבוי שמופעל אוטומטית אבל בתדירות יומית בלבד ועם שמירה של גרסאות שבעה ימים לאחור. יש מצב שגיבוי של 7 ימים זה לא תמיד מספיק (תלוי במידע ובאפליקציה).

ב-S3 Bucket למשל גם נדרש גיבוי. למשל, אם גורם מסוים חודר לתשתית שלנו ומצפין את המידע, או אם איזור מסוים הופך ללא זמין או אפילו מחיקה של הבאקט בטעות. יש לא מעט אסטרטגיות בהתאם למידע ודרכים והן לא מצריכות עבודה גדולה מדי – למשל העתקה אוטומטית של הבאקט לאיזור אחר. אם אני רוצה version policy על פריטים בבאקט, אני רק צריך לאפשר את זה.

לגבות הכל! 😱

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

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

גם כשממיינים מידע, חשוב גם לחשוב על הזמן שנדרש להשגתו מחדש. למשל – מידע פיננסי מלפני חמש שנים – לא צריך להיות זמין עכשיו ומייד ואפשר לחכות לו כמה שעות אפילו. מידע קריטי של לקוחות ממסד נתונים חי – צריך להיות ניתן לשחזור מייד. למה זה חשוב? בגלל העלויות. עלות של אחסון קר באמזון היא זולה מאד. תשוו את S3 Glacier Deep Archive לאחסון רגיל למשל. גם זה שיקול.

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

הגיבויים האישיים

ומה עם המידע האישי? פה יש כתבה ארוכה מאד בהארץ – שבה דיברתי על פתרונות שונים והיא די זהה למה שדיברנו בפרק 😇

סיכום

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