rsync דרך VPN: איזה צד הוא מקור האמת?

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

החליטו איזה עותק מנצח לפני שאתם מקלידים פקודה

כתבו את הכיוון במשפט אחד, כולל שם המארח והנתיב בכל צד, וקבלו אישור ממי שהנתונים שלו. במדריך הזה המקור הוא /srv/publish/ והיעד הוא חשבון על fileserver.example שרשאי לכתוב רק ב-/srv/mirror/.

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

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

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

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

אחר כך החליטו אם מחיקות נוסעות

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

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

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

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

שני משימות חד-כיווניות לא יוצרות סנכרון דו-כיווני

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

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

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

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

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

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