גיבוי חלק 6: השוואת כלי גיבוי

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

שחזור נתונים

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

rsync התמודד עם ערכת הבדיקה תוך 4 דקות ו-28 שניות, מראה

עומס כזה

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

זפת עשה את זה קצת יותר מהר

2 דקות ו-43 שניות:

עומס המערכת הכולל היה גבוה יותר בממוצע ב-20% בגלל ה-softirq המוגבר - עלויות התקורה במהלך פעולת תת-המערכת ברשת גדלו.

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

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

В גיבוי rdiff אתה יכול לסנכרן את הגיבוי האחרון שביצעת באמצעות rsync רגיל (התוצאות יהיו דומות), אך עדיין יש לשחזר גיבויים ישנים באמצעות תוכנית הגיבוי rdiff, שהשלימה את השחזור תוך 17 דקות ו-17 שניות, מראה

העומס הזה:

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

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

לְגַהֵק השלמתי את המשימה של שחזור גיבוי תוך 7 דקות ו-2 שניות עם
עם העומס הזה:

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

התוכנית הראתה בערך את אותה מהירות ועומס גיבוי PC בעת הפעלת מצב העברת rsync, פריסת הגיבוי עבור

7 דקות ו-42 שניות:

אבל במצב העברת נתונים, BackupPC התמודד עם זפת לאט יותר: תוך 12 דקות ו-15 שניות, עומס המעבד היה נמוך יותר בדרך כלל

פעם וחצי:

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

ללא הצפנה

עם הצפנה

לְשַׁכְפֵּל הראה שיעור התאוששות דומה, והשלים אותו תוך 13 דקות ו-45 שניות. נדרשו כ-5 דקות נוספות לבדוק את נכונות הנתונים המשוחזרים (בסך הכל כ-19 דקות). העומס היה

גבוה למדי:

כאשר הצפנת aes הופעלה באופן פנימי, זמן ההתאוששות היה 21 דקות ו-40 שניות, עם ניצול ה-CPU במקסימום (שתי הליבות!) במהלך השחזור; בעת בדיקת נתונים, רק חוט אחד היה פעיל, תופס ליבת מעבד אחת. בדיקת הנתונים לאחר השחזור ארכה אותן 5 דקות (כמעט 27 דקות בסך הכל).

תוצאה

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

כזה:

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

אותו הדבר:

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

הצפנה, דחיסת lzma

זמן ריצה 11 דקות ו-8 שניות

הצפנת AES, דחיסת lzma

זמן עבודה 14 דקות

הצפנת AES, דחיסת lzo

זמן ריצה 6 דקות, 19 שניות

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

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

הַבָּא:

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

ככה:

הצפנת AES מעט איטית יותר, זמן ההתאוששות הוא 3 דקות 23 שניות, העומס הוא במיוחד

לא השתנה:

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

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

לכן you

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

עם urBackup ניתן היה לשחזר את הנתונים תוך 8 דקות ו-19 שניות, העומס היה

כזה:

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

בחירה והצדקה של קריטריונים להשוואה

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

• קלות שימוש
• צדדיות
• יציבות
• מְהִירוּת

כדאי לשקול כל נקודה בנפרד ביתר פירוט.

קלות תפעול

זה הכי טוב כשיש כפתור אחד "עשה הכל טוב", אבל אם תחזור לתוכניות אמיתיות, הדבר הנוח ביותר יהיה איזה עקרון הפעלה מוכר וסטנדרטי.
סביר להניח שמצבם של רוב המשתמשים יהיה טוב יותר אם הם לא יצטרכו לזכור חבורה של מפתחות עבור cli, להגדיר חבורה של אפשרויות שונות, לעתים קרובות לא ברורות, דרך האינטרנט או tui, או להגדיר התראות על פעולה לא מוצלחת. זה כולל גם את היכולת "להתאים" בקלות פתרון גיבוי לתשתית הקיימת, כמו גם אוטומציה של תהליך הגיבוי. ישנה גם אפשרות להתקנה באמצעות מנהל חבילות, או בפקודה אחת או שתיים כמו "הורדה והורדה". curl ссылка | sudo bash - שיטה מורכבת, שכן צריך לבדוק מה מגיע דרך הקישור.

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

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

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

