انتقال سریع فایل‌های حجیم بین دو سرور با دستور rsync از طریق SSH در لینوکس

دستور rsync از طریق SSH یکی از بهترین و مطمئن‌ترین روش‌های لینوکسی برای انتقال سریع، امن و مقاوم در برابر قطعی فایل‌های حجیم بین دو سرور است. این روش به‌خصوص هنگام جابجایی صدها گیگابایت داده مانند فایل‌های وب‌سایت، آرشیوهای پشتیبان، پوشه‌های رسانه‌ای یا داده‌های برنامه‌ها بسیار کارآمد است، چرا که rsync تنها بلوک‌های تغییر یافته را منتقل می‌کند و نسبت به روش‌های کپی سنتی سرعت چشمگیری دارد. اصول کار به این شکل است که فایل‌های سرور مبدا از طریق تونل SSH به شکل رمزنگاری شده به سرور مقصد همگام‌سازی می‌شوند و در صورت قطع ارتباط، عملیات از همان نقطه ادامه می‌یابد.

هنگام انتقال سرور، ارتقا هاستینگ، تغییر دیتاسنتر یا عملیات بکاپ‌گیری، علاوه بر سرعت، حفظ یکپارچگی داده‌ها اهمیت ویژه‌ای دارد. دانلود کامل یک آرشیو حجیم و بارگذاری مجدد آن زمان‌بر است و ریسک از دست رفتن داده در صورت قطعی ارتباط وجود دارد. rsync با حفظ زمان‌بندی‌ها، مجوزها، مالکیت فایل‌ها و ساختار دایرکتوری‌ها این مشکلات را برطرف می‌کند. به همین دلیل مدیران سیستم لینوکس، تیم‌های DevOps و متخصصان وب‌هاستینگ روزانه از این ابزار استفاده می‌کنند.

در این راهنما مرحله به مرحله انتقال فایل‌های حجیم بین دو سرور لینوکسی با rsync از طریق SSH را همراه با مثال‌های واقعی دستوری بررسی می‌کنیم. همچنین پارامترهای بهینه‌سازی عملکرد، نکات امنیتی، سناریوهای خطا، روش‌های تست انتقال و نکات مهم پیش از ورود به محیط تولید را توضیح خواهیم داد. اگر قصد مهاجرت به VPS یا هاست جدیدی دارید، قبل از شروع مطمئن شوید که در هر دو سرور فضای کافی، دسترسی SSH و مجوزهای کاربری مناسب فراهم است. برای انتخاب زیرساخت مناسب می‌توانید صفحات راهکارهای سرور VPS Hostragons و پکیج‌های هاستینگ لینوکس را مطالعه کنید.

rsync چیست و چرا برای انتقال فایل‌های بزرگ مناسب است؟

rsync ابزاری قدرتمند خط فرمان برای همگام‌سازی فایل‌ها و پوشه‌ها در سیستم محلی یا بین سرورهای راه دور است. مهم‌ترین ویژگی آن الگوریتم انتقال دلتا است؛ این الگوریتم به جای ارسال کل فایل در هر بار، فقط بخش‌های تغییر یافته را منتقل می‌کند. برای نمونه، اگر در یک فایل پشتیبان ۸۰ گیگابایتی تنها ۲ گیگابایت تغییر داشته باشد، به جای ارسال کل ۸۰ گیگ، فقط این تغییرات ارسال می‌شود که موجب صرفه‌جویی زیادی در زمان و پهنای باند می‌شود.

SSH انتقال را رمزنگاری می‌کند تا داده‌ها به صورت متن ساده ارسال نشوند. این ویژگی برای حفظ امنیت اطلاعات مشتریان، سفارشات فروشگاه آنلاین، آرشیوهای رسانه‌ای، بکاپ دیتابیس و فایل‌های برنامه‌های اختصاصی حیاتی است. امنیت داده‌ها در دنیای هاستینگ فقط به گواهی SSL محدود نمی‌شود؛ کانال انتقال بین سرورها نیز باید امن باشد. همانطور که برای ترافیک وب از گواهی‌نامه SSL استفاده می‌کنید، برای انتقال فایل‌ها نیز SSH با رمزنگاری توصیه می‌شود.

