זוהי הפקודה fssync שניתן להפעיל בספק האירוח החינמי של OnWorks באמצעות אחת מתחנות העבודה המקוונות המרובות שלנו, כגון Ubuntu Online, Fedora Online, אמולטור מקוון של Windows או אמולטור מקוון של MAC OS
תָכְנִית:
שֵׁם
fssync - כלי סינכרון של מערכת קבצים (חד כיווני, מעל SSH)
תַקצִיר
fssync -d db -r שורש [אוֹפְּצִיָה...] המארח
תיאור
fssync הוא כלי סנכרון קבצים חד-כיווני שעוקב אחר אינודים ושומר על מקומי
מסד נתונים של קבצים שנמצאים בצד המרוחק, מה שמאפשר לו:
· לטפל ביעילות במספר עצום של dirs/קבצים
· לזהות שמות/תנועות וקישורים קשיחים
מטרתו היא למזער את תעבורת הרשת ולסנכרן כל פרט במערכת קבצים:
· כל סוגי האינודים: קובץ, dir, block/character/fifo, socket, symlink
· לשמר קישורים קשיחים
· זמן שינוי, בעלות/הרשאה/ACL, תכונות מורחבות
· קבצים דלילים
תכונות אחרות:
· ניתן להגדיר אותו כך שלא יכלול קבצים מסנכרון
· ניתן להפסיק את fssync ולחדש אותו בכל עת, מה שהופך אותו לסובלני לכשלים אקראיים
(למשל שגיאת רשת)
· אלגוריתם לסנכרון תוכן קבצים נועד להתמודד עם קבצים גדולים כמו תמונות VM
ביעילות, על ידי עדכון בלוקים ששונו בגודל קבוע במקום
השימוש העיקרי ב-fssync הוא למנוע אובדן נתונים במקרה של כשל חומרה, כאשר RAID1 נמצא
לא אפשרי (למשל במחשבים ניידים).
On Btrfs [1] מערכות קבצים, fssync הוא חלופה שימושית עבור btrfs לשלוח (ו לקבל)
פקודות, הודות ליכולות סינון. ניתן לשלב זאת עם צילום Btrfs
בצד היעד לפתרון גיבוי מלא.
נוהג
השתמש fssync - עזרה כדי לקבל את רשימת האפשרויות המלאה.
הדבר החשוב ביותר לזכור הוא שמסד הנתונים המקומי חייב להתאים בדיוק למה שיש
על מארח היעד:
· אין לשנות קבצים המועתקים על מארח היעד. ושום דבר לא צריך
ליצור באופן ידני בתוך ספריות יעד. אם אתה עדיין רוצה לגשת לנתונים על
מארח מרוחק, עליך לעשות זאת באמצעות חיבור לקריאה בלבד (דורש לינוקס >=
2.6.26).
· אתה חייב להיות בסיס נתונים אחד לכל יעד, אם אתה מתכנן להחזיק מספר עותקים של אותו
ספריית מקור.
להסתכל על -c אפשרות אם אתה תוהה אם מסד הנתונים שלך תואם את ספריית היעד.
הפעלה ראשונה של fssync:
· הדרך הקלה ביותר היא לתת ל-fssync לעשות הכל. ציין נתיב קובץ לא קיים אל -d
אפשרות וספריית יעד ריקה או לא קיימת (ראה -R אוֹפְּצִיָה). fssync יהיה
יוצר אוטומטית את מסד הנתונים ומעתיק את כל ה-dirs/קבצים למארח מרוחק.
· דרך מהירה יותר עשויה להיות לעשות את העותק הראשוני באמצעים אחרים, כמו עותק גולמי של a
חֲלוּקָה. אם אתה בטוח לחלוטין שהמקור והיעד זהים לחלוטין,
אתה יכול לאתחל את מסד הנתונים על ידי ציון - כמארח. אם מספרי האינודה זהים
משני הצדדים, וזה המקרה אם הועתקו נתונים ברמת הבלוק, אתה יכול לשנות את
מחיצת המקור בזמן שאתה מאתחל את ה-DB באחד היעד, וחזור
ה-DB באופן מקומי.
דוגמה של עטיפה סביב fssync, עם מסנן, ניתן למצוא ב examples/fssync_home
fssync אף פעם לא יורד ספריות במערכות קבצים אחרות. אינודות מכוסות על ידי נקודות הרכבה
הם גם מדלגים, אז יש לבטל אותם באופן זמני אם אתה רוצה שהם יהיו
מסונכרן. ניתן להשיג את אותה תוצאה על ידי סנכרון מ-bind mount.
ראה גם אף לא אחד צופן מיתוג [2] תיקון אם אתה לא צריך הצפנה ואתה רוצה
להאיץ את חיבור ה-SSH שלך.
איך IT עבודות
fssync שומר על טבלת SQLite אחת של כל ה-dirs/קבצים שנמצאים בצד המרוחק. כל אחד
שורה תואמת נתיב, עם האינוד שלו (בצד המקומי), מטא נתונים אחרים (בצד המרוחק) ו-
בָּדוּק דגל.
בעת הפעלה, fssync חוזר באופן רקורסיבי דרך כל ה-dirs/קבצים המקומיים ולכל נתיב
שלא מתעלמים מזה (ראה -f אפשרות), הוא שואל את ה-DB להחליט מה לעשות. אם כבר
בָּדוּק, נתיב נדלג מיד. כאשר נתיב מסונכרן, הוא מסומן כ
בָּדוּק. בסוף, כל השורות שלא בָּדוּק מתאים לנתיבים שאינם קיימים
יותר. ברגע שהם נמחקים בצד המרוחק, הכל בָּדוּק הדגלים מאופסים.
כשלון סובלנות
למעשה, fssync אינו מחייב שמסד הנתונים יתאים בצורה מושלמת ליעד. זה
סובל כמה הבדלים כדי לשחזר כל סנכרון מופרע שנגרם על ידי א
כשל ברשת, שגיאת תפעול קבצים או כל דבר אחר מלבד קריסת מערכת הפעלה
של המארח המקומי (או משהו דומה כמו הפסקת חשמל).
ברוב המקרים, זה נעשה על ידי המארח המרוחק, שיוצר (או מחליף) באופן אוטומטי
אינוד מהסוג הצפוי במידת הצורך. היוצא מן הכלל היחיד הוא שהשלט יעשה זאת
לעולם אל תמחק ספרייה לא ריקה בפני עצמה. עבור רוב המקרים המורכבים, fssync מדווחת
הפעולה במסד הנתונים: במקרה של כשל, fssync יוכל להתאושש ב- Next
סינכרון.
גזע תנאים
תנאי גזע פירושו שתהליכים אחרים במארח המקומי משנים את האינודים
fssync מסתנכרן. fssync מטפל בכל סוג של מצב מירוץ. למעשה, ל-fssync יש
אין מה לעשות ברוב המקרים.
כאשר מתרחש מצב מירוץ, fssync אינו מבטיח שהנתונים המרוחקים נמצאים ב-a
מצב עקבי. כל סנכרון תמיד מתקן חוסר עקביות קיימות אך עשוי להציג
אחרים, אז fssync אינו מתאים לגיבוי חם של מסדי נתונים.
עם Btrfs, אתה יכול לקבל עקביות על ידי צילום מצב בצד המקור.
דוֹמֶה פרוייקטים
הרעיון של תחזוקת מסד נתונים מקומי מגיע למעשה csync2 [3]. עמדתי
אמצו את זה כשהבנתי שאני באמת צריך כלי שתמיד מזהה שמות/תנועות של
קבצים גדולים. זו הסיבה שאני רואה ב-fssync שכתוב חלקי של csync2, עם מעקב אינוד ו
ללא סנכרון דו כיווני. מסד הנתונים המקומי באמת מייצר fssync & csync2
מהיר יותר מהידוע rsync [4].
השתמש ב-fssync באופן מקוון באמצעות שירותי onworks.net
