أدلة كيفية

نقل الملفات الكبيرة بين خادمَي Linux باستخدام rsync عبر SSH

  • 17 دقائق للقراءة
  • فريق Hostragons
نقل الملفات الكبيرة بين خادمَي Linux باستخدام rsync عبر SSH

يُعتبر أمر rsync عبر SSH من أكثر الطرق العملية لنقل الملفات الكبيرة بسرعة وأمان وبدون انقطاع بين خادمين. خاصةً عندما يتعلق الأمر بملفات مواقع الويب التي يصل حجمها إلى مئات جيجابايت، أو أرشيفات النسخ الاحتياطي، أو مجلدات الوسائط، أو بيانات التطبيقات، يوفر rsync ميزة كبيرة من حيث السرعة مقارنةً بأساليب النسخ التقليدية، حيث يقوم بنقل الكتل المتغيرة فقط. الفكرة الأساسية هي أن الملفات من الخادم المصدر تُنسق بشكل مشفر إلى الخادم الهدف عبر نفق SSH؛ وإذا انقطعت الاتصال، يمكن استئناف العملية من النقطة التي توقفت عندها.

عند نقل الخوادم، أو ترقية الاستضافة، أو تغيير مركز البيانات، أو إجراء عمليات النسخ الاحتياطي، تعتبر سرعة النقل وسلامة البيانات بنفس القدر من الأهمية. تحميل أرشيف كبير ككتلة واحدة ثم إعادة تحميله يُعد مضيعة للوقت، وقد يؤدي إلى بدء العملية من جديد في حال حدوث أخطاء في الاتصال. هنا يأتي دور rsync الذي يمكنه الحفاظ على طوابع الزمن، والأذونات، ومعلومات الملكية، وبنية المجلدات. لهذا السبب، يفضل مديرو أنظمة Linux، وفرق DevOps، وخبراء استضافة الويب استخدامه بشكل متكرر في العمليات اليومية.

في هذا الدليل، سنتناول بالتفصيل عملية نقل الملفات الكبيرة بين خادمين يعملان بنظام Linux باستخدام rsync عبر SSH، مع أمثلة فعلية للأوامر خطوة بخطوة. سنشارك أيضًا معايير زيادة الأداء، والرقابة الأمنية، وسيناريوهات الأخطاء، وطرق اختبار النقل، والنقاط التي يجب مراعاتها قبل الانتقال إلى بيئة الإنتاج. إذا كنت تخطط للانتقال إلى بيئة VPS أو استضافة جديدة، تأكد من وجود مساحة كافية على القرص، والوصول إلى SSH، والأذونات الصحيحة للمستخدم على كل من الخادم المصدر والهدف قبل تطبيق هذا الدليل. يمكنك مراجعة صفحات حلول خادم VPS Hostragons و حزم استضافة لينكس لاختيار البنية التحتية المناسبة.

ما هو rsync ولماذا يُفضل في نقل الملفات الكبيرة؟

rsync هو أداة قوية لسطر الأوامر تُستخدم لمزامنة الملفات والمجلدات بين النظام المحلي أو الخوادم البعيدة. تعتبر أهم ميزاته هي خوارزمية نقل الدلتا. هذه الخوارزمية تنقل فقط الأجزاء المتغيرة من الملف بدلاً من إعادة إرسال الملف بالكامل في كل مرة. على سبيل المثال، إذا كان هناك تغيير بحجم 2 جيجابايت فقط في ملف نسخ احتياطي حجمه 80 جيجابايت، فمن الممكن نقل الكتل المتغيرة فقط بدلاً من نقل الملف بأكمله.

يعمل SSH على تشفير النقل، مما يجعل أمر rsync ينقل محتويات الملفات عبر الشبكة بشكل آمن بدلاً من نقلها كنص عادي. هذه الميزة مهمة بشكل خاص للبيانات الحساسة مثل بيانات العملاء، وسجلات الطلبات في التجارة الإلكترونية، وأرشيفات الوسائط، ونسخ احتياطية لقواعد البيانات، وملفات التطبيقات الخاصة. في عالم الاستضافة، لا تقتصر أمان البيانات على شهادات SSL فقط؛ بل يجب أن يكون قناة النقل بين الخوادم آمنة أيضًا. عند استخدام شهادة SSL لحركة مرور موقع الويب، يجب أن يُفضل أيضًا استخدام التشفير عبر SSH عند نقل الملفات بين الخوادم.