در مقایسه با FTP یا دانلود و آپلود دستی، rsync انعطاف‌پذیرتر است. این ابزار می‌تواند مجوزها را حفظ کند، لینک‌های سمبولیک را منتقل کند، فایل‌های حذف شده را در مقصد نیز پاک کند، پهنای باند را محدود کند و قبل از انتقال تست اجرا نماید. چنین کنترل و قابلیت‌هایی در انتقال فایل‌های بزرگ بسیار ارزشمند است.

چه زمانی باید از rsync از طریق SSH استفاده کنید؟

rsync از طریق SSH برای انتقال فایل‌های حجیم، تعداد زیاد یا فایل‌هایی که به‌طور مکرر تغییر می‌کنند بسیار مناسب است. برای انتقال یک پوشه کوچک تصاویر، استفاده از SFTP دستی ممکن است کافی باشد، اما وقتی هزاران فایل، مجوزهای متنوع و آرشیوهای بزرگ درکار باشند، rsync گزینه مطمئن‌تر و بهینه‌تری است.

• وقتی از سرور قدیمی به VPS جدید سایت منتقل می‌کنید.
• انتقال پوشه‌هایی مانند uploads وردپرس با هزاران فایل رسانه‌ای.
• کپی گرفتن پشتیبان‌های روزانه، هفتگی یا ماهانه به سرور دیگر.
• تغییر دیتاسنتر یا ارائه‌دهنده هاستینگ.
• همگام‌سازی فایل‌های برنامه بین محیط تولید و بکاپ.
• انتقال‌های طولانی که احتمال قطعی اتصال وجود دارد.

مثلاً دانلود یک پوشه رسانه‌ای ۲۵۰ گیگابایتی روی کامپیوتر شخصی و سپس آپلود آن روی سرور جدید به دو مرحله انتقال نیاز دارد که هم زمان‌بر است و هم ممکن است پهنای باند اینترنت خانگی یا اداری را اشغال کند. با rsync انتقال مستقیم از سرور مبدا به مقصد انجام می‌شود و این مرحله میانی حذف می‌گردد.

موارد لازم قبل از شروع

دانستن دستورات rsync کافی نیست؛ بررسی شرایط سرور مبدا و مقصد بسیار مهم است تا ریسک از دست رفتن داده یا انتقال ناقص کاهش یابد. در محیط‌های تولیدی حتماً موارد زیر را کنترل کنید.

1. دسترسی SSH را آزمایش کنید

سرور مبدا باید بتواند به سرور مقصد از طریق SSH متصل شود. برای تست معمولی دستور زیر اجرا می‌شود: ssh user@ip-destination. اگر SSH روی پورتی غیر از ۲۲ است به شکل زیر تست کنید: ssh -p 2222 user@ip-destination. اگر اتصال برقرار نشود، rsync نیز کار نخواهد کرد. تنظیمات فایروال، Fail2ban، پورت SSH، مجوزهای کاربری و احراز هویت با کلید یا رمز عبور باید چک شود.

2. نصب بودن بسته rsync را بررسی کنید

بیشتر توزیع‌های لینوکس به طور پیش‌فرض rsync دارند ولی بهتر است بررسی شود. در سیستم‌های Debian و Ubuntu دستور rsync --version را اجرا کنید. در صورت نبود، با apt install rsync نصب کنید. در توزیع‌هایی مثل AlmaLinux، Rocky Linux یا CentOS از dnf install rsync یا yum install rsync استفاده می‌شود. اگر VPS لینوکسی روی Hostragons دارید، نصب معمولاً چند ثانیه طول می‌کشد.

