מדיניות האחסון של Veeam B&R - פירוק שרשראות גיבוי יחד עם תמיכה טכנית

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

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

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

עבודות גיבוי

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

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

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

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

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

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

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

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

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

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

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

תשובה

הסבר: כדי לענות, פשוט שאלו את עצמכם "מתי תחול שימור"? התשובה היא כאשר נוכל להסיר את 3 הנקודות הראשונות (VBK, VIB, VIB) ושאר השרשרת לא יורדת מתחת ל-8 הנקודות הנדרשות. מתברר שנוכל לעשות זאת כשיהיו לנו 11 נקודות בסך הכל, כלומר ביום ראשון בשבוע השני.

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

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

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

בעיות

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

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

במקרים אחרים, גיבוי מלא מוגדר להיווצר באופן קבוע, אך משום מה לא. אפרט כאן את הסיבה הפופולרית ביותר. חלק מהלקוחות מעדיפים להשתמש באפשרות התזמון "ריצה אחרי" ולהגדיר משימות לרוץ בשרשרת. ניקח את הדוגמה הזו: יש 3 עבודות שפועלות כל יום ויוצרות גיבוי מלא ביום ראשון. המשימה הראשונה מתחילה ב-22.30, השאר מושקים בשרשרת. גיבוי מצטבר אורך 10 דקות, ולכן עד 23.00 כל העבודות מסיימות לעבוד. אבל גיבוי מלא לוקח שעה, אז ביום ראשון קורה הדבר הבא: המשימה הראשונה פועלת מ-22.30 עד 23.30. הבא מ-23.30 עד 00.30. אבל המשימה השלישית מתחילה ביום שני. גיבוי מלא מוגדר ליום ראשון, אז במקרה הזה זה פשוט לא יקרה. המשימה תחכה לגיבוי מלא כדי להחיל את השמירה. אז היזהר כשאתה משתמש באפשרות "ריצה אחרי" או אל תשתמש בה בכלל - פשוט הגדר את המשימות להתחיל באותו זמן ותן למתזמן המשאבים לעשות את עבודתו.

האפשרות הקשה "הסר פריטים שנמחקו"

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

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

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

הגיע הזמן להחיל שמירה, אבל לרכב אחד יש 7 נקודות ולשנייה רק ​​4. האם שמירה תיושם כאן? התשובה היא כן, זה יהיה. אם בוצע גיבוי של אובייקט אחד לפחות, B&R סבור שהנקודה נוצרה.

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

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

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

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

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

מה נוסף ב-v.10

מה שדיברנו עליו קודם קיים ב-B&R עבור גרסאות רבות. לאחר שהבנו את עקרונות הפעולה הללו, בואו נסתכל כעת על מה שהתווסף ל"עשר" יום השנה.

שימור יומי

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

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

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

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

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

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

ארכיון GFS לעבודות רגילות

לפני v.10, שיטת האחסון של סבא-אב-בן (GFS) הייתה זמינה רק עבור עבודות העתקת גיבוי ועבודות העתקת קלטות. כעת הוא זמין לגיבוי רגיל.

למרות שזה לא קשור לנושא הנוכחי, אני לא יכול שלא לומר שהפונקציונליות החדשה לא אומרת חריגה מאסטרטגיית ה-3-2-1. נוכחותן של נקודות ארכיון במאגר הראשי אינה משפיעה בשום אופן על מהימנותו. מובן ש-GFS ישמש בשילוב עם מאגר Scale-out כדי להעלות את הנקודות הללו ל-S3 ואחסון דומים. אם אתה לא משתמש בו, אז עדיף להמשיך לאחסן נקודות ראשיות וארכיון במאגרים שונים.

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

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

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

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

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

דוגמה: GFS שבועי מוגדר ליום רביעי, ו-GFS חודשי מוגדר לשבוע האחרון של החודש. המשימה פועלת כל יום ויוצרת גיבויים מלאים בימי שני ושישי.

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

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

עם זאת, אם תכלול רק את המרווחים השבועיים והשנתיים, הם יפעלו ללא תלות זה בזה ויכולים לסמן 2 VBK נפרדים כמרווחי GFS תואמים.

משימות העתקת גיבוי

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

שיטת שמירה פשוטה

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

מספר הנקודות נקבע קצת יותר בכרטיסייה יעד

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

שיטת שמירה באמצעות GFS

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

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

GFS סינתטי

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

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

אז ביום שני, התוספת האחרונה בשרשרת מסומנת כ-GFS, אך לא מתרחשים שינויים גלויים אחרים. כל יום המשימה יוצרת 2 נקודות חדשות, והשמירה מזיזה ללא הרף את השרשרת קדימה. לבסוף, ביום חמישי הגיע הזמן להחיל שמירה על אותה תוספת. הפגישה הזו תימשך זמן רב מהרגיל - מכיוון שהמשימה "תחלץ" את הבלוקים הדרושים מהשרשרת ותיצור נקודה שלמה חדשה. מרגע זה כבר יהיו 8 נקודות בשרשרת - 7 בשרשרת הראשית + ​​GFS.

יצירת נקודות GFS עם אפשרות "קרא את כל הנקודה".

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

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

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

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

ושוב "הסר פריטים שנמחקו"

אפשרות זו קיימת גם עבור BCJ:

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

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

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

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

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

Innovation v.10 – עותק מיידי

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

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

דיסקים מסתובבים. תכונות של מאגרים עם כוננים מסובבים

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

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

בואו נשקול כל אפשרות.

משימה רגילה ומאגר Windows

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

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

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

לאחר מכן אנו מחברים את הכונן השני. עם ההפעלה, B&R ישים לב שהדיסק הוחלף. השרשרת בדיסק הראשון תיעלם מהממשק, אך מידע עליה יישאר במסד הנתונים. כעת המשימה תשמור 3 נקודות בדיסק השני. המצב הכללי יהיה כך:

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

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

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

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

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

הפתרון הוא להוסיף DWORD ForceDeleteBackupFiles כפי שמצוין בדף זה: www.veeam.com/kb1154. לאחר מכן, העבודה תתחיל פשוט למחוק את כל התוכן של תיקיית העבודה או תיקיית המאגר (בהתאם לערך) בכל סיבוב.

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

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

עותק גיבוי ומאגר Windows

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

ראשית, B&R מתחיל ליצור נקודות בדיסק הראשון. נניח שהגדרנו את השמירה ל-3 נקודות. המשימה תעבוד במצב אינקרמנטלי אינסוף ותמזג את כל מה שלא נחוץ (אני מזכיר לך ששמירה על GFS אינה נתמכת במקרה זה).

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

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

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

עותק גיבוי ואחסון רשת במאגר לינוקס

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

מסקנה

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

מקור: www.habr.com