يعتبر rsync أكثر مرونة مقارنةً بأساليب النقل اليدوي أو FTP. يمكنه الحفاظ على الأذونات، ونقل الروابط الرمزية، وحذف الملفات المحذوفة من الهدف، وتحديد عرض النطاق الترددي، واختبار ما يجب القيام به قبل النقل. توفر هذه المستويات من التحكم مزايا كبيرة في العمليات عالية المخاطر مثل نقل الملفات الكبيرة.

متى يجب استخدام أمر rsync عبر SSH؟

يُعتبر أمر rsync عبر SSH مثاليًا بشكل خاص عند نقل ملفات كبيرة، أو عند وجود عدد كبير من الملفات، أو في حالة الملفات التي تتغير بشكل متكرر. قد يكون SFTP اليدوي كافيًا لمجلد صور بسيط؛ ولكن عندما يتعلق الأمر بآلاف الملفات، والأذونات المختلفة، والأرشيفات الكبيرة، يصبح rsync خيارًا أكثر موثوقية.

  • عند نقل موقع الويب من خادم قديم إلى خادم VPS جديد.
  • عند نقل مجلدات تحتوي على آلاف الملفات الوسائط مثل مجلدات رفع WordPress.
  • عند نسخ النسخ الاحتياطية اليومية، أو الأسبوعية، أو الشهرية إلى خادم مختلف.
  • عند تغيير مركز البيانات أو مزود الاستضافة.
  • عند مزامنة ملفات التطبيقات بين بيئة الإنتاج والنسخ الاحتياطي.
  • عند التخطيط لعمليات نقل طويلة قد تتعرض لانقطاع الاتصال.

على سبيل المثال، إذا كنت تقوم بتنزيل مجلد وسائط حجمه 250 جيجابايت على جهاز الكمبيوتر الخاص بك ثم تحميله إلى خادم جديد، فهذا يعني أنك تقوم بعمليتين منفصلتين. هذا يزيد من إجمالي الوقت ويجعل اتصال الإنترنت المنزلي أو المكتبي نقطة اختناق. يمكنك تجنب هذه الخطوة الوسيطة من خلال إجراء نقل مباشر من الخادم المصدر إلى الخادم الهدف باستخدام rsync.

ما تحتاجه قبل البدء

لم يكتفِ معرفة أمر rsync وحده لتحقيق عملية ناجحة. يجب التحقق من شروط الخادم المصدر والهدف، مما يقلل من خطر فقدان البيانات أو حدوث نقل جزئي. يجب إجراء الفحوصات التالية في بيئات الإنتاج.

1. تحقق من الوصول إلى SSH

يجب أن يكون من الممكن إنشاء اتصال SSH من الخادم المصدر إلى الخادم الهدف. يتم اختبار الاتصال القياسي على النحو التالي: ssh المستخدم@عنوان-ip-الخادم-الهدف. إذا كان SSH يعمل على منفذ مختلف، يُجرب الاتصال على النحو التالي: ssh -p 2222 المستخدم@عنوان-ip-الخادم-الهدف. إذا لم يكن هذا الاختبار ناجحًا، فلن يعمل rsync أيضًا. يجب التحقق من جدار الحماية، وFail2ban، ومنفذ SSH، وأذونات المستخدم، والتحقق من كلمة المرور أو المفتاح.

2. تحقق من تثبيت حزمة rsync

عادةً ما تأتي معظم توزيعات Linux مع تثبيت rsync، ولكن يجب التحقق من ذلك. يمكن استخدام الأمر rsync --version في الأنظمة المستندة إلى Debian وUbuntu. إذا لم يكن مثبتًا، يمكنك تثبيته باستخدام apt install rsync. في توزيعات AlmaLinux أو Rocky Linux أو CentOS، يُفضل استخدام الأوامر dnf install rsync أو yum install rsync. إذا كنت تستخدم VPS قائم على Linux من Hostragons، فإن التثبيت عادةً ما يستغرق بضع ثوانٍ فقط.

3. حساب مساحة القرص

