גיבוי חלק 7: מסקנות

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

נתונים גולמיים

לשרת ייעודי יש לרוב לפחות שני כוננים קשיחים המשמשים לארגון מערך RAID ברמה ראשונה (מראה). זה הכרחי כדי להיות מסוגל להמשיך להפעיל את השרת אם דיסק אחד נכשל. אם מדובר בשרת ייעודי רגיל, ייתכן שיהיה בקר חומרה RAID נפרד עם טכנולוגיית מטמון אקטיבית על SSD, כך שבנוסף לכוננים קשיחים רגילים, ניתן לחבר SSD אחד או יותר. לפעמים מוצעים שרתים ייעודיים, שבהם הדיסקים המקומיים היחידים הם SATADOM (דיסקים קטנים, מבחינה מבנית כונן הבזק המחובר ליציאת SATA), או אפילו כונן הבזק קטן (8-16GB) רגיל המחובר ליציאה פנימית מיוחדת, וה הנתונים נלקחים ממערכת האחסון, מחוברים דרך רשת אחסון ייעודית (Ethernet 10G, FC וכו'), ויש שרתים ייעודיים שנטענים ישירות ממערכת האחסון. לא אשקול אפשרויות כאלה, מכיוון שבמקרים כאלה משימת הגיבוי של השרת עוברת בצורה חלקה למומחה המתחזק את מערכת האחסון; בדרך כלל ישנן טכנולוגיות קנייניות שונות ליצירת תמונות מצב, מניעת כפילויות מובנית והנאות אחרות של מנהל המערכת. , שנדון בחלקים הקודמים של סדרה זו. נפח מערך הדיסקים של שרת ייעודי יכול להגיע לכמה עשרות טרה-בייט, בהתאם למספר וגודל הדיסקים המחוברים לשרת. במקרה של VPS, הנפחים צנועים יותר: לרוב לא יותר מ-100GB (אבל יש גם יותר), והתעריפים עבור VPS כזה יכולים בקלות להיות יקרים יותר מהשרתים הייעודיים הזולים ביותר מאותו מארח. ל-VPS לרוב יש דיסק אחד, מכיוון שתהיה מערכת אחסון (או משהו מתכנס) מתחתיו. לפעמים ל-VPS יש כמה דיסקים עם מאפיינים שונים, למטרות שונות:

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

כאשר אתה מתקין מחדש את המערכת באמצעות לוח הבקרה, הדיסק עם נתוני המשתמש אינו מוחלף, אך דיסק המערכת מתמלא מחדש לחלוטין. כמו כן, במקרה של VPS, המארח עשוי להציע כפתור שמצלם תמונת מצב של ה-VPS (או הדיסק), אך אם תתקין מערכת הפעלה משלך או תשכח להפעיל את השירות הרצוי בתוך ה-VPS, חלק מהנתונים עדיין עלולים ללכת לאיבוד. בנוסף לכפתור, מוצע בדרך כלל שירות אחסון נתונים, לרוב מוגבל מאוד. בדרך כלל מדובר בחשבון עם גישה דרך FTP או SFTP, לפעמים יחד עם SSH, עם מעטפת מופשטת (לדוגמה, rbash), או הגבלה על הפעלת פקודות דרך authorized_keys (באמצעות ForcedCommand).

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

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

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

ארגון לוגי של מערכת הדיסקים

אם יש לך בקר RAID, או VPS עם דיסק אחד, ואין העדפות מיוחדות לתפעול תת-מערכת הדיסק (לדוגמה, דיסק מהיר נפרד למסד נתונים), כל השטח הפנוי מחולק באופן הבא: מחיצה אחת נוצר, ומעליו נוצרת קבוצת נפח LVM , נוצרים בה מספר כרכים: 2 קטנים באותו גודל, המשמשים כמערכת קבצי השורש (השתנו אחד אחד במהלך העדכונים לאפשרות החזרה מהירה, הרעיון נקלט מהפצת Calculate Linux), אחד נוסף מיועד למחיצת ההחלפה, שאר השטח הפנוי מחולק לנפחים קטנים, המשמשים כמערכת קבצי השורש עבור קונטיינרים מלאים, דיסקים למכונות וירטואליות, קובץ מערכות לחשבונות ב-/home (לכל חשבון יש מערכת קבצים משלו), מערכות קבצים למיכלי יישומים.

הערה חשובה: כרכים חייבים להיות עצמאיים לחלוטין, כלומר. לא אמורים להיות תלויים זה בזה או במערכת קבצי השורש. במקרה של מכונות וירטואליות או קונטיינרים, נקודה זו נצפה באופן אוטומטי. אם אלו הם מיכלי יישומים או ספריות ביתיות, כדאי לחשוב על הפרדת קבצי התצורה של שרת האינטרנט ושירותים אחרים בצורה כזו שתבטל ככל האפשר תלות בין אמצעי האחסון. לדוגמה, כל אתר פועל מהמשתמש שלו, קבצי תצורת האתר נמצאים בספריית הבית של המשתמש, בהגדרות שרת האינטרנט, קבצי תצורת האתר אינם כלולים דרך /etc/nginx/conf.d/.conf, וכן, למשל, /home//configs/nginx/*.conf

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

ללא קשר לסכימת השימוש, תמיד כדאי להעריך מראש את המהירות המשוערת של כתיבת שינויים לדיסקים, ולאחר מכן לחשב את כמות השטח הפנוי שיישמר ליצירת תמונות מצב. למשל, אם השרת שלנו כותב נתונים במהירות של 10 מגה-בייט לשנייה, וגודל מערך הנתונים כולו הוא 10 טרה-בייט - זמן הסנכרון יכול להגיע ליום (22 שעות - זה כמה נפח כזה יועבר ברשת 1 Gbps) - כדאי להזמין כ-800 GB . במציאות, הדמות תהיה קטנה יותר; אתה יכול לחלק אותו בבטחה במספר הכרכים הלוגיים.

התקן שרת אחסון גיבוי

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

• נפחים התואמים לשרתים המשמשים לאחסון נתוני משתמש (הגיבוי האחרון שנעשה ייפרס עליהם לצורך אימות);
• אמצעי אחסון המשמשים כמאגרי BorgBackup (נתונים לגיבויים יעברו ישירות לכאן).

עקרון הפעולה הוא שנפחים נפרדים נוצרים עבור כל שרת עבור מאגרי BorgBackup, לשם יעברו נתונים משרתי הקרב. המאגרים פועלים במצב הוספה בלבד, מה שמבטל את האפשרות למחוק נתונים בכוונה, ובשל ביטול כפילויות וניקוי תקופתי של מאגרים מגיבויים ישנים (נותרים עותקים שנתיים, מדי חודש בשנה האחרונה, מדי שבוע בחודש האחרון, מדי יום עבור בשבוע שעבר, אולי במקרים מיוחדים - מדי שעה ליום האחרון: סך הכל 24 + 7 + 4 + 12 + שנתי - כ-50 עותקים לכל שרת).
מאגרי BorgBackup אינם מאפשרים מצב הוספה בלבד; במקום זאת, נעשה שימוש ב-ForcedCommand ב-.ssh/authorized_keys משהו כמו זה:

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

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

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

תהליך גיבוי

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

אם יש בסיס נתונים קטן (עד 1 ג'יגה לכל אתר), מתבצעת dump של בסיס נתונים, שנשמר בנפח הלוגי המתאים, שבו נמצאים שאר הנתונים של אותו אתר, אך כך שה-dump יהיה לא נגיש דרך שרת האינטרנט. אם מסדי הנתונים גדולים, עליך להגדיר הסרת נתונים "חם", למשל, באמצעות xtrabackup עבור MySQL, או לעבוד עם WAL עם archive_command ב-PostgreSQL. במקרה זה, בסיס הנתונים ישוחזר בנפרד מנתוני האתר.

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

עבודה נוספת מתבצעת על שרת אחסון הגיבוי:

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

תהליך שחזור שרת

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

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

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

מאמרים נוספים בסדרה

גיבוי, חלק 1: מדוע יש צורך בגיבוי, סקירה של שיטות, טכנולוגיות
גיבוי חלק 2: סקירה ובדיקה של כלי גיבוי מבוססי rsync
גיבוי חלק 3: סקירה ובדיקה של כפילות, כפילות
גיבוי חלק 4: סקירה ובדיקה של zbackup, restic, borgbackup
גיבוי חלק 5: בדיקת Bacula ו- Veeam Backup עבור לינוקס
גיבוי: חלק לבקשת הקוראים: סקירת AMANDA, UrBackup, BackupPC
גיבוי חלק 6: השוואת כלי גיבוי
גיבוי חלק 7: מסקנות

אני מזמין אותך לדון באפשרות המוצעת בהערות, תודה על תשומת הלב שלך!

מקור: www.habr.com