3. فضای دیسک کافی را بسنجید

اگر در سرور مقصد فضای کافی نباشد، انتقال نیمه‌کاره متوقف می‌شود. حجم پوشه مبدا را با دستور du -sh /path/to/source می‌توان دید و فضای خالی مقصد با df -h بررسی می‌شود. بهتر است علاوه بر حجم فایل‌ها، فضای اضافی برای فایل‌های موقت و لاگ‌ها در نظر گرفته شود. مثلاً برای انتقال ۵۰۰ گیگابایت داده، حداقل ۵۵۰ تا ۶۰۰ گیگ فضای آزاد در سرور مقصد برنامه‌ریزی کنید.

4. برنامه‌ریزی برای سرویس‌های حیاتی و فایل‌های در حال تغییر

در سایت‌های فعال ممکن است فایل‌ها هنگام انتقال تغییر کنند؛ مثلاً آپلودهای کاربران، پوشه کش و فایل‌های لاگ مرتب به‌روزرسانی می‌شوند. در انتقال‌های بزرگ ابتدا انتقال اصلی انجام می‌شود، سپس سایت به حالت نگهداری (maintenance) برده شده و rsync مجدد برای هماهنگ‌سازی تغییرات اجرا می‌شود تا زمان قطعی به حداقل برسد. برای سایت‌های وردپرسی می‌توانید از محتوای راهنمای انتقال هاستینگ وردپرس برای برنامه‌ریزی بهتر کمک بگیرید.

دستور پایه rsync برای انتقال فایل بین دو سرور

فرم معمول دستور به شکل زیر است: rsync -avz /source/path/ user@destination-ip:/destination/path/. گزینه -a حالت آرشیو است که مجوزها، زمان‌ها و لینک‌های سمبولیک را حفظ می‌کند. -v خروجی جزئیات را نشان می‌دهد و -z فایل‌ها را هنگام انتقال فشرده می‌کند. نکته مهم وجود اسلش در انتهای مسیر مبدا است؛ اگر وجود داشته باشد فقط محتوای پوشه منتقل می‌شود، در غیر این صورت کل پوشه به مقصد کپی می‌شود.

فرض کنید می‌خواهید پوشه /var/www/site/public_html/ به حجم ۱۸۰ گیگابایت از سرور قدیمی به همان مسیر در سرور جدید منتقل کنید. دستور به این شکل خواهد بود: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. این دستور از طریق SSH فایل‌ها را به سرور مقصد منتقل می‌کند.

اگر نمی‌خواهید با کاربر root کار کنید، بهتر است روی سرور مقصد کاربری با دسترسی نوشتن به پوشه ایجاد کنید. برای مثال کاربر deploy را بسازید و مالکیت پوشه‌ها را به آن تغییر دهید. در محیط‌های تولیدی، استفاده از کاربر با مجوز محدود امنیت بیشتری دارد.

پارامترهای پیشنهادی امن و مقاوم برای rsync

برای انتقال‌های بزرگ، استفاده از دستور پایه کافی نیست. باید پارامترهای اضافی برای مقابله با قطع اتصال، فایل‌های نیمه‌کپی شده، حذف اشتباه یا شبکه‌های کند به کار گرفته شوند. نمونه دستور زیر برای اغلب سناریوهای واقعی مناسب است:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /source/path/ user@destination-ip:/destination/path/

در این دستور -a حالت آرشیو، -H حفظ لینک‌های سخت، -A حفظ مجوزهای ACL و -X حفظ ویژگی‌های توسعه یافته فایل‌ها را تضمین می‌کند. --numeric-ids کاربران و گروه‌ها را با شناسه عددی مقایسه می‌کند که اگر نام‌های کاربری متفاوت باشد مفید است. --partial فایل‌های نیمه‌کپی شده را حذف نمی‌کند. --progress پیشرفت انتقال را نشان می‌دهد و --append-verify در فایل‌های بزرگ هنگام ادامه انتقال صحت داده را تضمین می‌کند.