إذا لم يكن هناك مساحة كافية على الخادم الهدف، سيتوقف النقل. يمكن استخدام du -sh /مسار/المجلد لمعرفة حجم المجلد المصدر. يجب التحقق من حالة القرص باستخدام df -h على الهدف. في الممارسة العملية، يجب أن يكون هناك مساحة كافية ليس فقط لحجم الملفات ولكن أيضًا لملفات مؤقتة والسجلات. على سبيل المثال، إذا كنت ستنقل 500 جيجابايت من البيانات، فمن الأفضل التخطيط لتوفير 550-600 جيجابايت على الأقل من المساحة القابلة للاستخدام على الهدف.

4. التخطيط للخدمات الحرجة والملفات المتغيرة

قد تتغير الملفات أثناء النقل في المواقع التي تعمل بشكل مباشر. خاصةً، يتم تحديث التحميلات من المستخدمين، ومجلدات التخزين المؤقت، وملفات السجل باستمرار. في عمليات النقل الكبيرة، يجب نقل البيانات الأساسية أولاً، ثم وضع الموقع في وضع الصيانة لتشغيل rsync أخيرًا. بهذه الطريقة، يمكن تقليل فترة الانقطاع إلى دقائق. يمكنك إكمال خطة العملية الخاصة بك بمحتوى الدعم مثل دليل نقل استضافة ووردبريس.

الأمر الأساسي rsync: نقل الملفات بين خادمين

البنية الأساسية الأكثر استخدامًا هي كالتالي: rsync -avz /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/. حيث -a هو وضع الأرشيف ويحاول الحفاظ على المعلومات مثل الأذونات، وطوابع الزمن، والروابط الرمزية. -v يوفر إخراجًا تفصيليًا. -z يطبق الضغط أثناء النقل. إن وجود الشريط المائل في نهاية المجلد هو تفصيل مهم. إذا كتبت /مسار/المجلد/، سيتم نسخ محتويات المجلد إلى الهدف؛ أما إذا كتبت /مسار/المجلد، فسيتم إنشاء المجلد نفسه في الهدف.

دعونا نفكر في سيناريو مثالي: تريد نقل 180 جيجابايت من ملفات الويب الموجودة في مجلد /var/www/site/public_html/ على الخادم القديم إلى مجلد /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 وضبط ملكية المجلدات وفقًا لذلك. في بيئات الإنتاج، قد يكون من العملي التعامل مباشرةً مع root، ولكن من الأفضل من الناحية الأمنية استخدام مستخدم ذي صلاحيات محدودة.

المعلمات المقترحة لـ rsync التي تعزز الأمان والمتانة

في نقل الملفات الكبيرة، ليس من الصحيح دائمًا الاكتفاء بالأمر الأساسي. يجب استخدام معلمات إضافية لحالات مثل انقطاع الاتصال، والملفات الجزئية، وأخطاء الحذف، أو الشبكات البطيئة. الأمر التالي يعد نقطة بداية قوية للعديد من سيناريوهات النقل الحقيقية:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/

في هذا الأمر، يساعد -a على الحفاظ على وضع الأرشيف، و-H معلومات الروابط الصلبة، و-A أذونات ACL، و-X قيم السمات الموسعة. --numeric-ids يعتمد على قيم ID بدلاً من أسماء المستخدمين والمجموعات؛ وهذا يمكن أن يكون مفيدًا عندما تتغير أسماء المستخدمين عبر خوادم مختلفة. --partial يترك الملفات جزئية دون حذف. --progress يظهر حالة النقل. --append-verify يساعد بشكل خاص في التحقق من الجزء الذي تم إضافته عند الاستئناف.

قد لا تكون كل معلمة ضرورية في كل نظام. على سبيل المثال، في النقل البسيط لموقع الويب، قد يكون استخدام -aHAX كافيًا، بينما في تطبيق يستخدم أذونات ملفات خاصة، تصبح حماية معلومات ACL والسمات الموسعة أمرًا حاسمًا. لذلك، من المهم إجراء اختبار نقل أولاً.

ماذا إذا كنت تستخدم منفذ SSH مختلف؟

لأسباب أمنية، قد يعمل SSH على منفذ مختلف عن 22. في هذه الحالة، يتم تحديد معلمة SSH داخل rsync. على سبيل المثال: rsync -avz -e ssh -p 2222 /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/. لكن يجب استخدام القيمة في معلمة -e معًا في سطر الأوامر. تكون الفكرة الصحيحة كالتالي: rsync -avz -e 'ssh -p 2222' /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/.

