גיבוי נתונים באמצעות FreeFileSync ו-7-zip

אנמנזה, כביכול:

שרת Fujitsu rx300 s6, RAID6 של 6 דיסקים של 1TB, XenServer 6.2 מותקן, מספר שרתים מסתובבים, ביניהם אובונטו עם מספר כדורים, 3,5 מיליון קבצים, 1,5 TB של נתונים, כל זה גדל ומתנפח בהדרגה.

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

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

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

אנו זורקים קבצים זמניים לחריגות מסיכה: *.dwl, *.dwl2, *.tmp.

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

הארכיון יתבצע בשרת גיבוי מקומי, במקום זה ששימש בעבר TheCopier עם ארכיון רשת. אגב, TheCopier מעולה! אבל עם נפחים כאלה, פשוט אין לו זמן להעביר הכל, למרות ממשק 1Gbps בגיבוי ו-2Gbps בקובץ הראשון (קשר של שני כרטיסי רשת).

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

כדי לאחסן את התיקיות הדרושות, אנו כותבים קובץ אצווה עבור 7-zip:

הגדר עכשיו=%TIME:~0,-3%
set now=%now::=.%
הגדר עכשיו=%עכשיו: =0%
set now=%DATE:~-4%.%DATE:~3,2%.%DATE:~0,2%_%now%
C:"Program Files"7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_10-04.zip E:10-04
C:"Program Files"7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_35-110.zip E:35-110
C:"Program Files"7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_asu.zip E:asu
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_director.zip E:director
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_gpr.zip E:gpr
C:"Program Files"7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_otiz.zip E:otiz
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_ps.zip E:ps
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_pto.zip E:pto
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_rza.zip E:rza
C:“Program Files”7-Zip7z.exe a -tzip -mx=1 -mmt=on -mtc=off -ssw D:backupsAll%now%_smeta.zip E:smeta

::a - יצירת ארכיון
:: -tzip או -t7z - סוג ארכיון (ה-zip מהיר פי 1.5-2)
:: -mx=1 — יחס דחיסה (מינימום 1, 9 ערכים מקסימליים x=[0 | 1 | 3 | 5 | 7 | 9 ])
:: -mmt=on - מאפשר ריבוי השרשורים היכן שהוא אינו מופעל
:: -mtc=off - משבית חותמות זמן של מערכת הקבצים (כאשר נשמר, שונה וכו')
:: -ssw - גם דוחס קבצים שנפתחו לכתיבה
:: -xr!.Sync* - לא כולל קבצי BtSync זמניים מהארכיון, ומשאיר קבצי BtSync קבועים

הבנייה של set now=% וכן הלאה מאפשרת לשמור את פורמט זמן ההקלטה בשם קובץ ללא הבעיות שנוצרו כאשר מספר היום או החודש היה פחות מ-10, כלומר, אנו מחליפים אפס.

הערה -xr!.Sync* היא יסוד שנותר מהשימוש המקורי BTSync.

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

למרות שהארכיון הוא 7-zip, אנו מאחסנים אותו בפורמט zip במקום ה-7z המקורי, מכיוון שהוא הרבה יותר מהיר, ואין כמעט הבדל בדחיסה עם mx=1, זה אומת על ידי ניסויים רבים.

ארכיונים מבוצעים אחד אחד.

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

מקור: www.habr.com