rclone ابزار انتقال و مدیریت فایل میان فضای محلی و سرویس‌های ذخیره‌سازی است. سه فرمان copy، sync و check می‌توانند در یک گردش کار کنار هم قرار بگیرند، اما هدف یکسانی ندارند. تفاوت آن‌ها زمانی مهم می‌شود که مقصد از قبل داده دارد، مبدأ ناقص است یا باید امکان بازگشت به نسخه قبلی حفظ شود. این راهنما رفتار فرمان‌ها را با طراحی یک فرایند قابل بررسی ترکیب می‌کند. نام remote و مسیرها در مثال‌ها فرضی‌اند؛ فرمانی روی داده واقعی اجرا نشده و خروجی موفقیت‌آمیزی نیز ادعا نمی‌شود.
ابتدا مشخص کنید کدام طرف مرجع است
پیش از انتخاب فرمان، یک جمله روشن بنویسید: «این مسیر مبدأ، مرجع این مجموعه داده است و این مسیر مقصد باید چه رابطه‌ای با آن داشته باشد؟» اگر پاسخ این است که مقصد نسخه‌ای مطابق وضعیت فعلی مبدأ باشد، sync می‌تواند مناسب باشد. اگر فایل‌های تازه و تغییرکرده باید منتقل شوند ولی فایل‌های اضافی مقصد باقی بمانند، copy به هدف نزدیک‌تر است. اگر فقط می‌خواهید اختلاف را بشناسید، check نقطه شروع مناسب‌تری است.
این تصمیم را از نام پوشه‌ها حدس نزنید. پوشه‌ای به نام backup ممکن است تنها نسخه موجود بعضی فایل‌ها را نگه دارد. برعکس، مسیری به نام archive ممکن است در عمل یک آینه موقتی باشد. معیار، سیاست نگه‌داری و مالکیت داده است. پیش از خودکارسازی، مسئول هر دو طرف و انتظار درباره حذف را مشخص کنید. بسیاری از خطاهای انتقال از اشتباه در جهت فرمان ناشی می‌شوند، نه از خرابی شبکه یا نقص ابزار.
copy چه کاری انجام می‌دهد؟
طبق مستندات رسمی، copy محتوا را از مبدأ به مقصد می‌برد، فایل‌های یکسان را دوباره منتقل نمی‌کند و فایل‌های اضافی مقصد را به‌دلیل نبودن در مبدأ حذف نمی‌کند. بااین‌حال، «حذف‌نکردن» به معنای «تغییرندادن فایل موجود» نیست. اگر فایل متناظر متفاوت باشد، انتقال می‌تواند نسخه مقصد را جایگزین کند. بنابراین copy نیز بدون سیاست نسخه‌بندی، تاریخچه همه تغییرات را حفظ نمی‌کند.
نکته دیگر، معنای مسیر پوشه است. rclone محتوای پوشه مبدأ را داخل مسیر مقصد قرار می‌دهد؛ نباید فرض کرد نام پوشه مبدأ حتماً یک لایه تازه در مقصد می‌سازد. برای انتقال یک فایل با نام مقصد مشخص نیز copyto فرمان جداگانه‌ای دارد. یک آزمایش کوچک با دو فایل و یک زیرپوشه کمک می‌کند ساختار مورد انتظار را پیش از انتقال اصلی ببینید.
برای نمونه آموزشی، می‌توان طرح انتقال را بدون اعمال تغییر دید:
rclone copy /srv/example-source remote:example/current --dry-run -v
در این مثال، remote باید قبلاً به یک backend مشخص اشاره کند. نام آن به‌خودی‌خود درباره محل واقعی داده چیزی نمی‌گوید؛ پیکربندی و مسیر مقصد باید مستقل بررسی شوند.
sync یک‌طرفه است و می‌تواند حذف کند
فرمان sync مقصد را با مبدأ هماهنگ می‌کند و تغییرات را در مقصد اعمال می‌کند. اگر فایل در محدوده عملیاتِ مقصد وجود داشته باشد اما در مبدأ نباشد، ممکن است حذف شود. این رفتار برای ساخت آینه مفید است، اما با ادغام دو مجموعه مستقل تفاوت دارد. اجرای sync در جهت معکوس، «تکمیل همگام‌سازی» نیست؛ می‌تواند معنای مرجع را برعکس کند.
مستندات توصیه می‌کند پیش از اجرای واقعی از dry-run یا حالت تعاملی استفاده شود. همچنین رفتار پیش‌فرض درباره خطاهای عملیات و حذف را توضیح می‌دهد. این محافظت‌ها مجوزی برای بی‌دقتی در انتخاب مسیر نیستند. ابزار نمی‌داند پوشه خالی مبدأ نتیجه یک mount ناموفق است یا حذف عمدی داده. اگر مسیر از نظر سیستم معتبر ولی از نظر کاری اشتباه باشد، سیاست همگام‌سازی می‌تواند همان وضعیت اشتباه را درست اجرا کند.
نمونه‌ای برای مشاهده برنامه تغییرات:
rclone sync /srv/example-source remote:example/current --dry-run -v
قبل از حذف dry-run، فهرست حذف‌ها را با انتظار کاری تطبیق دهید. سؤال فقط این نیست که فرمان خطا داده یا نه؛ باید بدانید چرا هر گروه از فایل‌ها قرار است منتقل، جایگزین یا حذف شود.
یک سناریوی کوچک، تفاوت را روشن می‌کند
فرض کنید مبدأ دو فایل report و photo دارد. مقصد علاوه بر این دو، فایل notes را نیز نگه می‌دارد. اگر notes فقط در مقصد ساخته شده باشد، copy معمولاً آن را باقی می‌گذارد، در حالی که sync برای نزدیک‌کردن مقصد به مبدأ می‌تواند آن را حذف کند. اگر report در مبدأ تغییر کرده باشد، هر دو فرمان ممکن است آن را در مقصد به‌روز کنند. این مثال نشان می‌دهد تفاوت اصلی فقط «انتقال‌دادن یا ندادن» نیست؛ سیاست برخورد با داده اضافی مقصد تعیین‌کننده است.
اکنون فرض کنید مبدأ به دلیل خطای آماده‌سازی فقط نیمی از فایل‌های مورد انتظار را دارد. اجرای دقیق sync روی چنین ورودی‌ای ممکن است نتیجه نادرست کاری بسازد. راه‌حل، افزودن بررسی پیش‌شرط است: وجود مسیر کافی نیست؛ کامل‌بودن مجموعه نیز باید با معیار مناسب سنجیده شود. تعداد تقریبی فایل، وجود یک فایل نشانگر یا تکمیل موفق مرحله تولید داده می‌تواند نشانه باشد. معیار باید با کار واقعی هماهنگ شود و نباید صرفاً یک عدد ثابت بدون توضیح باشد.
dry-run را به بازبینی واقعی تبدیل کنید
dry-run امکان مشاهده عملیات پیشنهادی را فراهم می‌کند، اما کیفیت بازبینی به روش شما بستگی دارد. اگر هزاران خط گزارش را بدون خلاصه یا نمونه‌گیری ببینید، تغییر غیرمنتظره ممکن است گم شود. تعداد و حجم انتقال، مسیرهای حذف و فایل‌های جایگزین‌شونده را جدا بررسی کنید. برای نخستین اجرا، محدوده کوچکی انتخاب کنید که بتوانید محتوایش را دستی بشناسید.
میان آزمایش و اجرای واقعی فاصله طولانی نگذارید. اگر مبدأ در این فاصله تغییر کند، dry-run تصویری از وضعیت قدیمی خواهد بود. برای مجموعه‌ای حساس، بهتر است از خروجی تثبیت‌شده یک فرایند یا snapshot مناسب استفاده شود. این توصیه درباره سازگاری ورودی است و ربطی به قابلیت خاص یک backend ندارد. ابزار انتقال نمی‌تواند به‌تنهایی تضمین کند فایل‌هایی که هم‌زمان تغییر می‌کنند، نماینده یک لحظه مشترک از برنامه‌اند.
روش مقایسه فایل‌ها را بشناسید
rclone بسته به فرمان، گزینه‌ها و قابلیت backend از اندازه، زمان تغییر یا hash برای تشخیص یکسانی استفاده می‌کند. این ویژگی‌ها معنای یکسانی ندارند. اندازه برابر، برابری محتوا را ثابت نمی‌کند. زمان تغییر نیز ممکن است دقت متفاوت داشته باشد یا هنگام انتقال حفظ نشود. hash می‌تواند بررسی قوی‌تری فراهم کند، اما باید دید دو طرف چه الگوریتم و چه اطلاعاتی ارائه می‌کنند.
جدول رسمی قابلیت backendها برای همین بررسی مفید است. همه سرویس‌ها قابلیت یکسانی در hash، زمان تغییر، تغییر نام یا عملیات سمت سرور ندارند. بنابراین تجربه موفق میان دو پوشه محلی، تمام رفتار انتقال به یک سرویس ابری را پیش‌بینی نمی‌کند. پیش از انتخاب گزینه‌ای مانند checksum، قابلیت واقعی دو طرف را بررسی کنید و هزینه گرفتن اطلاعات را نیز در نظر بگیرید.
از نظر طراحی، روش مقایسه باید متناسب با ارزش داده باشد. برای توزیع فایل‌های موقتیِ قابل بازسازی، بررسی سریع ممکن است کافی باشد. برای تحویل مجموعه‌ای که بعداً قرار است مبنای آرشیو شود، ارزیابی محتوا و ثبت گزارش اهمیت بیشتری دارد. این انتخاب را مستند کنید تا اجرای بعدی ناخواسته با گزینه‌ای سریع‌تر اما ضعیف‌تر جایگزین نشود.
check چه چیزی را تأیید می‌کند؟
فرمان check مبدأ و مقصد را مقایسه می‌کند و آن‌ها را تغییر نمی‌دهد. مستندات آن مقایسه اندازه و hash و امکان دریافت داده با گزینه download را توضیح می‌دهد. گزینه one-way فقط حضور و تطابق فایل‌های مبدأ در مقصد را بررسی می‌کند و اضافه‌بودن فایل مقصد را گزارش نمی‌کند. این حالت پس از copy می‌تواند با هدف نگه‌داشتن داده اضافی سازگار باشد، ولی برای تأیید یک آینه کامل همان معنای بررسی دوطرفه را ندارد.
برای یک نمونه آموزشی:
rclone check /srv/example-source remote:example/current --one-way
در انتخاب روش بررسی، هزینه شبکه را نیز ببینید. دانلود برای مقایسه می‌تواند حجم زیادی مصرف کند. گزارش اختلاف، فایل مفقود و خطای خواندن را از هم تفکیک کنید؛ خطای دسترسی با اختلاف محتوای قطعی یکسان نیست. همچنین موفقیت check درباره همان مجموعه و همان زمان معنا دارد و جای آزمایش بازیابی در کاربرد اصلی را نمی‌گیرد.
فیلترها بخشی از قرارداد انتقال‌اند
فیلتر تعیین می‌کند چه فایل‌هایی در محدوده عملیات قرار دارند. اگر بخشی از مبدأ کنار گذاشته شود، دیگر نباید نتیجه را آینه همه مبدأ بنامید. مستندات filtering قواعد include و exclude و ترتیب ارزیابی آن‌ها را توضیح می‌دهد. برای قواعد پیچیده، فایل فیلتر قابل بازبینی بهتر از رشته‌ای طولانی و مبهم در فرمان است. همان فایل را همراه گزارش اجرای مربوط نگه دارید.
در تحلیل عملی، یک خطر رایج تفاوت فیلتر میان انتقال و بررسی است. اگر انتقال فقط تصاویر را شامل شود ولی check همه فایل‌ها را ببیند، اختلاف‌ها الزاماً نشانه خرابی انتقال نیستند. برعکس، فیلتر بیش از حد محدود در مرحله بررسی می‌تواند داده جاافتاده را پنهان کند. محدوده دو مرحله باید آگاهانه یکسان یا تفاوتش مستند باشد.
از گزینه delete-excluded فقط با درک اثر آن استفاده کنید؛ رفتار حذف فایل‌های خارج از محدوده را تغییر می‌دهد. این گزینه راهی عمومی برای تمیزکردن مقصد نیست. ابتدا فهرست واقعی فایل‌های مشمول قاعده را ببینید و اثر ترکیب قواعد را آزمایش کنید. یک الگوی ساده ممکن است در مسیرهای تو‌در‌تو معنایی متفاوت از انتظار داشته باشد.
backup-dir و تاریخچه تغییرات
مستندات عمومی rclone توضیح می‌دهد که backup-dir می‌تواند فایل‌هایی را که قرار است جایگزین یا حذف شوند، به سلسله‌مراتب دیگری منتقل کند. این قابلیت شرایطی دارد: backend باید عملیات لازم را پشتیبانی کند، مقصد آرشیو با remote مناسب هماهنگ باشد و مسیرها به‌صورت مشکل‌ساز هم‌پوشانی نداشته باشند. بنابراین اضافه‌کردن یک پرچم، بدون بررسی ساختار ذخیره‌سازی، سیاست پشتیبان‌گیری کامل ایجاد نمی‌کند.
برای طراحی آرشیو تغییرات، به نام‌گذاری هر اجرا و برخورد نام‌های تکراری فکر کنید. اگر چند اجرا فایل هم‌نام را به محل واحد بفرستند، تاریخچه مورد انتظار ممکن است حفظ نشود. همچنین این پوشه عمدتاً فایل‌های تغییرکرده یا حذف‌شونده را نگه می‌دارد؛ لزوماً تصویری کامل و مستقل از هر لحظه نیست. بازسازی باید با همین معنا طراحی و آزمایش شود.
پشتیبان واقعی به سیاست نگه‌داری، جداسازی از دامنه خرابی و روش بازیابی نیاز دارد. اگر همان حساب بتواند هم مقصد جاری و هم همه آرشیوها را پاک کند، وجود دو مسیر به‌تنهایی جداسازی ایجاد نمی‌کند. کنترل دسترسی و قابلیت‌های نسخه‌بندی سرویس باید بر اساس نیاز بررسی شوند. این نکته درباره معماری حفاظت داده است، نه ادعای اینکه یک فرمان خاص همه خطرها را برطرف می‌کند.
فهرست‌برداری، گزارش و اجرای تکرارشونده
برای شناخت مجموعه پیش از انتقال، فرمان‌هایی مانند lsf و lsjson مفیدند. اولی خروجی فهرستی با قالب قابل انتخاب فراهم می‌کند و دومی برای پردازش ساختاریافته مناسب است. در اسکریپت، خروجی ماشین‌خوان معمولاً از بریدن ستون‌های متن نمایشی قابل اتکاتر است. بااین‌حال، فهرست‌برداری نیز هزینه و زمان دارد و روی مخزن بزرگ باید با توجه به محدودیت سرویس انجام شود.
در اجرای تکرارشونده، نسخه ابزار، مسیرها، فیلترها و وضعیت پایان را ثبت کنید. موفقیت زمان‌بند به معنای موفقیت فرمان نیست؛ ممکن است برنامه شروع شده ولی با خطا تمام شده باشد. از هم‌پوشانی اجراها نیز جلوگیری کنید تا دو فرایند هم‌زمان درباره یک مقصد تصمیم نگیرند. گزارش باید برای تشخیص مسئله کافی باشد، اما نباید اطلاعات دسترسی یا داده خصوصی غیرضروری را منتشر کند.
اگر از crypt استفاده می‌کنید، برنامه بازیابی باید شامل پیکربندی و کلیدهای لازم نیز باشد. داده رمز‌شده بدون اطلاعات لازم برای بازگشایی، حتی در صورت انتقال کامل، قابل استفاده نیست. مستندات crypt و فرمان اختصاصی cryptcheck را برای این حالت بخوانید؛ فرض‌های بررسی فایل عادی را بی‌تغییر به لایه رمز‌شده منتقل نکنید.
معیار پایان کار را کاربرد تعیین می‌کند
انتقال موفق زمانی کامل است که نتیجه با هدف اولیه تطبیق داشته باشد. برای آینه، نبود اختلاف در محدوده تعریف‌شده مهم است. برای تحویل فایل، دریافت و بازشدن نمونه‌های نماینده اهمیت دارد. برای پشتیبان‌گیری، بازگردانی و استفاده از داده در محیط جدا معیار جدی‌تری است. هرکدام آزمون متفاوتی می‌خواهند و صرف مشاهده تعداد بایت منتقل‌شده کافی نیست.
یک گردش کار روشن از شناخت مبدأ و مقصد آغاز می‌شود، با پیش‌نمایش و اجرای کنترل‌شده ادامه می‌یابد و با بررسی و آزمایش بازیابی پایان می‌گیرد. copy، sync و check در این فرایند ابزارهای مکمل‌اند. انتخاب درست زمانی رخ می‌دهد که معنای حذف، جایگزینی و تأیید را دقیق تعریف کرده باشید؛ سپس فرمان مناسب را برای همان قرارداد به کار ببرید.
