גיבוי, חלק 1: מטרה, סקירת שיטות וטכנולוגיות

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

תוכנית אידיאלית פועלת מהר, אינה דולפת זיכרון, אין לה חורים ואינה קיימת.

-לא ידוע

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

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

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

אמנים טובים מעתיקים, אמנים מעולים גונבים.

-פאבלו פיקאסו.

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

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

לו רק הייתי יודע היכן תיפול, הייתי פורש קשיות!

-פתגם בלארוסי עממי

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

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

הנה תיאוריה קטנה

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

- ז'אן ברולר

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

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

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

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

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

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

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

-לא ידוע

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

יש להבין את פורמט האחסון כדלקמן:

• אם יש תלות בשיטת האחסון הפיזית, אנו משנים את השיטה הפיזית.
• אם יש תלות בשיטת האחסון הלוגי, נשנה את השיטה הלוגית.

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

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

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

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

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

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

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

האם אתה שומר על ipsos custodiet?

(מי ישמור על השומרים עצמם? - לט.)

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

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

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

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

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

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

מומחה לתבלינים הוא לא זה שמוסיף אותם לכל מנה, אלא זה שלעולם לא מוסיף לה שום דבר נוסף.

-IN. סיניבסקי

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

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

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

• dd, המוכר לוותיקי ניהול המערכת, זה כולל גם תוכניות דומות (אותה dd_rescue, למשל).
• כלי עזר המובנים במערכות קבצים מסוימות היוצרות dump של מערכת הקבצים.
• כלי עזר אוכלי כל; למשל partclone.
• החלטות משלו, לרוב קנייניות; לדוגמה, NortonGhost ואילך.

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

• Rsync, תוכנית ופרוטוקול לשימוש כללי לסנכרון מצב מערכות הקבצים.
• כלי ארכיון מובנים (ZFS).
• כלי ארכיון של צד שלישי; הנציג הפופולרי ביותר הוא זפת. ישנם אחרים, למשל, dar - תחליף לזפת המכוון למערכות מודרניות.

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

• הרכבת מערכת הקבצים במצב קריאה בלבד (ReadOnly), או הקפאת מערכת הקבצים (הקפאה) - השיטה היא בעלת יישום מוגבל.
• יצירת תמונות מצב של מערכות קבצים או התקני חסימה (LVM, ZFS).
• שימוש בכלים של צד שלישי לארגון הופעות, גם במקרים בהם לא ניתן לספק את הנקודות הקודמות מסיבה כלשהי (תוכנות כמו עותקים חמים).
• עם זאת, טכניקת העתקה בשינוי (CopyOnWrite), לרוב היא קשורה למערכת הקבצים שבה נעשה שימוש (BTRFS, ZFS).

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

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

מועמדים מאלה שעומדים פחות או יותר בדרישות:

• גיבוי rdiff
• תמונת מצב
• גיהוק
• לְשַׁכְפֵּל
• כפילות
• תן לדופ
• אבל
• zbackup
• רסטי
• borgbackup

מכונה וירטואלית (מבוססת על XenServer) עם המאפיינים הבאים תשמש כספסל בדיקה:

• 4 ליבות 2.5 GHz,
• 16 ג'יגה זיכרון RAM,
• 50 GB אחסון היברידי (מערכת אחסון עם מטמון על SSD 20% מגודל הדיסק הוירטואלי) בצורה של דיסק וירטואלי נפרד ללא חלוקה למחיצות,
• ערוץ אינטרנט 200 Mbps.

כמעט אותה מכונה תשמש כשרת מקלט גיבוי, רק עם כונן קשיח של 500 ג'יגה-בייט.

מערכת הפעלה - Centos 7 x64: מחיצה רגילה, מחיצה נוספת תשמש כמקור נתונים.

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

תוצאות בדיקת שרת באמצעות sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 הפעלת מעבד
sysbench 1.1.0-18a9f86 (באמצעות LuaJIT 2.1.0-beta3 מאגד)
הפעלת הבדיקה עם האפשרויות הבאות:
מספר האשכולות: 4
אתחול מחולל מספרים אקראיים מהזמן הנוכחי

הגבלת מספרים ראשוניים: 20000

מאתחל שרשורי עובדים...

החוטים התחילו!

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

תפוקה:
אירועים/ים (eps): 836.6908
זמן שחלף: 30.0039 שניות
מספר האירועים הכולל: 25104