نظرًا لأن استخدام علامات الاقتباس المفردة في JSON وبعض اللوحات قد يتصرف بشكل مختلف، تأكد من صحة علامات الاقتباس عند كتابتها مباشرة في الطرفية. إذا كنت تتصل بمفتاح SSH، يمكن إضافة المعلمة -i أيضًا: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/. تُستخدم هذه الطريقة بشكل متكرر في مهام النسخ الاحتياطي المعتمدة على الأتمتة وcron.

اختبار النقل قبل التنفيذ: استخدام --dry-run

إحدى الخطوات الأكثر احترافية التي يمكن اتخاذها قبل نقل البيانات الكبيرة هي استخدام --dry-run. هذه المعلمة لا تنسخ الملفات فعليًا؛ بل تُظهر فقط الملفات التي سيتم نقلها. بهذا الشكل، يمكن اكتشاف الدليل الخاطئ، أو مسار الهدف غير الصحيح، أو عمليات الحذف غير المتوقعة مسبقًا.

أمر الاختبار النموذجي: rsync -avz --dry-run /var/www/site/ المستخدم@عنوان-ip-الهدف:/var/www/site/. في الإخراج، سترى الملفات التي سيتم نقلها، والمجلدات التي سيتم إنشاؤها، وملخص العملية. إذا كنت ستستخدم معلمة --delete، يصبح الأمر أكثر أهمية. لأن --delete يمكن أن يحذف الملفات التي لا توجد في المصدر من الهدف. عند استخدامها بشكل صحيح، ستجعل الهدف متطابقًا تمامًا؛ ولكن عند استخدامها في دليل خاطئ، يمكن أن تؤدي إلى فقدان البيانات بشكل خطير.

عادةً ما تكون عملية التطبيق الاحترافية كالتالي: أولاً، يتم إجراء اختبار SSH، ثم يتم التحقق من مساحة القرص، ثم يتم تشغيل rsync --dry-run، ثم يتم إجراء اختبار حقيقي باستخدام مجلد صغير، وبعدها يتم بدء النقل الرئيسي. هذه الطريقة قد تتطلب بضع دقائق إضافية، لكنها تمنع عمليات النقل الخاطئة التي قد تستغرق ساعات.

الإعدادات الخاصة بالأداء: الضغط، وعرض النطاق الترددي، والتشفير

تتوقف أداء rsync ليس فقط على حجم الملفات. تعتبر قوة CPU للخوادم، ونوع القرص، وتأخير الشبكة، وعرض النطاق الترددي، وعدد الملفات أيضًا عوامل هامة. يمكن أن يتم نقل عدد كبير من الملفات الصغيرة بشكل أبطأ من ملف واحد كبير؛ لأن عمليات البيانات الوصفية تُجرى لكل ملف. في بيئات VPS المزودة بأقراص NVMe، قد يكون أداء الفحص والكتابة أفضل بشكل ملحوظ. لذلك، إذا كنت تخطط لنقل مكثف، من المنطقي النظر في خيارات خادم VPS NVMe.

تساعد معلمة الضغط -z في الملفات النصية، والسجلات، وبعض أنواع النسخ الاحتياطية. ومع ذلك، قد لا تحقق فائدة كبيرة عند التعامل مع الملفات المضغوطة بالفعل مثل zip، أو tar.gz، أو jpg، أو mp4، حيث قد تستنزف CPU دون تقديم فوائد كبيرة. إذا كنت تقوم بنقل ملفات وسائط ضخمة بين خادمين قويين بسرعة 1 جيجابت في الثانية، يمكنك الحصول على أداء أفضل دون استخدام -z. بالمقابل، في عرض النطاق الترددي المنخفض وفي الملفات الثقيلة بالنصوص، يمكن أن توفر -z توفيرًا كبيرًا.

لتحديد عرض النطاق الترددي، يمكن استخدام --bwlimit. على سبيل المثال، --bwlimit=50000 يضع حدودًا بحوالي 50 ميجابايت في الثانية. وهذا مهم لعدم إغراق حركة مرور الشبكة لموقع الويب الحي. قد يؤثر النقل بسرعة كاملة في أوقات الذروة على تجربة الزائرين في خادم الإنتاج. من الجيد التخطيط للنقل في ساعات الليل، وتحديد حدود عرض النطاق الترددي، ومراقبة قيم الحمل أثناء العملية.

