גיבוי מוכן: ביטול מיתוסים לכבוד החג

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

אני עובד על הנושא הזה כבר כמעט 20 שנה, מהן השנתיים האחרונות ב-Promsvyazbank. ממש בתחילת התרגול, עשיתי גיבויים כמעט באופן ידני, עם סקריפטים שפשוט העתיקו קבצים. אז הופיעו כלים נוחים ב-Windows: כלי השירות Robocopy להכנת קבצים ו-NT Backup להעתקה. ורק אז הגיע הזמן לתוכנה מיוחדת, בעיקר Veritas Backup Exec, שנקראת כיום Symantec Backup Exec. אז אני מכיר את הגיבויים כבר הרבה זמן.

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

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

ישנם כמה מיתוסים אופייניים סביב גיבוי שצריך להפריך מזמן. הנה המפורסמים שבהם.

מיתוס 1. גיבוי הוא מזמן רק פונקציה קטנה בתוך מערכות אבטחה או אחסון

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

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

מיתוס 2. כאשר יש RAID, אין צורך יותר בגיבוי.

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

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

מיתוס 3. גיבוי הוא משהו שעושים פעם בחודש.

תדירות הגיבוי היא הגדרה הניתנת להגדרה שתלויה בעיקר בדרישות מערכת הגיבוי שלך. בהחלט ניתן למצוא נתונים שכמעט ולא משתנים ואינם חשובים במיוחד, אובדנם לא יהיה קריטי עבור החברה.
אכן, ניתן לגבות אותם פעם בחודש ואף פחות. אבל נתונים קריטיים יותר נשמרים לעתים קרובות יותר, בהתאם למחוון RPO (Recovery Point Objective), שקובע את אובדן הנתונים המותר. זה יכול להיות פעם בשבוע, פעם ביום, או אפילו כמה פעמים בשעה. יש לנו את יומני העסקאות האלה מה-DBMS.

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

מיתוס 4. נפח העותקים גדל כל הזמן ותופס כל מקום שהוקצה לחלוטין.

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

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

מיתוס 5. החל גיבוי - הכל נתקע

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

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

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

בארגונים גדולים נוצרת רשת נפרדת למערכת הגיבוי כך שהגיבוי לא ישפיע על הייצור. בנוסף, ייתכן שתעבורה לא תועבר דרך הרשת, אלא דרך ה-SAN.

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

מיתוס 6. השיקה מערכת גיבוי - זו סובלנות תקלות עבורך

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

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

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

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

וקצת על עבודתו של מנהל המערכת

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

יחד עם זאת, יש עדיין עבודה רבה בשל צי השרתים הנרחב, כולל מסדי נתונים, מערכות דואר, אשכולות מכונות וירטואליות ושיתופי קבצים גם ב-Windows וגם ב-Linux/Unix. עובדים ששומרים על מערכת הגיבוי פועלת לא יושבים בטל.

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

מקור: www.habr.com