Capacity Tier (או כפי שאנו קוראים לזה בתוך Vim - captir) הופיע עוד בימי Veeam Backup and Replication 9.5 Update 4 תחת השם Archive Tier. הרעיון מאחוריו הוא לאפשר להעביר גיבויים שנפלו מחלון השחזור המבצעי לאחסון אובייקטים. זה עזר לפנות שטח דיסק עבור אותם משתמשים שהיה להם מעט ממנו. ואפשרות זו נקראה Move Mode.

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

אבל ב-VBR v10, הקונספט הושלם עם פונקציות חדשות - Copy Mode, Sealed Mode ודבר עם השם הקשה להגייה Immutability הופיע.

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

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

• בלי שמץ של חרטה. מחבר המאמר.

כמו שזה היה

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

כפי שאנו רואים בתמונה, יש לנו מעין שרשרת גיבוי עם בלוקים של נתונים, אשר ממוקמת ב-Performance tier SOBR של המאגר אליו מחוברת ה-Capacity Tier. חלון הגיבוי התפעולי שלנו הוא שלושה ימים.

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

אבל למה בדיוק הייתה הכוונה בשרשרת אטומה ומה אפשר לשלוח לטווח הירי בקיבולת בעדכון 4?

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

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

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

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

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

בוא נראה איך זה נראה עם דוגמה: נניח שיש לנו .vbk שיצא מחלון העסקאות ושייך לשרשרת אטומה. זה אומר שיש לנו את כל הזכות להעביר אותו לטווח הירי הקיבולת. בזמן המעבר, נוצר קובץ מטא נתונים במקף הקיבולת והבלוקים של הקובץ המועבר. קובץ המטא נתונים ברמת הקישור מתאר מאילו בלוקים מורכב הקובץ שלנו. במקרה שבתמונה, הקובץ הראשון שלנו מורכב מבלוקים a,b,c והמטא נתונים מכילים קישורים לבלוקים אלו. כאשר יש לנו קובץ .vbk שני, מוכן להזזה ומורכב מבלוקים a, b ו-d, אנו, בניתוח אינדקס ההתייבשות, מבינים שצריך להעביר רק את בלוק d. וקובץ המטא נתונים שלו יכיל קישורים לשני בלוקים קודמים ואחד חדש.

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

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

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

איך זה הפך להיות

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

מצב העתקה

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

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

אם אתה משווה את מצבי ההעברה וההעתקה חזיתית, זה ייראה כך:

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

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

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

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

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

בוא נעשה את זה נכון.

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

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

למה אנחנו צריכים את מצב העתקה הזה?

עדיף אפילו לנסח מחדש את השאלה כך: מאילו סיכונים אנו מוגנים בעזרתה? איזו בעיה זה עוזר לנו לפתור?

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

אז בואו נעבור על התרחישים האפשריים, מהפשוטים למורכבים יותר.

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

סיפור עצוב יותר הוא שאחת ההיקפים של מאגר ה-SOBR שלנו נשברה.

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

עכשיו בואו נסתכל על כל מצב בנפרד.

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

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

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

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

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

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

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

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

מצב אטום

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

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

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

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

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

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

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

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

הדברים מסובכים יותר עם טווח הירי הקיבולת.

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

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

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

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

זה בעצם כל מה שיש בזה. אז בואו נעבור לתכונה ההארדקורית ביותר -

חוסר יכולת

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

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

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

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

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

הבה ניקח סולם זמן של שישה ימים ומטה נסמן את שעת פקיעת הבלתי משתנה הצפויה. ביום הראשון אנחנו לוקחים ויוצרים קובץ המורכב מבלוק נתונים a והמטא נתונים שלו. אם אי-השינוי מוגדר לשלושה ימים, הגיוני להניח שביום הרביעי הנתונים יבוטלו וימחקו. ביום השני נוסיף קובץ2 חדש, המורכב מבלוק b עם אותן הגדרות. עדיין צריך להסיר את הבלוק a ביום הרביעי. אבל ביום השלישי קורה משהו נורא - נוצר קובץ File3, המורכב מבלוק d חדש וקישור לבלוק א' הישן. משמעות הדבר היא שעבור בלוק והדגל הבלתי משתנה שלו יש לאפס לתאריך חדש, המוזז ליום השישי. וכאן נוצרת בעיה - בגיבויים אמיתיים יש מספר עצום של בלוקים כאלה. וכדי להאריך את תקופת הבלתי משתנה שלהם, אתה צריך להגיש מספר עצום של בקשות בכל פעם. ולמעשה, זה יהיה תהליך יומיומי כמעט אינסופי, שכן עם רמה גבוהה של הסתברות נמצא ערימות כבדות של בלוקים משוכפלים בכל עותק. מה המשמעות של מספר רב של בקשות מספקי אחסון אובייקטים? ימין! חשבון ענק בסוף החודש.

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

בואו נמשיך לשקול את אותו המצב, אבל עם יצירת בלוק. ביום הראשון אנו יוצרים קובץ1 מבלוק a ומטא נתונים. נחבר את תקופת הדור ואי-השינוי - זה אומר שההזדמנות למחוק את הקובץ תהיה ביום השישי. אם ביום השני ניצור את File2, המורכב מבלוק b וקישור לחסימה a, אז שום דבר לא קורה לתאריך המחיקה הצפוי. היא עמדה כפי שעמדה ביום השישי. ובכך אנו מנסים לחסוך כסף במספר הבקשות. המצב היחיד שבו ניתן להזיז את המועד הוא אם פג תקופת הייצור. כלומר, אם ביום השלישי ה-File3 החדש מכיל קישור לחסימת a, אז דור 2 יתווסף מכיוון ש-Gen1 כבר פג. והתאריך הצפוי למחיקת בלוק a יעבור ליום השמיני. זה מאפשר לנו לצמצם באופן דרמטי את מספר הבקשות להארכת החיים של בלוקים נטולי כפילות, מה שחוסך ללקוחות המון כסף.

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

וכרגיל, כמה קישורים שימושיים:

• על דור בלוק בכל פרט.
• כל המידע על גיבוי ושכפול של Veeam 10 במיטבו
• О דרגת קיבולת בפירוט

מקור: www.habr.com