גיבוי חלק 4: סקירה ובדיקה של zbackup, restic, borgbackup

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

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

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

ישנם מספר פתרונות דומים, אני אתמקד ב-3: zbackup, borgbackup ו-restic.

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

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

רצוי מאוד גם להיות מסוגל ליצור עותקי גיבוי של קבצים ישירות, מבלי להשתמש בארכיונים כמו tar, כמו גם לעבוד עם ssh/sftp ללא כלים נוספים כמו rsync ו-sshfs.

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

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

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

בדיקת zbackup

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

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

lzma ו-lzo מרובי הליכי משמשים לדחיסה, ו-aes להצפנה. לגרסאות האחרונות יש את היכולת למחוק נתונים ישנים מהמאגר בעתיד.
התוכנית כתובה ב-C++ עם תלות מינימלית. המחבר קיבל כנראה השראה מה-unix-way, כך שהתוכנה מקבלת נתונים על stdin בעת יצירת גיבויים, מייצרת זרם נתונים דומה על stdout בעת שחזור. לפיכך, zbackup יכול לשמש כ"אבן בניין" טוב מאוד בעת כתיבת פתרונות גיבוי משלך. לדוגמה, מחבר המאמר השתמש בתוכנית זו ככלי הגיבוי העיקרי למכונות ביתיות מאז 2014 בערך.

זרם הנתונים יהיה זפת רגיל אלא אם צוין אחרת.

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

העבודה נבדקה ב-2 אפשרויות:

1. נוצר מאגר ו-zbackup מופעל בשרת עם נתוני המקור, ואז התוכן של המאגר מועבר לשרת אחסון הגיבוי.
2. נוצר מאגר בשרת אחסון הגיבוי, zbackup מופעל באמצעות ssh בשרת אחסון הגיבוי, ונתונים נשלחים אליו באמצעות pipe.

התוצאות של האפשרות הראשונה היו כדלקמן: 43m11s - בעת שימוש במאגר לא מוצפן ובמדחס lzma, 19m13s - בעת החלפת המדחס ב-lzo.

העומס על השרת עם הנתונים המקוריים היה כדלקמן (מוצגת דוגמה עם lzma; עם lzo הייתה בערך אותה תמונה, אבל החלק של rsync היה בערך רבע מהזמן):

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

יותר מעניינת וישימה בפועל היא האפשרות השנייה, הפעלת zbackup ישירות על שרת אחסון הגיבוי.

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

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

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

39m45s
40m20s
40m3s

7m36s
8m3s
7m48s

15m35s
15m48s
15m38s

אם תאפשר הצפנה באמצעות aes, התוצאות די קרובות:

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

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

43m40s
44m12s
44m3s

8m3s
8m15s
8m12s

15m0s
15m40s
15m25s

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

שעות:

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

18m2s
18m15s
18m12s

5m13s
5m24s
5m20s

8m48s
9m3s
8m51s

גודל המאגר שהתקבל היה זהה יחסית ב-13GB. המשמעות היא שמניעת כפילויות פועלת כהלכה. כמו כן, על נתונים שכבר דחוסים, השימוש ב-lzo נותן השפעה ניכרת; במונחים של זמן פעולה כולל, zbackup מתקרב לכפולות/כפילויות, אך מפגר פי 2-5 אחרי אלה המבוססים על librsync.

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

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

בודק borgbackup

Borgbackup הוא מזלג של עליית גג, מערכת נוספת הדומה ל-zbackup. כתוב ב-python, יש לו רשימה של יכולות דומות ל-zbackup, אבל בנוסף יכול:

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

בדיקות ביצועים

borgbackup benchmark crud ssh://backup_server/repo/path local_dir

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