هر پارامتر لزوماً در همه سیستم‌ها لازم نیست. مثلاً انتقال یک سایت ساده ممکن است با -aHAX کافی باشد ولی برای برنامه‌هایی که مجوزهای خاص دارند، حفظ ACL و ویژگی‌های توسعه یافته حیاتی است. بنابراین بهتر است ابتدا تست انتقال انجام شود.

اگر SSH روی پورت متفاوتی است، دستور rsync چگونه باشد؟

برای امنیت، ممکن است SSH روی پورتی غیر از ۲۲ فعال باشد. در این حالت باید پارامتر ssh با پورت مشخص شده به rsync داده شود. مثال:

rsync -avz -e 'ssh -p 2222' /source/path/ user@destination-ip:/destination/path/

توجه کنید که مقدار -e باید درون یک جفت کوتیشن قرار گیرد تا صحیح اجرا شود. در بعضی پنل‌ها و JSON ها کوتیشن‌ها ممکن است متفاوت رفتار کنند، پس در ترمینال به درستی وارد کنید. اگر از کلید خصوصی برای اتصال استفاده می‌کنید، می‌توانید پارامتر -i را نیز اضافه کنید:

rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /source/path/ user@destination-ip:/destination/path/

این روش برای خودکارسازی و استفاده در کرون جاب‌ها بسیار رایج است.

تست انتقال با گزینه --dry-run

یکی از بهترین روش‌ها قبل از انتقال واقعی، استفاده از گزینه --dry-run است که عملیات را شبیه‌سازی می‌کند و هیچ فایلی منتقل نمی‌شود. فقط لیست فایل‌هایی که قرار است منتقل شوند و عملیاتی که انجام می‌شود نمایش داده می‌شود. این کار به شما کمک می‌کند اشتباه در مسیر، حذف ناخواسته فایل‌ها یا مشکلات دیگر را قبل از شروع انتقال واقعی شناسایی کنید.

مثال دستور تست:

rsync -avz --dry-run /var/www/site/ user@destination-ip:/var/www/site/

خروجی شامل فایل‌هایی است که قرار است کپی شوند و خلاصه عملیات. اگر از گزینه --delete استفاده می‌کنید، اجرای dry-run اهمیت بیشتری دارد چون این گزینه فایل‌های موجود در مقصد که در مبدا نیستند را حذف می‌کند و ممکن است باعث از دست رفتن داده شود. معمولاً ابتدا تست SSH، سپس بررسی فضای دیسک، اجرای rsync با --dry-run و تست روی پوشه کوچک انجام و در نهایت انتقال اصلی شروع می‌شود. این کار چند دقیقه بیشتر طول می‌کشد ولی از ساعت‌ها مشکل جلوگیری می‌کند.

تنظیمات فشرده‌سازی، محدودیت پهنای باند و رمزنگاری برای بهبود عملکرد

عملکرد rsync فقط به حجم فایل‌ها بستگی ندارد؛ قدرت پردازش سرورها، نوع دیسک، تأخیر شبکه، پهنای باند و تعداد فایل‌ها نیز تأثیرگذارند. فایل‌های کوچک زیاد ممکن است کندتر از یک فایل بزرگ منتقل شوند چون پردازش متادیتا بیشتر است. VPSهای مجهز به دیسک NVMe سرعت خواندن و نوشتن بهتری دارند و مناسب انتقال‌های سنگین هستند. اگر قصد انتقال زیاد دارید، گزینه‌های سرور VPS NVMe را بررسی کنید.