مقارنة rsync وscp وSFTP وFTP

مقارنة rsync وscp وSFTP وFTP

هناك العديد من الطرق لنقل الملفات؛ ولكن كل طريقة لها نقاط القوة والضعف الخاصة بها. تلخص الجدول أدناه أي أداة هي الأنسب في سيناريوهات نقل الملفات الكبيرة والخوادم.

مقارنة rsync وscp وSFTP وFTP
الطريقةالأماناستئناف النقلأداء الملفات الكبيرةالاستخدام الأنسب
rsync + SSHعاليقويجيد جدًانقل الخوادم، النسخ الاحتياطي، المزامنة
scpعاليمحدودمتوسطنسخ عدد قليل من الملفات بسرعة
SFTPعاليمرتبط بالعميلمتوسطإدارة الملفات يدويًا
FTPمنخفضمرتبط بالعميلمتغيرأنظمة قديمة حيث الأمان ليس حرجًا

كما يتضح من الجدول، يُبرز rsync، خاصة في عمليات المزامنة المتكررة ونقل البيانات الكبيرة. بينما يعتبر scp بسيطًا وسهل الاستخدام، إلا أنه ليس قويًا مثل rsync في اكتشاف الملفات المتغيرة. من ناحية أخرى، قد لا يكون FTP مناسبًا لمعايير الأمان الحديثة عند استخدامه بدون تشفير. قد يكون الوصول عبر FTP عبر لوحات الإدارة عمليًا؛ ولكن في النقل الحرج بين الخوادم، يجب تفضيل الطرق المعتمدة على SSH.

تدفق العمل النموذجي لنقل موقع ويب حي

عند نقل موقع ويب من خادم قديم إلى خادم جديد، فإن الهدف ليس مجرد نسخ الملفات. يجب أيضًا التحقق من إعدادات DNS، وقاعدة البيانات، وإصدار PHP، وأذونات الملفات، وتكوين البريد الإلكتروني. أدناه يوجد تدفق عمل منخفض الانقطاع لموقع ويب يحتوي على ملفات كبيرة.

  • قم بإعداد خادم الويب وPHP وقاعدة البيانات والوحدات اللازمة على الخادم الجديد.
  • قم بتقليل قيمة TTL لنظام أسماء النطاقات للاسم إلى قيمة منخفضة مثل 300 ثانية قبل النقل. يمكنك تقييم صفحة استعلام عن النطاق وإدارة النطاق لإدارة اسم النطاق.
  • ابدأ النقل الأول باستخدام rsync بينما يكون الموقع حيًا. ستقوم هذه المرحلة بنقل معظم البيانات الكبيرة.
  • قم بعمل نسخة احتياطية لقاعدة البيانات ونقلها إلى الخادم الجديد.
  • ضع الموقع في وضع الصيانة لفترة قصيرة.
  • قم بتشغيل أمر rsync الثاني لمزامنة الملفات الأخيرة المتغيرة.
  • قم بتحديث قاعدة البيانات مرة أخرى أو استخدم استراتيجية متزايدة.
  • تحقق من أذونات الملفات، وفتح الموقع، والسجلات على الخادم الجديد.
  • قم بتثبيت أو تجديد شهادة SSL. قد يكون محتوى تثبيت شهادة SSL مفيدًا لذلك.
  • قم بتوجيه سجلات DNS إلى عنوان IP الجديد.

في هذه الطريقة، يتم إجراء النقل الرئيسي للملفات الأطول بينما يكون الموقع قيد التشغيل. يحدث الانقطاع فقط خلال المزامنة النهائية ومرور DNS. في مواقع WordPress ذات الأرشيفات الكبيرة من الوسائط، يمكن أن تقلل هذه الطريقة فترة الانقطاع التي قد تستغرق ساعات إلى بضع دقائق.

التحقق من سلامة البيانات