CZ-BIG 96.51 MB/s (10 100.00 MB קבצים לגמרי אפס: 10.36 שניות)
RZ-BIG 57.22 MB/s (10 100.00 MB קבצים לגמרי אפס: 17.48 שניות)
UZ-BIG 253.63 MB/s (10 100.00 MB קבצים לגמרי אפס: 3.94 שניות)
DZ-BIG 351.06 MB/s (10 100.00 MB קבצים לגמרי אפס: 2.85 שניות)
CR-BIG 34.30 MB/s (10 100.00 MB קבצים אקראיים: 29.15 שניות)
RR-BIG 60.69 MB/s (10 100.00 MB קבצים אקראיים: 16.48 שניות)
UR-BIG 311.06 MB/s (10 100.00 MB קבצים אקראיים: 3.21 שניות)
DR-BIG 72.63 MB/s (10 100.00 MB קבצים אקראיים: 13.77 שניות)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB קבצים לגמרי אפס: 9.21 שניות)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB קבצים לגמרי אפס: 13.13 שניות)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB קבצים לגמרי אפס: 3.02 שניות)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB קבצים לגמרי אפס: 2.58 שניות)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB קבצים אקראיים: 26.45 שניות)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB קבצים אקראיים: 14.51 שניות)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB קבצים אקראיים: 2.88 שניות)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB קבצים אקראיים: 20.49 שניות)
CZ-SMALL 11.72 MB/s (10000 10.00 קילובייט קבצים לגמרי אפס: 8.53 שניות)
RZ-SMALL 32.57 MB/s (10000 10.00 קילובייט קבצים לגמרי אפס: 3.07 שניות)
UZ-SMALL 19.37 MB/s (10000 10.00 קילובייט קבצים לגמרי אפס: 5.16 שניות)
DZ-SMALL 33.71 MB/s (10000 10.00 קילובייט קבצים לגמרי אפס: 2.97 שניות)
CR-SMALL 6.85 MB/s (10000 10.00 KB קבצים אקראיים: 14.60 שניות)
RR-SMALL 31.27 MB/s (10000 10.00 KB קבצים אקראיים: 3.20 שניות)
UR-SMALL 12.28 MB/s (10000 10.00 KB קבצים אקראיים: 8.14 שניות)
DR-SMALL 18.78 MB/s (10000 10.00 KB קבצים אקראיים: 5.32 שניות)

בעת הבדיקה, יוריסטיקה של דחיסה תשמש לקביעת סוג הקובץ (דחיסה אוטומטית), והתוצאות יהיו כדלקמן:

ראשית, בואו נבדוק איך זה עובד ללא הצפנה:

שעות:

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

4m6s
4m10s
4m5s

56s
58s
54s

1m26s
1m34s
1m30s

אם תפעיל הרשאת מאגר (מצב אימות), התוצאות יהיו סגורות:

שעות:

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

4m11s
4m20s
4m12s

1m0s
1m3s
1m2s

1m30s
1m34s
1m31s

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

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

4m55s
5m2s
4m58s

1m0s
1m2s
1m0s

1m49s
1m50s
1m50s

ואם תשנה את ה-aes ל-Blak, המצב ישתפר לחלוטין:

שעות:

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

4m33s
4m43s
4m40s

59s
1m0s
1m0s

1m38s
1m43s
1m40s

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

לא היו חסרונות מיוחדים בעת השימוש בו.

בדיקה רסטית

למרות העובדה ש-restic הוא פתרון חדש למדי (2 המועמדים הראשונים היו ידועים ב-2013 ומעלה), יש לו מאפיינים טובים למדי. נכתב בגו.

בהשוואה ל-zbackup, הוא נותן בנוסף:

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

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

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

שעות:

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

5m25s
5m50s
5m38s

35s
38s
36s

1m54s
2m2s
1m58s

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

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

ממצאים

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

ממצאים

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

Borgbackup בעצם לא יותר גרוע, אבל zbackup כנראה עדיף להחליף. נכון, עדיין ניתן להשתמש ב-zbackup כדי להבטיח שכלל 3-2-1 עובד. לדוגמה, בנוסף למתקני גיבוי מבוססי (lib)rsync.

הכרזה

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

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

מקור: www.habr.com