צדדיות

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

כסימן - יכולת עבודה באמצעות ssh רגיל.

מהירות עבודה

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

יציבות

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

השוואה בין כלי גיבוי

העתק זמן יצירת
העתק את זמן ההתאוששות
התקנה קלה
התקנה קלה
שימוש פשוט
אוטומציה פשוטה
האם אתה צריך שרת לקוח?
בדיקת תקינות המאגר
עותקים דיפרנציאליים
עבודה באמצעות צינור
צדדיות
עצמאות
שקיפות מאגר
Шифрование
דחיסה
מניעת כפילות
ממשק אינטרנט
מתמלא עד הענן
תמיכה ב-Windows
ציון

rsync
4m15s
4m28s
כן
לא
לא
לא
כן
לא
לא
כן
לא
כן
כן
לא
לא
לא
לא
לא
כן
6

זפת
טהור
3m12s
2m43s
כן
לא
לא
לא
לא
לא
כן
כן
לא
כן
לא
לא
לא
לא
לא
לא
כן
8,5

מופעלת דחיסת
9m37s
3m19s
כן

Rdiff-גיבוי
16m26s
17m17s
כן
כן
כן
כן
כן
לא
כן
לא
כן
לא
כן
לא
כן
כן
כן
לא
כן
11

תמונת מצב
4m19s
4m28s
כן
כן
כן
כן
לא
לא
כן
לא
כן
לא
כן
לא
לא
כן
כן
לא
כן
12,5

לְגַהֵק
11m9s
7m2s
כן
לא
כן
כן
כן
כן
כן
לא
כן
כן
לא
לא
כן
לא
כן
לא
כן
10,5

צביעות
ללא הצפנה
16m48s
10m58s
כן
כן
לא
כן
לא
כן
כן
לא
לא
כן
לא
כן
כן
לא
כן
לא
כן
11

Gpg
17m27s
15m3s

לְשַׁכְפֵּל
ללא הצפנה
20m28s
13m45s
לא
כן
לא
לא
לא
כן
כן
לא
לא
כן
לא
כן
כן
כן
כן
כן
כן
11

AES
29m41s
21m40s

Gpg
26m19s
16m30s

zbackup
ללא הצפנה
40m3s
11m8s
כן
כן
לא
לא
לא
כן
כן
כן
לא
כן
לא
כן
כן
כן
לא
לא
לא
10

AES
42m0s
14m1s

aes+lzo
18m9s
6m19s

BorgBackup
ללא הצפנה
4m7s
2m45s
כן
כן
כן
כן
כן
כן
כן
כן
כן
כן
לא
כן
כן
כן
כן
לא
כן
16

AES
4m58s
3m23s

blake2
4m39s
3m19s

קשור
5m38s
4m28s
כן
כן
כן
כן
לא
כן
כן
כן
כן
כן
לא
כן
לא
כן
לא
כן
כן
15,5

urBackup
8m21s
8m19s
כן
כן
כן
לא
כן
לא
כן
לא
כן
כן
לא
כן
כן
כן
כן
לא
כן
12

אמנדה
9m3s
2m49s
כן
לא
לא
כן
כן
כן
כן
לא
כן
כן
כן
כן
כן
לא
כן
כן
כן
13

גיבוי PC
rsync
12m22s
7m42s
כן
לא
כן
כן
כן
כן
כן
לא
כן
לא
לא
כן
כן
לא
כן
לא
כן
10,5

זפת
12m34s
12m15s

אגדת טבלה:

• ירוק, זמן פעולה פחות מחמש דקות, או תשובה "כן" (חוץ מהעמודה "צריך שרת לקוח?"), נקודה אחת
• צהוב, זמן פעולה חמש עד עשר דקות, 0.5 נקודות
• אדום, זמן העבודה הוא יותר מעשר דקות, או שהתשובה היא "לא" (חוץ מהעמודה "צריך שרת לקוח?"), 0 נקודות

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

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

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

הכרזה

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

מקור: www.habr.com