گزینه -z فشرده‌سازی هنگام انتقال را فعال می‌کند که برای فایل‌های متنی، لاگ و برخی بکاپ‌ها مفید است ولی روی فایل‌های فشرده شده مثل zip، tar.gz، jpg، mp4 یا gzip باعث مصرف پردازنده اضافه شده و تأثیر کمی دارد. اگر بین دو سرور قوی با لینک یک گیگابیت دارید و فایل‌های رسانه‌ای بزرگ انتقال می‌دهید، ممکن است بدون -z سرعت بیشتری بگیرید. اما در شبکه‌های کم سرعت و فایل‌های متنی، -z صرفه‌جویی قابل توجهی دارد.

برای محدود کردن پهنای باند می‌توان از --bwlimit استفاده کرد. مثلاً --bwlimit=50000 پهنای باند را حدود ۵۰ مگابایت بر ثانیه محدود می‌کند. این کار به حفظ کیفیت تجربه کاربران سایت در ساعات اوج کمک می‌کند. بهتر است انتقال را در ساعات کم‌بار برنامه‌ریزی کنید، سقف پهنای باند اعمال کنید و در حین کار میزان بار سرور (load average) را زیر نظر داشته باشید.

مقایسه rsync، scp، SFTP و FTP

روش‌های متعددی برای انتقال فایل وجود دارد که هر کدام مزایا و معایب خاص خود را دارند. جدول زیر برای انتقال فایل‌های حجیم و جابجایی سرور، کاربرد هر روش را نشان می‌دهد:

همانطور که جدول نشان می‌دهد، rsync برای همگام‌سازی مکرر و انتقال داده‌های بزرگ بهترین انتخاب است. scp ساده و سریع است اما توانایی شناسایی تغییرات فایل را ندارد. FTP بدون رمزنگاری امنیت پایینی دارد و برای انتقال‌های حساس توصیه نمی‌شود. در پنل‌های هاستینگ ممکن است FTP راحت باشد ولی انتقال‌های مهم بین سرورها بهتر است با روش‌های مبتنی بر SSH انجام شود.

نمونه روند کار برای انتقال سایت زنده

وقتی یک وب‌سایت را از سرور قدیمی به جدید منتقل می‌کنید، فقط کپی فایل‌ها کافی نیست. باید DNS، دیتابیس، گواهی SSL، نسخه PHP، مجوزهای فایل و تنظیمات ایمیل را هم بررسی کنید. در ادامه روندی با کمترین قطعی برای سایت‌های حجیم آورده شده است.

• نصب وب‌سرور، PHP، دیتابیس و ماژول‌های لازم روی سرور جدید.
• کاهش مقدار TTL دامنه به عدد پایین (مثلاً ۳۰۰ ثانیه) قبل از انتقال. برای مدیریت دامنه به بررسی دامنه و مدیریت دامنه مراجعه کنید.
• اجرای اولین انتقال rsync در حالی که سایت هنوز آنلاین است تا بخش عمده داده منتقل شود.
• تهیه بکاپ دیتابیس و انتقال به سرور جدید.
• قرار دادن سایت در حالت نگهداری (maintenance).
• اجرای دومین انتقال rsync برای همگام‌سازی تغییرات نهایی.
• بروزرسانی مجدد دیتابیس یا استفاده از روش افزایشی (incremental).
• چک کردن مجوز فایل‌ها، راه‌اندازی سایت و بررسی لاگ‌ها روی سرور جدید.
• نصب یا تمدید گواهی SSL. برای این کار می‌توانید از نصب گواهی‌نامه SSL استفاده کنید.
• تغییر رکوردهای DNS به IP جدید.

در این روش، بخش عمده انتقال در حالی انجام می‌شود که سایت فعال است و قطعی فقط هنگام همگام‌سازی نهایی و تغییر DNS خواهد بود. در سایت‌های وردپرسی با آرشیو رسانه‌ای بزرگ، این کار می‌تواند قطعی چند ساعته را به چند دقیقه کاهش دهد.

بررسی یکپارچگی داده‌ها