عند اكتمال النقل، ليس كافيًا فقط أن تكون العملية قد انتهت. يجب التحقق من عدد الملفات، والأحجام، والملفات الحيوية. للتحقق البسيط، يمكن مقارنة أحجام المجلدات باستخدام أمر du -sh على كل من المصدر والهدف. ومع ذلك، قد لا تبدو القيم متطابقة بسبب اختلافات نظام الملفات. للتحقق الأكثر تفصيلاً، يمكن تشغيل rsync مرة أخرى بنفس المعلمات. إذا لم يكن هناك ملفات جديدة للنقل، سيكون الإخراج في الحد الأدنى.

للتحقق من صحة Checksum، يمكن استخدام الأمر rsync -avc --dry-run /مسار/المجلد/ المستخدم@عنوان-ip-الهدف:/مسار/المجلد/. هنا، تساعد المعلمة -c في مقارنة الملفات ليس فقط بالطوابع الزمنية والأحجام، ولكن أيضًا باستخدام Checksum. يجب استخدامها بحذر في البيانات الكبيرة نظرًا لأنها قد تسبب تحميلًا على CPU والقرص. توفر هذه التحقق الإضافي الأمان للأرشيفات الحيوية، وملفات تفريغ قواعد البيانات، أو المستندات الخاصة بالعملاء.

إذا نقلت موقع ويب، يجب أيضًا إجراء فحص على مستوى التطبيق. يجب فحص الصفحة الرئيسية، وواجهة الإدارة، وتحميل الصور، وصفحة الدفع، ونموذج الاتصال، وسجلات الأخطاء.

الأخطاء الشائعة وحلولها

خطأ Permission denied

يحدث هذا الخطأ عادةً بسبب أذونات مستخدم SSH، أو إذن الكتابة في الدليل الهدف، أو تحقق المفتاح. جرب أولاً إنشاء اتصال SSH عادي باستخدام نفس المستخدم. إذا كانت الاتصال ناجحًا، قم بتجربة إنشاء ملف في الدليل الهدف. إذا لزم الأمر، يمكن تغيير ملكية الدليل الهدف باستخدام chown للمستخدم المعني، أو التخطيط لاستراتيجية تعتمد على sudo.

خطأ No space left on device

عندما لا توجد مساحة كافية على القرص الهدف، يتوقف النقل. تحقق من تقسيمات القرص باستخدام df -h. أحيانًا لا يكون القرص الرئيسي ممتلئًا، ولكن /tmp أو نقطة التركيب الهدف ممتلئة. في عمليات النقل الكبيرة، يمكن تنظيف ملفات السجل، والنسخ الاحتياطية القديمة، ومجلدات التخزين المؤقت. قد تحتاج إلى توسيع القرص أو الانتقال إلى خطة VPS ذات سعة أعلى كحل دائم.

خطأ Connection reset أو Broken pipe

قد تحدث انقطاعات في الشبكة خلال النقل الطويل. إذا كنت تستخدم --partial و --append-verify، يمكنك إعادة تشغيل الأمر لاستئناف النقل من حيث توقفت. قد تساعد إعدادات keepalive لـ SSH أيضًا. يمكن أن يقلل إعداد ServerAliveInterval 60 من انقطاع الاتصال أثناء الفراغ.

نقل بطيء للغاية

يمكن أن تكون البطء ناتجة عن عدد الملفات، أو حدود I/O للقرص، أو حمل الضغط، أو سعة الشبكة. إذا كان هناك عدد كبير من الملفات الصغيرة، قد يكون إنشاء أرشيف tar أولاً أسرع في بعض الحالات؛ ولكن في هذه الحالة، يتناقص ميزة التغييرات المستندة إلى الملفات في rsync. اختبر بإزالة معلمة -z في الملفات الكبيرة التي تم ضغطها بالفعل. أيضًا، استخدم أدوات مثل iotop وhtop وiftop لتحديد ما إذا كانت نقطة الاختناق تتعلق بـ CPU أو القرص أو الشبكة.

أفضل الممارسات للأمان

يجب عدم إغفال الأمان أثناء نقل الملفات بين الخوادم. خاصةً، يجب اعتبار الوصول إلى root، ومفاتيح SSH، وملفات النسخ الاحتياطي حساسة. من الأفضل استخدام مفتاح SSH بدلاً من الدخول بكلمة مرور. يجب أن تكون أذونات ملفات مفتاح SSH صارمة، ويجب عدم مشاركة المفاتيح الخاصة، وحمايتها بكلمة مرور إن أمكن.