חביון (ms):
דקות: 2.38
ממוצע: 4.78
מקסימום: 22.39
אחוזון 95: 10.46
סכום: 119923.64

הוגנות חוטים:
אירועים (avg/stddev): 6276.0000/13.91
זמן ביצוע (avg/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=ריצת זיכרון לקרוא
sysbench 1.1.0-18a9f86 (באמצעות LuaJIT 2.1.0-beta3 מאגד)
הפעלת הבדיקה עם האפשרויות הבאות:
מספר האשכולות: 4
אתחול מחולל מספרים אקראיים מהזמן הנוכחי

הפעלת בדיקת מהירות זיכרון עם האפשרויות הבאות:
גודל בלוק: 1KiB
גודל כולל: 102400MiB
פעולה: לקרוא
היקף: גלובלי

מאתחל שרשורי עובדים...

החוטים התחילו!

סך הפעולות: 50900446 (1696677.10 לשנייה)

49707.47 MiB הועבר (1656.91 MiB/sek)

תפוקה:
אירועים/ים (eps): 1696677.1017
זמן שחלף: 30.0001 שניות
מספר האירועים הכולל: 50900446

חביון (ms):
דקות: 0.00
ממוצע: 0.00
מקסימום: 24.01
אחוזון 95: 0.00
סכום: 39106.74

הוגנות חוטים:
אירועים (avg/stddev): 12725111.5000/137775.15
זמן ביצוע (avg/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=ריצת זיכרון לכתוב
sysbench 1.1.0-18a9f86 (באמצעות LuaJIT 2.1.0-beta3 מאגד)
הפעלת הבדיקה עם האפשרויות הבאות:
מספר האשכולות: 4
אתחול מחולל מספרים אקראיים מהזמן הנוכחי

הפעלת בדיקת מהירות זיכרון עם האפשרויות הבאות:
גודל בלוק: 1KiB
גודל כולל: 102400MiB
פעולה: לכתוב
היקף: גלובלי

מאתחל שרשורי עובדים...

החוטים התחילו!

סך הפעולות: 35910413 (1197008.62 לשנייה)

35068.76 MiB הועבר (1168.95 MiB/sek)

תפוקה:
אירועים/ים (eps): 1197008.6179
זמן שחלף: 30.0001 שניות
מספר האירועים הכולל: 35910413

חביון (ms):
דקות: 0.00
ממוצע: 0.00
מקסימום: 16.90
אחוזון 95: 0.00
סכום: 43604.83

הוגנות חוטים:
אירועים (avg/stddev): 8977603.2500/233905.84
זמן ביצוע (avg/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (באמצעות LuaJIT 2.1.0-beta3 מאגד)
הפעלת הבדיקה עם האפשרויות הבאות:
מספר האשכולות: 4
אתחול מחולל מספרים אקראיים מהזמן הנוכחי

דגלים נוספים לפתיחת קובץ: (אין)
128 קבצים, 8MiB כל אחד
גודל קובץ כולל של 1GiB
בלוק בגודל 4KiB
מספר בקשות IO: 0
יחס קריאה/כתיבה עבור מבחן IO אקראי משולב: 1.50
FSYNC תקופתי מופעל, קורא ל-fsync() כל 100 בקשות.
קורא fsync() בסוף הבדיקה, מופעל.
שימוש במצב קלט/פלט סינכרוני
עושה מבחן r/w אקראי
מאתחל שרשורי עובדים...

החוטים התחילו!

תפוקה:
קרא: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
כתוב: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

חביון (ms):
דקות: 0.00
ממוצע: 0.27
מקסימום: 18.01
אחוזון 95: 1.08
סכום: 238469.45

הערה זו מתחילה בגדול

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

1. גיבוי, חלק 1: מדוע יש צורך בגיבוי, סקירה של שיטות, טכנולוגיות
2. גיבוי חלק 2: סקירה ובדיקה של כלי גיבוי מבוססי rsync
3. גיבוי חלק 3: סקירה ובדיקה של כפילות, כפילות, דג'ה דופ
4. גיבוי חלק 4: סקירה ובדיקה של zbackup, restic, borgbackup
5. גיבוי חלק 5: בדיקת גיבוי bacula ו-veeam עבור לינוקס
6. גיבוי חלק 6: השוואת כלי גיבוי
7. גיבוי חלק 7: מסקנות

מקור: www.habr.com