پس از اتمام انتقال، کافی نیست که فقط دستور به پایان رسیده باشد. باید تعداد فایل‌ها، حجم‌ها و فایل‌های حساس بررسی شوند. ساده‌ترین روش مقایسه حجم پوشه‌ها با دستور du -sh در مبدا و مقصد است، ولی به دلیل تفاوت‌های سیستم فایل امکان دارد اعداد دقیقاً برابر نباشند. برای تایید دقیق‌تر می‌توان دستور rsync را با همان پارامترها دوباره اجرا کرد و اگر چیزی برای انتقال نمانده بود، خروجی بسیار کم خواهد بود.

برای بررسی صحت داده‌ها می‌توان از گزینه -c استفاده کرد که علاوه بر تاریخ و حجم، چکسام فایل‌ها را هم مقایسه می‌کند:

rsync -avc --dry-run /source/path/ user@destination-ip:/destination/path/

این کار مصرف CPU و دیسک بالایی دارد و در داده‌های حجیم باید با احتیاط استفاده شود. برای آرشیوهای حساس، فایل‌های دیتابیس یا اسناد مشتری این اعتبارسنجی اطمینان‌بخش است.

اگر سایت را منتقل کرده‌اید، حتماً عملکرد در سطح برنامه را هم بررسی کنید؛ صفحه اصلی، پنل مدیریت، آپلود تصاویر، صفحات پرداخت، فرم تماس و لاگ خطاها باید تست شوند. در سایت‌های فروشگاهی فقط انتقال فایل کافی نیست؛ اتصال پرداخت‌ها و کارکرد کرون جاب‌ها روی سرور جدید باید مطمئن شود.

خطاهای رایج و راه‌حل‌ها

خطای Permission denied

این خطا معمولاً به دلیل نبود مجوز کافی کاربر SSH، اجازه نوشتن روی پوشه مقصد یا مشکل در احراز هویت کلید رخ می‌دهد. ابتدا با همان کاربر SSH متصل شوید و تست ایجاد فایل در مقصد انجام دهید. اگر لازم است مالکیت پوشه‌ها را با chown تغییر دهید یا راهکار مبتنی بر sudo در نظر بگیرید.

خطای No space left on device

این خطا وقتی رخ می‌دهد که فضای دیسک مقصد کافی نباشد. با df -h پارتیشن‌ها را بررسی کنید. گاهی ممکن است فضای اصلی پر نباشد ولی /tmp یا محل mount مقصد پر شده باشد. برای انتقال‌های بزرگ می‌توانید لاگ‌ها، بکاپ‌های قدیمی و کش را پاک کنید یا در نهایت فضای دیسک را افزایش دهید یا به VPS با ظرفیت بالاتر مهاجرت کنید.

خطای Connection reset یا Broken pipe

در انتقال‌های طولانی ممکن است اتصال شبکه قطع شود. اگر از گزینه‌های --partial و --append-verify استفاده کنید، می‌توانید دستور را مجدد اجرا کنید تا انتقال از همان نقطه ادامه یابد. همچنین تنظیمات keepalive در SSH مثل ServerAliveInterval 60 به کاهش قطع اتصال کمک می‌کند.

سرعت انتقال بسیار پایین است

کندی ممکن است به تعداد زیاد فایل‌های کوچک، محدودیت ورودی/خروجی دیسک، بار پردازنده یا محدودیت شبکه مربوط باشد. در صورت وجود فایل‌های کوچک، ایجاد آرشیو tar و انتقال آن ممکن است سریع‌تر باشد، ولی مزیت تغییرات جزئی rsync کاهش می‌یابد. برای فایل‌های بزرگ و فشرده شده گزینه -z را حذف و تست کنید. ابزارهایی مانند iotop، htop و iftop برای شناسایی گلوگاه CPU، دیسک یا شبکه مفیدند.

بهترین روش‌های امنیتی