إن إنشاء مستخدم مؤقت للنقل ومنحه الوصول إلى الدلائل الضرورية فقط هو طريقة جيدة. بعد انتهاء العملية، يمكن إزالة أذونات هذا المستخدم أو تعطيل حسابه. من المهم أيضًا تقييد الوصول إلى SSH ببعض عناوين IP لتقليل مساحة الهجوم. يجب أن تكون قواعد جدار الحماية، وFail2ban، وإصدار OpenSSH المحدث من بين الفحوصات الأساسية.

إذا تم نقل ملفات تفريغ قاعدة البيانات، أو المستندات الخاصة بالعملاء، أو الأرشيفات التي تحتوي على بيانات شخصية، يجب تنظيف الملفات المؤقتة غير الضرورية من المصدر والهدف بعد النقل. بالإضافة إلى ذلك، ترك ملفات النسخ الاحتياطي مثل .sql، أو .zip، أو .tar تحت الدليل الجذر للويب يشكل خطرًا أمنيًا كبيرًا. يجب أن تُخزن هذه الملفات في دليل مغلق أمام الوصول الويب إن أمكن، أو تُحذف عند انتهاء العملية.

استخدام rsync للنسخ الاحتياطي التلقائي

يمكن استخدام rsync ليس فقط للنقل لمرة واحدة، بل أيضًا للنسخ الاحتياطي المنتظم. على سبيل المثال، يمكن تعريف مهمة cron لإرسال مجلد معين إلى خادم النسخ الاحتياطي كل ليلة. في هذا السيناريو، يتم إنشاء اتصال آمن بدون كلمة مرور باستخدام مفتاح SSH، وينقل rsync فقط الملفات المتغيرة، ويمكن تطبيق حد عرض النطاق الترددي.

المنطق النموذجي: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@عنوان-ip-النسخ-الاحتياطي:/backup/site/. يمكن أن يقوم هذا الأمر بمزامنة الدليل الهدف مع المصدر. ومع ذلك، يجب أن يتم استخدام المعلمة --delete بحذر. حيث إذا تم حذف ملف عن طريق الخطأ من المصدر، فسوف يتم حذفه أيضًا من الهدف. لذلك، يُفضل استخدام استراتيجيات النسخ الاحتياطي الحيوية مثل اللقطات، أو المجلدات اليومية، أو الحلول المعتمدة على النسخ المتعددة.

في عمليات استضافة البيانات، تعتبر قاعدة النسخ الاحتياطي 3-2-1 مرجعًا جيدًا: يجب الاحتفاظ بثلاث نسخ على الأقل من البيانات، في بيئتين مختلفتين، ونسخة واحدة في موقع مختلف. يجعل rsync جزء النسخ الاحتياطي بين الخوادم عمليًا. يمكنك تعزيز خطتك من خلال الاطلاع على حلول النسخ الاحتياطي و خدمات الاستضافة المؤسسية.

قائمة التحقق النهائية

قبل بدء عملية نقل الملفات الكبيرة، يساعد تنفيذ القائمة القصيرة التالية في تقليل مخاطر الأخطاء. يجب أن تصبح هذه القائمة معيارية في بيئات الإنتاج.

  • هل تم تثبيت rsync على كل من الخادم المصدر والهدف؟
  • هل تم اختبار اتصال SSH مع المستخدم الصحيح والمنفذ؟
  • هل يوجد مساحة كافية على القرص في الخادم الهدف؟
  • هل تم التحقق من العملية الأولى باستخدام --dry-run؟
  • هل تم التخطيط لوضع الصيانة والمزامنة النهائية للموقع الحي؟
  • إذا كنت ستستخدم --delete، هل تم التحقق من المسار الهدف بدقة؟
  • هل سيتم إجراء اختبارات على حجم الملفات، والأذونات، والتطبيق بعد النقل؟
  • هل سيتم تنظيف النسخ الاحتياطية المؤقتة وملفات التفريغ بشكل آمن؟

قد تبدو هذه الفحوصات بسيطة، ولكن في الواقع، فإن معظم المشكلات الشائعة تنشأ عادةً من مسار الهدف الخاطئ، أو الأذونات المفقودة، أو عدم كفاية مساحة القرص، أو الانتقال غير المخطط لنظام أسماء النطاقات. إن عملية rsync المخططة تقلل من مدة النقل وتزيد من احتمالية العودة.

