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 بیشتر از هر نرخ اوجی که در آزمون کوتاهی اندازه‌گیری شده باشد به شما می‌گوید.