אנחנו ב-Veeam אוהבים יומנים. ומכיוון שרוב הפתרונות שלנו הם מודולריים, הם כותבים הרבה יומנים. ומכיוון שהיקף הפעילות שלנו הוא להבטיח את בטיחות הנתונים שלך (כלומר שינה רגועה), אז היומנים צריכים לא רק לתעד כל עיטוש, אלא גם לעשות זאת בפירוט מסוים. זה הכרחי כדי שבמקרה של משהו יהיה ברור איך ה"מה" הזה קרה, מי אשם ומה צריך לעשות הלאה. זה כמו במדע משפטי: אתה אף פעם לא יודע איזה דבר קטן יעזור לך למצוא את הרוצח של לורה פאלמר.
לכן, החלטתי להסתכל על סדרת מאמרים, שבה אדבר ברצף על מה אנחנו כותבים לבולי עץ, איפה אנחנו מאחסנים אותם, איך לא להשתגע מהמבנה שלהם ומה לחפש בתוכם.
למה סדרת מאמרים ולמה לא לתאר הכל בבת אחת?
פשוט לרשום איזה יומן נמצא איפה ומה מאוחסן בו זו משימה הרת אסון. וזה מפחיד אפילו לחשוב על שמירת המידע הזה מעודכן. רשימה פשוטה של כל סוגי היומנים האפשריים ב- Veeam Backup & Replication היא טבלה על מספר גיליונות באותיות קטנות. כן, וזה יהיה רלוונטי רק בזמן הפרסום, כי. כאשר התיקון הבא ישוחרר, עלולים להופיע לוגים חדשים, ההיגיון של המידע המאוחסן באלה הישנים ישתנה וכו'. לכן, זה יהיה הרבה יותר משתלם להסביר את המבנה שלהם ואת מהות המידע הכלול בהם. זה יאפשר לך לנווט טוב יותר במקומות מאשר דחיסת שמות בנאלית.
לכן, כדי לא למהר אל מאגר דפי הטקסט, בואו נעשה עבודת הכנה במאמר זה. לכן, היום לא ניכנס ליומנים עצמם, אלא נלך מרחוק: נרכיב מילון מונחים ונדון מעט במבנה ה-Veeam מבחינת יצירת יומנים.
מילון מונחים וז'רגון
כאן, קודם כל, כדאי להתנצל בפני אלופי טוהר השפה הרוסית ועדי המילון של אוז'גוב. כולנו אוהבים מאוד את שפת האם שלנו, אבל תעשיית ה-IT הארורה פועלת באנגלית. ובכן, לא הגענו לזה, אבל זה קרה היסטורית. זו לא אשמתי, הוא הגיע בעצמו (ג)
בעסק שלנו, לבעיית האנגליזמים (וז'רגון) יש מאפיינים משלה. כשתחת מילים תמימות כמו "מארח" או "אורח" כל העולם כבר מזמן הבין דברים מאוד ספציפיים, אז על ⅙ של הארץ, הבלבול ההירואי וההלם עם חיטוט במילונים נמשך. והטיעון המחייב בהחלט "אבל בעבודה שלנו...".
בנוסף, ישנו אך ורק הטרמינולוגיה שלנו, הטבועה במוצרי Veeam, אם כי כמה מילים וביטויים הגיעו לאנשים. לכן, עכשיו נסכים על מה המונח אומר מה, ובעתיד, מתחת למילה "אורח", אתכוון בדיוק למה שכתוב בפרק זה, ולא למה שאתה רגיל בעבודה. וכן, זו לא הגחמה האישית שלי, אלו מונחים מבוססים בתעשייה. להילחם בהם זה קצת חסר טעם. למרות שאני תמיד בעד להירגע בתגובות.
לצערי, יש הרבה מונחים בעבודה ובמוצרים שלנו, אז לא אנסה לפרט את כולם. רק המידע הבסיסי וההכרחי ביותר על גיבויים ויומנים להישרדות בים. למעוניינים, אני יכול גם עמיתים על קלטות, שם הוא גם נתן רשימה של מונחים הקשורים לחלק זה של הפונקציונליות.
מארח (מארח): בעולם הוירטואליזציה מדובר במכונה עם היפרוויזר. פיזי, וירטואלי, ענן - זה לא משנה. אם משהו מריץ היפרוויזר (ESXi, Hyper-V, KVM וכו'), אז ה"משהו" הזה נקרא מארח. בין אם זה אשכול עם עשרה מתלים או המחשב הנייד שלך עם מעבדה למכונה וירטואלית אחת וחצי - אם השקת Hypervisor, הפכת למארח. מכיוון שה-Hypervisor מארח מכונות וירטואליות. יש אפילו סיפור ש-VMware רצתה בזמנו להשיג שיוך מוצק של המילה מארח עם ESXi. אבל היא לא עשתה זאת.
בעולם המודרני, המושג "מארח" התמזג למעשה עם המושג "שרת", מה שמביא קצת בלבול בתקשורת, במיוחד כשמדובר בתשתית Windows. אז כל מכונה שמארחת שירות כלשהו שמעניין אותנו יכולה להיקרא בבטחה מארח. לדוגמה, ביומנים של WinSock הכל מסומן במילה host. הקלאסי "המארח לא נמצא" הוא דוגמה לכך. אז אנחנו מתחילים מהקשר, אבל זכרו - בעולם הווירטואליזציה, מארח הוא מה שמארח אורחים (עוד על כך בשתי שורות למטה).
מהז'רגון המקומי (במקרה זה אפילו ראשי תיבות), נזכיר כאן ש-VMware הוא VI, vSphere הוא VC, וה-Hyper-V הוא HV.
אורח (אורח): המכונה הוירטואלית הפועלת על המארח. אין כאן מה להסביר, הכל כל כך הגיוני ופשוט. עם זאת, רבים גוררים כאן בשקידה כמה משמעויות אחרות.
בשביל מה? אני לא יודע.
מערכת ההפעלה Guest, בהתאמה, מערכת ההפעלה של מכונת האורח. וכולי.
עבודת גיבוי/שכפול (jobA): ז'רגון Wim טהור, מציין כמה מהמשימות. עבודת גיבוי == עבודת גיבוי. אף אחד לא הבין איך לתרגם את זה יפה לרוסית, אז כולם אומרים "JobA". בדגש על ההברה האחרונה.
כן, הם פשוט לוקחים את זה ואומרים "ג'ובה". ואפילו במכתבים כותבים כך, והכל בסדר.
כל מיני עבודות גיבוי, משימות גיבוי וכו', תודה, אבל אין צורך. רק עבודה, ויוכלו להבין. העיקר לשים את הלחץ על ההברה האחרונה.
גיבוי (גיבוי, גיבוי. עבור true-oldfags, גיבוי מותר): בנוסף למובן מאליו (עותק גיבוי של נתונים מונחים איפשהו), המשמעות היא גם העבודה עצמה (שלוש שורות למעלה, אם כבר שכחתם), וכתוצאה מכך מופיע קובץ הגיבוי עצמו. כנראה, רבותי דוברי אנגלית שפת אם הם עצלנים מדי לומר שניהלתי את עבודת הגיבוי שלי בכל פעם, אז הם פשוט אומרים שניהלתי את הגיבוי שלי, וכולם מבינים זה את זה בצורה מושלמת. אני מזמין אתכם לתמוך ביוזמה הנפלאה הזו.
איחוד (איחוד): מונח שהופיע ב-ESXi 5.0 אפשרות בתפריט תמונת המצב שמתחילה תהליך של מחיקת מה שנקרא תצלומי מצב יתומים. כלומר, תמונות שזמינות פיזית, אך נפלו מהמבנה הלוגי המוצג. תיאורטית, תהליך זה לא אמור להשפיע על הקבצים המוצגים במנהל התמונות, אבל הכל יכול לקרות. המהות של תהליך הקונסולידציה היא שהנתונים מתמונת המצב (דיסק ילד) נכתבים לדיסק הראשי (האב). תהליך שילוב הדיסקים נקרא מיזוג. אם הונפקה פקודת איחוד, ניתן להסיר את רשומת תמונת המצב ממסד הנתונים לפני מיזוג ומחיקת תמונת המצב. ואם לא ניתן היה למחוק את תמונת המצב מסיבה כלשהי, אזי אותן תמונות יתומות מופיעות. לגבי עבודה עם צילומי מצב, יש ל-VMware . ואנחנו גם איכשהו לגביהם .
מאגר נתונים (אחסון או אחסון): מושג רחב מאוד, אבל בעולם הוירטואליזציה, הוא מובן כמקום שבו מאוחסנים קבצי מכונות וירטואליות. אבל בכל מקרה, כאן אתה צריך להבין את ההקשר בצורה ברורה מאוד, ועם הספק הקטן ביותר, להבהיר מה בדיוק חשב בן שיחו.
פרוקסי (פרוקסי): חשוב להבין מיד ש-Veeam Proxy אינו דומה למה שאנו רגילים אליו באינטרנט. בתוך מוצרי Veeam מדובר במעין ישות העוסקת בהעברת נתונים ממקום למקום. אם לא נכנסים לפרטים, אז VBR הוא שרת פיקוד ובקרה, ופרוקסי הם סוסי העבודה שלו. כלומר, פרוקסי הוא מכונה שדרכו זורמת התעבורה ועליה מותקנים רכיבי VBR שעוזרים לנהל את התעבורה הזו. למשל, להעביר נתונים מערוץ אחד לאחר, או פשוט להדביק דיסקים לעצמו (מצב HotAdd).
מאגר (מאגר): מבחינה טכנית, זהו רק ערך במסד הנתונים של VBR, המציין את המקום שבו מאוחסנים הגיבויים, וכיצד להתחבר למקום הזה. למעשה, זה יכול להיות רק כדור CIFS או דיסק נפרד, שרת או דלי בענן. שוב, אנחנו בהקשר, אבל אנחנו מבינים שמאגר הוא רק מקום שבו נמצאים הגיבויים שלך.
תמונת מצב (SnapshOt): חובבי הדקדוק של אוקספורד מעדיפים לומר מי הוא סנאפצ'ט ומי הוא סנאפצ'ט, אבל הרוב האנאלפביתי מרוויח מהמסה הגדולה יותר. אם מישהו לא יודע, זו טכנולוגיה שמאפשרת לשחזר את מצב הדיסק בנקודת זמן מסוימת. זה נעשה על ידי הפנייה זמנית של פעולות I/O הרחק מהדיסק הראשי - ואז זה ייקרא תצלום מצב של RoW (Redirect on Write) - או על ידי העברת בלוקים הניתנים לכתיבה מחדש מהדיסק שלך לאחר - זה ייקרא CoW (Copy on Write) ) תמונת מצב. הודות לאפשרויות הרחבות לשימוש בפונקציות הללו, Veeam יכולה להפעיל את קסם הגיבוי שלה. למהדרין, לא רק הם, אלא זה העניין של המהדורות הבאות.
יש תוהו ובוהו סביב המונח הזה בתיעוד ובלוגים של ESXi, ובהקשר של אזכור תצלומי מצב, אתה יכול למצוא צילומי מצב בעצמם, ולבצע שוב יומן, ואפילו דיסק דלתא. התיעוד של Veeam לא מכיל קרע כזה, ותמונת מצב היא תמונת מצב, ו-redo log הוא בדיוק קובץ REDO שנוצר על ידי דיסק עצמאי בלתי מתמיד. קבצי REDO נמחקים כשהמכונה הוירטואלית כבויה, כך שבלבול ביניהם עם צילומי מצב הוא נתיב לכישלון.
סינתטי (סינטטי): גיבויים סינתטיים הם גיבויים מצטברים לאחור ולתמיד קדימה. למקרה שלא נתקלתם במונח הזה, זה רק אחד מהמנגנונים המשמשים לבניית טרנספורמציה של שרשרת גיבוי. עם זאת, ביומנים ניתן למצוא גם את המושג Transform, המשמש במסגרת של יצירת עותקים מלאים ממרווחים (מלא סינתטי).
משימה (משימה): זהו תהליך העיבוד של כל מכונה בנפרד במסגרת העבודה. כלומר: יש לך עבודת גיבוי, הכוללת שלוש מכונות. המשמעות היא שכל מכונית תטופל כחלק ממשימה נפרדת. בסך הכל, יהיו ארבעה יומנים: העיקרי עבור משרות ושלושה עבור משימות. עם זאת, יש כאן ניואנס חשוב: עם הזמן, המילה "משימה" הפכה לדו-משמעית שלא לצורך. כשאנחנו מדברים על יומנים כלליים, אנחנו מתכוונים שמשימה היא בדיוק VM. אבל יש "משימות" הן בפרוקסי והן במאגר. שם זה יכול להיות דיסק וירטואלי, מכונה וירטואלית וכל העבודה. כלומר, חשוב לא לאבד את ההקשר.
שירות Veeam %name%: לטובת גיבויים מוצלחים פועלים מספר שירותים בבת אחת, שרשימתם ניתן למצוא בציוד הסטנדרטי. השמות שלהם משקפים בשקיפות למדי את המהות שלהם, אבל בין השווים יש את החשוב ביותר - Veeam Backup Service, שבלעדיו השאר לא יעבוד.
VSS: מבחינה טכנית, VSS צריך תמיד לעמוד עבור Microsoft Volume Shadow Copy Service. למעשה, הוא משמש על ידי רבים כמילה נרדפת לעיבוד תמונה מודע ליישום. מה שכמובן שגוי קטגורית, אבל זה סיפור מהקטגוריה "כל רכב שטח יכול להיקרא ג'יפ, ויבינו אותך".
בולי עץ פנטסטיים והיכן הם חיים
אני רוצה להתחיל את הפרק הזה בגילוי הסוד הגדול - מה השעה שמוצגת ביומנים?
זכור:
- ESXi תמיד כותב יומנים ב-UTC+0.
- vCenter שומר יומנים בהתאם לזמן של אזור הזמן שלו.
- Veeam שומרת יומנים לפי זמן ואזור זמן של השרת שבו הוא נמצא.
- ורק אירועי Windows בפורמט EVTX לא סובלים מקישור לכלום. בפתיחה, הזמן מחושב מחדש עבור המכונית שבה הם נפתחו. האפשרות הנוחה ביותר, אם כי יש איתה קשיים. הקושי המוחשי היחיד הוא ההבדל במקומות. זהו נתיב מובטח כמעט ליומנים בלתי קריאים. כן, יש אפשרויות איך לטפל בזה, אבל בואו פשוט לא נתווכח עם העובדה שהכל ב-IT עובד באנגלית, ונסכים להגדיר תמיד את המקום האנגלי בשרתים. נו באמת.
עכשיו בואו נדבר על המקומות שבהם חיים בולי העץ וכיצד להשיג אותם. במקרה של VBR, ישנן שתי גישות.
האפשרות הראשונה מתאימה אם אינך להוט לחפש קבצים בערימה הכללית הקשורים ספציפית לצרות שלך. לשם כך, יש לנו אשף נפרד, אליו תוכל לציין עבודה ספציפית ותקופה מסוימת עבורה אתה צריך יומנים. לאחר מכן הוא יעבור בעצמו על התיקיות ויכניס את כל מה שצריך בארכיון אחד. היכן לחפש אותו וכיצד לעבוד איתו מתואר בפירוט ב .
עם זאת, האשף אינו אוסף את היומנים של כל המשימות, ולדוגמה, אם אתה צריך ללמוד את יומני השחזור, הכשל או הכשל, הנתיב שלך נמצא בתיקייה %ProgramData%/Veeam/גיבוי. זהו חנות הלוגו הראשית של VBR ו-%ProgramData% היא תיקייה נסתרת וזה בסדר. אגב, ניתן להקצות מחדש את מיקום ברירת המחדל באמצעות מפתח הרישום REG_SZ: LogDirectory בענף HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
במחשבי לינוקס, יש לחפש יומני סוכן עובדים ב- /var/log/VeeamBackup/אם אתה משתמש בחשבון root או sudo. אם אין לך הרשאות כאלה, חפש כניסות /tmp/VeeamBackup.
עבור סוכן Veeam עבור %OS_name% יש לחפש ביומנים %ProgramData%/Veeam/Endpoint (או %ProgramData%/Veeam/Backup/Endpoint) ו /var/log/veeam בהתאמה.
אם אתה משתמש בעיבוד תמונה מודע ליישום (וסביר להניח שאתה עושה זאת), אז המצב הופך להיות קצת יותר מסובך. תצטרך את היומנים של העוזר שלנו, המאוחסנים בתוך המכונה הוירטואלית עצמה, ואת יומני ה-VSS. על איך והיכן להשיג את האושר הזה, כתוב בפירוט ב . וכמובן שיש כדי לאסוף את יומני המערכת הדרושים.
אירועי Windows נאספים בנוחות לפי . אם אתה משתמש ב-Hyper-V, הדברים מסתבכים יותר, מכיוון שתצטרך גם את כל היומנים שלו מהיישומים ויומני השירות > Microsoft > סניף Windows. למרות שאתה תמיד יכול ללכת בדרך המטופשת יותר ופשוט לאסוף את כל האובייקטים מ-%SystemRoot%System32winevtLogs.
אם משהו נשבר במהלך ההתקנה/שדרוג, כל מה שאתה צריך נמצא בתיקייה %ProgramData%/Veeam/Setup/Temp. למרות שלא אסתיר את העובדה שבאירועי מערכת ההפעלה ניתן למצוא מידע שימושי יותר מאשר ביומנים אלו. שאר המעניינים טמונים ב-%Temp%, אבל יש בעיקר יומני התקנה לתוכנות קשורות, כמו הבסיס, ספריות .Net ודברים אחרים. שימו לב כי Veeam מותקן מ-msi וכל הרכיבים שלו מותקנים גם כחבילות msi נפרדות, גם אם זה לא הוצג ב-GUI. לכן, אם ההתקנה של אחד הרכיבים תיכשל, כל התקנת VBR תופסק. לכן, אתה צריך להיכנס ליומנים ולראות מה בדיוק נשבר ובאיזה נקודה.
ולבסוף, פריצת חיים: אם אתה מקבל שגיאה במהלך ההתקנה, אל תמהר ללחוץ על אישור. ראשית ניקח את היומנים ולאחר מכן לחץ על אישור. כך תקבלו יומן שמסתיים בזמן השגיאה, ללא זבל בסוף.
וזה קורה שאתה צריך להיכנס ליומני vSphere. הכיבוש מאוד כפוי טובה, אבל אחרי שהפשיל שרוולים צריך לעשות משהו אחר. בגרסה הפשוטה ביותר, אנחנו צריכים יומנים עם אירועי מחשב וירטואלי vmware.log, שנמצאים ליד קובץ ה-.vmx שלו. במקרה קשה יותר, פתח את Google ושאל היכן נמצאים היומנים של גרסת המארח שלך, מכיוון ש-VMware אוהבת לשנות את המקום הזה מהדורה לגרסה. לדוגמה, , אלא בשביל . עבור יומני vCenter, חזור על ההליך . אבל באופן כללי, אנו נתעניין ביומני אירועי מארח hostd.log, אירועים מארח המנוהלים על ידי vCenter vpxa.log, יומני ליבה vmkernel.log ויומני אימות auth.log. ובכן, במקרים המוזנחים ביותר, יומן SSO, שנמצא בתיקיית SSO, עשוי להועיל.
מסורבל? מְבוּלבָּל? מַפְחִיד? אבל זה אפילו לא מחצית מהמידע שהתמיכה שלנו עובדת איתו על בסיס יומי. אז הם ממש ממש מגניבים.
רכיבי Veeam
וכסיכום למאמר המבוא הזה, בואו נדבר קצת על הרכיבים של Veeam Backup & Replication. שכן כאשר אתה מחפש את הסיבה לכאב, זה יהיה נחמד להבין איך המטופל עובד.
אז, כפי שכולם בוודאי יודעים, Veeam Backup הוא מה שנקרא יישום מבוסס SQL. כלומר, כל ההגדרות, כל המידע ובכלל כל מה שצריך רק לתפקוד תקין – כל זה נמצא במאגר הנתונים שלו. או ליתר דיוק, בשני מסדי נתונים, אם אנחנו מדברים על חבורה של VBR ו-EM: VeeamBackup ו-VeeamBackupReporting, בהתאמה. וכך קרה: שמנו עוד אפליקציה - מסד נתונים נוסף מופיע. כדי לא לאחסן את כל הביצים בסל אחד.
אבל כדי שכל הכלכלה הזו תעבוד בצורה חלקה, אנחנו צריכים סט שירותים ויישומים שיקשרו את כל הרכיבים יחד. רק כדוגמה, כך זה נראה באחת המעבדות שלי:
משמש כמנצח ראשי שירות גיבוי Veeam. הוא זה שאחראי על חילופי המידע עם הבסיסים. הוא גם אחראי על השקת כל המשימות, תזמור משאבים שהוקצו ועבודה כמעין מרכז תקשורת למגוון קונסולות, סוכנים וכל השאר. במילה אחת, בהחלט אין דרך בלעדיו, אבל זה בכלל לא אומר שהוא עושה הכל בעצמו.
עוזר לו בהגשמת תוכניתו מנהל הגיבוי של Veeam. לא מדובר בשירות, אלא בגוף שמשיק עבודות ועוקב אחר תהליך ביצוען. הידיים העובדות של שירות הגיבוי, איתן הוא מתחבר למארחים, יוצר צילומי מצב, מנטר שימור וכדומה.
אבל בחזרה לרשימת השירותים. שירות ברוקר של Veeam. הופיע בגרסה 9.5 (וזה לא כורה קריפטו, כפי שחשבו אז). אוסף מידע על מארחי VMware ושומר על הרלוונטיות שלו. אבל אל תרוצו מיד לכתוב הערות זועמות שאנחנו מרגלים אחריכם ומדליפים את כל ההתחברות/סיסמאות ל-taschmajor. הכל קצת יותר פשוט. כאשר אתה מפעיל גיבוי, הדבר הראשון שאתה צריך לעשות הוא להתחבר למארח ולעדכן את כל הנתונים על המבנה שלו. זה סיפור די איטי ומסורבל. רק זכרו כמה זמן לוקח לכם להיכנס דרך ממשק האינטרנט, וזכרו שרק השכבה העליונה נספרת שם. ואז אתה עדיין צריך לפתוח את כל ההיררכיה למקום הנכון, אגב. במילה אחת, אימה. אם אתה מפעיל תריסר גיבויים, כל עבודה צריכה לבצע את ההליך הזה. אם אנחנו מדברים על תשתיות גדולות, אז התהליך הזה יכול לקחת עשר דקות או יותר. לפיכך, הוחלט להקצות לכך שירות נפרד, באמצעותו ניתן יהיה לקבל מידע מעודכן תמיד. בעת ההפעלה, הוא בודק וסורק את כל התשתיות שנוספו, ולאחר מכן מנסה לעבוד רק ברמת השינויים המצטברים. אז גם אם תפעילו מאה גיבויים בו-זמנית, כולם יבקשו מידע מהברוקר שלנו, ולא יייסרו את המארחים בבקשותיהם. אם אתה מודאג לגבי משאבים, אז לפי החישובים שלנו, 5000 מכונות וירטואליות זקוקות רק ל-100 מגה-ביט של זיכרון.
הבא יש לנו קונסולת Veeam. הוא Veeam Remote Console, הוא Veeam.Backup.Shell. זהו אותו GUI שאנו רואים בצילומי המסך. הכל פשוט וברור - את הקונסולה אפשר להפעיל מכל מקום, כל עוד מדובר ב-Windows ויש חיבור לשרת VBR. הדבר היחיד שניתן לומר הוא שתהליך ה-FLR ירכיב נקודות באופן מקומי (כלומר במכונה שבה פועלת הקונסולה). ובכן, מגוון Veeam Explorers יפעלו גם באופן מקומי, כי הם חלק מהקונסולה. אבל זה כבר הוביל אותי לטבע הפראי...
שירות מעניין נוסף הוא שירות הנתונים בקטלוג הגיבוי של Veeam. ידוע כשירות קטלוג האורחים של Veeam ברשימת השירותים. הוא עוסק באינדקס מערכות קבצים במחשבי אורחים וממלא את תיקיית VBRCatalog בידע זה. הוא משמש רק כאשר תיבת הסימון לאינדקס מופעלת. וזה הגיוני להפעיל את זה רק אם יש לך Enterprise Manager. לכן, עצה מעומק ליבי: אל תפעיל אינדקס סתם כך אם אין לך EAT. חסוך את העצבים שלך וזמן תמיכה.
גם משירותים חשובים אחרים ראוי לציין שירות מתקין Veeam, בעזרתם נמסרים ומותקנים הרכיבים הדרושים על פרוקסי, מאגרים ושערים נוספים. למעשה, הוא לוקח את חבילות ה-.msi הדרושות לשרתים ומתקין אותם.
Veeam Data Mover - בעזרת סוכני עזר שהושקו על פרוקסי (ולא רק) היא עוסקת בהעברת נתונים. לדוגמה, בעת גיבוי, סוכן אחד יקרא קבצים ממאגר הנתונים המארח, והשני יכתוב אותם בזהירות לגיבוי.
בנפרד, ברצוני לציין דבר חשוב שלקוחות מגיבים אליו לעתים קרובות - זה ההבדל בגרסאות השירותים והמידע ב-Snap-in Programs and Features. כן, הרשימה תהיה זהה, אבל הגרסאות עשויות להיות סותרות לחלוטין. זה לא מאוד מגניב מנקודת מבט ויזואלית, אבל זה נורמלי לחלוטין אם הכל עובד ביציבות. לדוגמה, עבור שירות Installer, מספר הגרסה נמצא הרחק מאחורי אלה השכנות. אימה וסיוט? לא, כי הוא לא מותקן מחדש לחלוטין, אבל ה-DLL שלו פשוט מעודכן. בתיקון v9.5 U4, התרחש סיוט של תמיכה טכנית: במהלך העדכון, כל השירותים קיבלו גרסאות חדשות, מלבד החשובה ביותר. בתיקון U4b, שירות התחבורה עקף את כל האחרים בשתי גרסאות (אם לשפוט לפי המספרים). וזה גם נורמלי - נמצא בו באג רציני, אז הוא קיבל עדכון בונוס ביחס לשאר. אז לסיכום: הבדלי גרסאות יכולים להיות בעיה, אבל אם יש הבדל והכל עובד כמו שצריך, אז כנראה שזה צריך להיות. אבל אף אחד לא אוסר עליך להבהיר זאת בתמיכה הטכנית.
אלה היו מה שנקרא שירותי חובה או חובה. ויש חבורה שלמה של עזר, כמו טייפ שירות, שירות הר, שירות vPowerNFS וכן הלאה.
עבור Hyper-V, באופן כללי, הכל אותו דבר, רק שיש ספציפי שירות שילוב Veeam Backup Hyper-V ונהג משלך לעבודה עם CBT.
ובסופו של דבר, בואו נדבר על מי עובד על מכונות וירטואליות במהלך הגיבוי. להפעיל סקריפטים לפני ואחרי הקפאה, ליצור עותק צללים, לאסוף מטא נתונים, לעבוד עם יומני עסקאות של SQL וכו'. עוזר אורח של Veeam. ואם מערכות קבצים מתווספות לאינדקס, אינדקס אורחים של Veeam . אלו הם שירותים זמניים שנפרסו למשך הגיבוי והוסרו לאחריו.
במקרה של מכונות לינוקס, הכל הרבה יותר פשוט בגלל נוכחותן של מספר רב של ספריות מובנות והיכולות של המערכת עצמה. לדוגמה, אינדקס נעשה באמצעות mlocate.
זה הכל לעת עתה
אני לא מעז לפגוע בך יותר קצר אני חושב שההקדמה לתא המנוע של Veeam הסתיימה. כן, אפילו לא התקרבנו למאורות עצמן, אבל תאמין לי, כדי שהמידע המוצג בהן לא ייראה כמו זרם תודעתי לא קוהרנטי, הקדמה כזו היא הכרחית לחלוטין. אני מתכנן ללכת ללוגים עצמם רק במאמר השלישי, והתוכנית למאמר הבא היא להסביר מי מייצר את היומנים, מה בדיוק מוצג בהם ולמה בדיוק, ולא אחרת.
מקור: www.habr.com