أسئلة شائعة

إذا انقطع الاتصال أثناء استخدام أمر rsync عبر SSH، هل يبدأ النقل من جديد؟

لا، إذا تم استخدام المعلمات الصحيحة، فلن يبدأ النقل من جديد. تساعد خيارات --partial و --append-verify في حماية الملفات الكبيرة التي لم تكتمل وفي استئناف النقل من النقطة التي توقفت عندها عند إعادة تشغيل الأمر. ومع ذلك، من الجيد التحقق من مساحة القرص الهدف وحالة الملفات الجزئية قبل إعادة تشغيل الأمر في عمليات النقل الحرجة.

هل يمكن نقل قاعدة البيانات مباشرة باستخدام rsync؟

يعمل rsync على نقل الملفات؛ من غير الصحي نسخ ملفات قاعدة البيانات النشطة مباشرة. يجب استخدام mysqldump أو أدوات النسخ الاحتياطي الفيزيائي لـ MySQL أو MariaDB، ثم نقل ملف النسخ الاحتياطي الناتج إلى الخادم الهدف باستخدام rsync. يجب تخطيط وضع الصيانة أو استراتيجية النسخ عند التعامل مع الأنظمة الحية لضمان الاتساق في البيانات.

هل يتطلب استخدام rsync على كلا الخادمين الوصول إلى root؟

ليس من الضروري الوصول إلى root. يكفي أن يكون هناك مستخدم لديه أذونات الكتابة في الدليل الهدف. ومع ذلك، قد يتطلب الأمر صلاحيات أعلى إذا كانت هناك حاجة للحفاظ على ملكية الملفات، أو الدلائل النظامية، أو ACL، أو الأذونات الخاصة. من الأفضل القيام بالعمليات باستخدام مستخدم ذي صلاحيات محدودة قدر الإمكان من الناحية الأمنية.

هل تعتبر معلمة --delete آمنة؟

تعد --delete مفيدة جدًا لمزامنة الهدف مع المصدر عندما يتم استخدامها بشكل صحيح؛ ولكن إذا تم استخدامها في مسار هدف خاطئ، يمكن أن تتسبب في فقدان الملفات. لذلك، يجب دائمًا اختبار الأوامر التي تتضمن --delete باستخدام --dry-run والتأكد من التحقق بعناية من المسارات المصدر والهدف.

هل rsync أفضل من scp في نقل الملفات الكبيرة؟

قد يكون scp كافيًا في عمليات النسخ السريعة لعدد قليل من الملفات؛ لكن في حالة الملفات الكبيرة، أو العديد من الملفات، أو عمليات المزامنة المتكررة، غالبًا ما يكون rsync أفضل. لأنه يمكنه اكتشاف التغييرات في البيانات، واستئناف العمليات المعلقة، وتحديد عرض النطاق الترددي، وتقديم وضع الاختبار.

ملخص والخطوة التالية

يعتبر نقل الملفات الكبيرة بين خادمين باستخدام أمر rsync عبر SSH طريقة سريعة وآمنة وقابلة للإدارة. تصبح العملية مقاومة لانقطاع الاتصال مع المعلمات الصحيحة، وتوفر الوقت من خلال نقل الملفات المتغيرة فقط، وتقلل من الانقطاع في عمليات نقل المواقع الحية. للحصول على أفضل النتائج، قم أولاً بإجراء فحوصات SSH والقرص، واختبر باستخدام --dry-run، ثم خطط لتشغيل النقل الرئيسي بشكل منظم.

إذا كنت تخطط للانتقال إلى خادم جديد، أو تخزين عالي السعة، أو بنية استضافة أكثر أداءً، يمكنك الاطلاع على حلول Hostragons؛ مما يجعل نقل عملية الانتقال أكثر أمانًا من خلال خيارات VPS والاستضافة والنطاقات وSSL بحسب احتياجاتك. ابدأ باختبارات صغيرة، وقياس النتائج، ثم خطط للنقل النهائي بشكل مدروس.

شارك هذا المقال:

فريق Hostragons

نقدم لكم أحدث الأدلة من فريق خبرائنا حول الاستضافة والخوادم وأسماء النطاقات. دعونا نجد الحل الأمثل لمشروعكم معًا.

اتصل بنا