در انتقال فایل بین سرورها امنیت را جدی بگیرید. به‌ویژه دسترسی root، کلیدهای SSH و فایل‌های پشتیبان حساس هستند. توصیه می‌شود از ورود با رمز عبور اجتناب کرده و از کلید SSH با محافظت پسورد استفاده کنید. مجوزهای کلید خصوصی باید محدود باشد و کلیدها به هیچ کس منتقل نشوند.

ایجاد کاربر موقتی با دسترسی محدود به پوشه‌های مورد نیاز، روش مطمئنی است. پس از اتمام انتقال، دسترسی این کاربر باید حذف یا غیرفعال شود. محدود کردن دسترسی SSH به آی‌پی‌های مشخص، استفاده از فایروال، Fail2ban و به‌روزرسانی OpenSSH از دیگر اقدامات مهم است.

اگر فایل‌های dump دیتابیس، اسناد مشتری یا داده‌های شخصی منتقل می‌کنید، پس از انتقال فایل‌های موقتی و نیمه‌کپی شده را پاک کنید. همچنین نگهداری فایل‌های بکاپ مثل .sql، .zip یا .tar در پوشه‌های قابل دسترس وب خطر امنیتی است؛ آنها را در مسیرهای خارج از دسترس وب یا پس از اتمام عملیات حذف نمایید.

استفاده از rsync برای بکاپ خودکار

rsync تنها برای انتقال یک‌باره نیست، بلکه می‌توان آن را برای بکاپ منظم نیز به کار برد. مثلاً با تعریف کرون جاب می‌توان هر شب یک پوشه خاص را به سرور بکاپ منتقل کرد. در این حالت اتصال بدون رمز عبور با کلید SSH برقرار می‌شود، فقط تغییرات منتقل شده و محدودیت پهنای باند اعمال می‌شود.

مثال دستور بکاپ خودکار:

rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/

گزینه --delete باعث می‌شود مقصد دقیقاً شبیه مبدا شود، پس باید با دقت و پس از تست استفاده شود. استراتژی‌های بکاپ حرفه‌ای‌تر از snapshot، پوشه‌های روزانه یا نسخه‌بندی استفاده می‌کنند.

در عملیات هاستینگ قانون ۳-۲-۱ بکاپ توصیه می‌شود: حداقل ۳ نسخه از داده، در ۲ محیط متفاوت و ۱ نسخه در مکان فیزیکی جدا. rsync بخش کپی بین سرورها را آسان می‌کند. برای زیرساخت‌های جامع‌تر به صفحات راهکارهای پشتیبان‌گیری و خدمات هاستینگ شرکتی مراجعه نمایید.

چک‌لیست نهایی

قبل از شروع انتقال فایل‌های حجیم، موارد زیر را حتماً بررسی کنید تا ریسک خطا کاهش یابد. این لیست مخصوصاً در محیط‌های تولیدی باید به عنوان استاندارد رعایت شود.

• آیا rsync روی هر دو سرور نصب است؟
• آیا اتصال SSH با کاربر و پورت صحیح تست شده است؟
• آیا فضای دیسک کافی در سرور مقصد وجود دارد؟
• آیا انتقال اولیه با --dry-run بررسی شده است؟
• آیا برای سایت زنده حالت نگهداری و همگام‌سازی نهایی برنامه‌ریزی شده؟
• اگر از --delete استفاده می‌کنید، مسیر مقصد به دقت تأیید شده؟
• آیا پس از انتقال، حجم فایل‌ها، مجوزها و عملکرد برنامه تست می‌شود؟
• آیا فایل‌های موقتی بکاپ و dump به صورت امن پاک می‌شوند؟

این موارد ساده به نظر می‌رسند اما اکثر مشکلات واقعی به دلیل مسیر اشتباه، مجوز ناقص، کمبود فضای دیسک یا عدم برنامه‌ریزی صحیح DNS رخ می‌دهد. برنامه‌ریزی دقیق با rsync هم زمان انتقال را کاهش می‌دهد و هم امکان بازگشت به حالت قبل را فراهم می‌آورد.

