rsync דרך VPN: ניסיון חוזר שמשתמש מחדש בהעברה השבורה

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

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

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

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

החליטו היכן חי הקטע הניתן לשימוש חוזר

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

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

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

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

הריצו את אותו עותק, לא כזה חכם יותר

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

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

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

קבלו את האובייקט רק לאחר שהוא תואם

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

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

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

כשהקישור, ולא הדגל, הוא הגבול

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

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