גיבוי חלק 3: סקירה ובדיקה של כפילות, כפילות

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

בין העומדים בדרישות ניתן למנות duplicity (שיש לו ממשק נחמד בצורת deja dup) ו-duplicati.

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

תוצאות צפויות

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

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

התנהגות בעת יצירת גיבויים:

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

הבה נריץ את הפקודה הבאה כערך ייחוס:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

תוצאות הביצוע היו כדלקמן:

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

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

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

התוצאות הן:

זמן ביצוע 10 מ'11 שניות. סביר להניח שצוואר הבקבוק הוא המדחס עם זרימה אחת בקצה המקבל.

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

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

זה יצא כך:

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

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

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

התוצאות יצאו כך:

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

UPD: לבקשת bliznezz אני מוסיף בדיקות עם pigz. אם אתה משתמש רק במדחס, זה ייקח 6m30s, אם תוסיף גם הצפנה, זה יהיה בערך 7m. השפל בגרף התחתון הוא מטמון דיסק לא מסולק:

בדיקה כפולה

Duplicity היא תוכנת פיתון לגיבוי על ידי יצירת ארכיונים מוצפנים בפורמט tar.

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

ניתן להצפין ולחתום גיבויים באמצעות gnupg, דבר שחשוב בעת שימוש בספקים שונים לאחסון גיבויים (s3, backblaze, gdrive וכו')

בוא נראה מה התוצאות:

אלו הן התוצאות שקיבלנו בעת ריצה ללא הצפנה

ספוילר

זמן ריצה של כל ריצת מבחן:

השקה 1
השקה 2
השקה 3

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

והנה התוצאות כאשר הצפנת gnupg מופעלת, עם גודל מפתח של 2048 סיביות:

זמן פעולה על אותם נתונים, עם הצפנה:

השקה 1
השקה 2
השקה 3

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

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

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

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

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

בדיקה כפולה

תוכנה זו כתובה ב-C# ופועלת באמצעות סט ספריות מ-Mono. יש GUI וגם גרסת CLI.

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

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

בואו נראה אילו אינדיקטורים הפתרון הזה יכול לייצר:

אם אתה מכבה את ההצפנה (ו-WEBGUI לא ממליץ לעשות זאת), התוצאות הן כדלקמן:

שעות:

השקה 1
השקה 2
השקה 3

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

כשההצפנה מופעלת, באמצעות aes, זה נראה כך:

שעות:

השקה 1
השקה 2
השקה 3

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

ואם אתה משתמש בתוכנה החיצונית gnupg, התוצאות הבאות יוצאות:

השקה 1
השקה 2
השקה 3

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

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

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

בסך הכל, רשמים חיוביים למדי מהתוכנית, כולל היותו ידידותי למדי למתחילים.

ממצאים

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

ממצאים

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

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

הכרזה

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

פורסם על ידי: פאבל דמקוביץ'

מקור: www.habr.com