سوالات متداول

اگر اتصال SSH هنگام اجرای rsync قطع شود، آیا انتقال از ابتدا شروع می‌شود؟

خیر، اگر پارامترهای صحیح استفاده شده باشد، انتقال از محل قطع ادامه می‌یابد. گزینه‌های --partial و --append-verify فایل‌های نیمه‌کپی شده را حفظ می‌کنند و هنگام اجرای مجدد باعث ادامه فرایند می‌شوند. اما در انتقال‌های حساس بهتر است قبل از اجرای مجدد فضای دیسک و وضعیت فایل‌ها بررسی شود.

آیا می‌توان دیتابیس را مستقیماً با rsync منتقل کرد؟

rsync فقط فایل‌ها را منتقل می‌کند و کپی مستقیم فایل‌های دیتابیس در حالت اجرا توصیه نمی‌شود. برای MySQL و MariaDB بهتر است از ابزار mysqldump یا بکاپ فیزیکی استفاده کرده و فایل بکاپ را با rsync منتقل کنید. در سیستم‌های زنده باید حالت نگهداری یا استراتژی رپلیکیشن برنامه‌ریزی شود تا داده‌ها منسجم بمانند.

آیا برای استفاده از rsync باید روی هر دو سرور دسترسی root داشت؟

خیر، دسترسی root الزامی نیست. یک کاربر با مجوز نوشتن به پوشه مقصد کافی است. اما اگر نیاز به حفظ مالکیت فایل‌ها، دسترسی‌های سیستمی یا ACL باشد، ممکن است مجوزهای بالاتری لازم باشد. از نظر امنیتی بهتر است از کاربر محدود استفاده شود.

آیا گزینه --delete در rsync امن است؟

اگر به درستی استفاده شود، گزینه --delete برای همگام‌سازی دقیق پوشه مقصد با مبدا بسیار مفید است. اما اگر مسیر اشتباه باشد، ممکن است باعث حذف ناخواسته فایل‌ها شود. بنابراین قبل از استفاده حتماً با --dry-run تست کنید و مسیرها را به دقت کنترل نمایید.

برای انتقال فایل‌های حجیم، rsync بهتر است یا scp؟

برای انتقال‌های کوچک و تک‌باره scp کافی است، اما rsync برای فایل‌های حجیم، تعداد زیاد فایل و همگام‌سازی‌های مکرر بهتر است. چون می‌تواند فقط تغییرات را منتقل کند، انتقال نیمه‌کاره را ادامه دهد، پهنای باند را کنترل کند و امکان تست پیش از انتقال را فراهم کند.

جمع‌بندی و گام بعدی

انتقال فایل‌های حجیم بین دو سرور با دستور rsync از طریق SSH روشی سریع، امن و قابل مدیریت است. با پارامترهای مناسب این انتقال در برابر قطعی‌ها مقاوم شده و تنها بخش تغییر یافته منتقل می‌شود که در انتقال سایت‌های زنده باعث کاهش قطعی می‌گردد. برای بهترین نتیجه ابتدا دسترسی SSH و فضای دیسک را بررسی کنید، سپس با --dry-run تست کنید و در نهایت انتقال اصلی را برنامه‌ریزی کنید.

اگر قصد مهاجرت به سرور جدید، فضای ذخیره‌سازی بزرگ‌تر یا زیرساخت هاستینگ پرسرعت‌تر دارید، راهکارهای Hostragons را بررسی کنید و با VPS، هاستینگ، دامنه و SSL مناسب عملیات انتقال را امن‌تر انجام دهید. انتقال را با تست‌های کوچک شروع کنید، نتایج را بسنجید و همگام‌سازی نهایی را به صورت منظم انجام دهید.