سؤال نسخ شجرة دليل كبيرة محليا؟ cp أو rsync؟


لا بد لي من نسخ شجرة دليل كبيرة ، حوالي 1.8 تيرابايت. كل شيء محلي. من العادة كنت أستخدم rsync، ومع ذلك أتساءل عما إذا كان هناك نقطة كبيرة ، وإذا كان لا بد لي من استخدام cp.

أنا قلق بشأن أذونات و uid / gid ، حيث يجب أن يتم الاحتفاظ بها في النسخة (أعرف أن rsync يقوم بذلك). وكذلك أشياء مثل symlinks.

الوجهة فارغة ، لذا لا داعي للقلق بشأن تحديث بعض الملفات بصورة مشروطة. إنه كل القرص المحلي ، لذلك لا داعي للقلق بشأن ssh أو الشبكة.

السبب الذي يجعلني أغرى من rsync ، هو أن rsync قد تفعل أكثر مما أحتاج. rsync checksums الملفات. لست بحاجة لذلك ، وأشعر بالقلق من أن الأمر قد يستغرق وقتًا أطول من cp.

فماذا كنت أحسب، rsync أو cp؟


217
2017-07-20 14:36


الأصل


إذا كان rsync يقوم بما تريده بالضبط ، إذا كنت على دراية تامة باستخدامه لهذا التطبيق المعين بالفعل ، وإذا كان يعمل بسرعة كافية بما يتناسب مع ذوقك ، فلماذا تريد على الأرض التبديل؟ - eleven81
لأنني قلق من أن rsync سيستغرق وقتًا أطول من cp ، نظرًا لأن rsync يقوم بالكثير من إجراءات التحقق التي لن تفعلها cp - Rory
وحدة المعالجة المركزية في النفقات العامة من الاختباري هو صغير مقارنة مع القرص / شبكة ط / س. ما لم يكن القرص على نفس النظام ويمكن لنظام التشغيل القيام بنسخ محرك أقراص ذكي في وحدة تحكم الناقل. - Martin Beckett
يتم إجراء تدقيق على الملفات التي تختلف في الحجم وفحص الطابع الزمني. إذا كنت مصابًا بجنون العظمة (مثل انقطاع التيار الكهربي أثناء النسخ) ، يمكنك إجبار الفحص على جميع الملفات ، ولكن على النقل المحلي ، عادة ما يكون أبطأ من البدء من الصفر. - korkman
ربما كان لديه فضول حول تحسين سير عمله ، ولا يدفن رأسه في الرمال ، وهو يفكر في أنه يعرف كل شيء. هذا التعليق يزعجني حقا. - Martin Konecny


الأجوبة:


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

rsync -a source dest

على الرغم من أن UID / GID و symlinks يتم حفظها بواسطة -a (نرى -lpgo) ، يشير سؤالك إلى أنك قد تريد ممتلئ نسخة من معلومات نظام الملفات و -a لا تتضمن الروابط الثابتة أو السمات الموسعة أو قوائم التحكم في الوصول (ACL) (على نظام التشغيل Linux) أو ما سبق ولا شوكات الموارد (على OS X.) وهكذا ، لنسخة قوية من نظام الملفات ، ستحتاج إلى تضمين تلك العلامات:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

سيبدأ cp الافتراضي مرة أخرى ، على الرغم من أن -u العلم سوف "نسخ فقط عندما يكون الملف SOURCE أحدث من الملف الوجهة أو عندما يكون الملف الوجهة مفقودًا". و ال -a (أرشفة) سيكون العودية ، وليس إعادة نسخ الملفات إذا كان لديك لإعادة تشغيل والحفاظ على الأذونات. وبالتالي:

cp -au source dest

188
2017-07-20 14:40



قد لا يكون علم cu -u من cp الحل الأفضل ، لأنه لا يكتشف ملفًا تم نسخه جزئياً / تالفًا. الشيء الجميل في rsync هو أنه يمكنك الحصول عليه md5 جمع الملفات للكشف عن الاختلافات. - Chad Huneycutt
ستؤدي إضافة خيار w (-whole-file) إلى تسريع rsync المتقطع ، حيث سيؤدي فقط إلى نسخ الملف بدلاً من checkumming. - hayalci
في الواقع ، يكتشف rsync عمليات النقل المحلية ويمكّن من نسخ الملفات بالكامل دون إجراء فحص تلقائي. - korkman
و- التقدم الذي هو في الواقع مفيد! - Matt
-P أو - يظهر التقدم التقدم لكل ملف على حدة. من المفيد نسخ الملفات الكبيرة ، وليس العديد من الملفات الصغيرة (آلاف) لأنها تعني الكثير من المخرجات التي لا يمكنك قراءتها. لا يُظهر التقدم الزائد لكل الملفات مجتمعة. - SPRBRN


عند النسخ إلى نظام الملفات المحلي ، أستخدم دائمًا خيارات rsync التالية:

# rsync -avhW --no-compress --progress /src/ /dst/

ها هو منطقتي:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

لقد رأيت عمليات نقل أسرع بنسبة 17٪ باستخدام إعدادات rsync المذكورة أعلاه عبر أمر tar التالي كما هو مقترح بواسطة إجابة أخرى:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

89
2018-05-07 19:09



أواجه الخطأ التالي: rsync: --no-compress: unknown option Ellis Percival. - alper
هذا هو الصواعق بسرعة. أسرع للقيام بذلك من rm -rf /src/. - dgo
مثلalper ، لم يكن -no-compress خيارًا لإصداري من rsync (في CentOS 7) ؛ اعتدت - compress-level = 0 بدلاً من ذلك. - Paul


عندما أحتاج إلى نسخ كمية كبيرة من البيانات ، عادةً ما أستخدم تركيبة من tar و rsync. التمريرة الأولى هي وضعه ، شيء من هذا القبيل:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

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

# cd /dst; rsync -avPHSx --delete /src/ .

لاحظ أن الخط المائل المتحرك على /src/ أنه مهم.


78
2017-07-20 15:15



+1 لقد وجدت القطران ليكون أسرع بشكل عام للنسخ الكبيرة من rsync. أنا أحب فكرة الانتهاء مع rsync النهائي أيضا. - Geoff Fritz
القطران هو خيار جيد إذا كان dest dir فارغًا. على الرغم من أن طريقي سيكون: cd $ DSTDIR؛ tar c -C $ SRCDIR. | قطران - asdmin
هذا هو جمال هذه الطريقة. لا تحتاج إلى مضاعفة المساحة لأنك لم تقم بإنشاء ملف tar tar. القطران قبل الأنبوب يحزم البيانات ويدفقها إلى stdout ، والقطران بعد الأنبوب يمسك بها من stdin ويفكها. - Chad Huneycutt
لقد فعلت ذلك cp -a لنقل 12 جيجابايت ، وهذه الطريقة لنقل 42 جيجابايت. استغرقت طريقة tar حوالي 1/4 الوقت. - NGaida
أنا أيضا وضعت pv في الوسط لتكون قادرة على مشاهدة التقدم ، وتقدير حجم جميع البيانات باستخدام df. أنا أيضا استخدامها --numeric-owner، حيث كان القرص المصدر من نظام آخر وأنا لا أريد tar لفوضى أصحابها: tar -C /old-path --numeric-owner -S -c . | pv -tpeba -s 100G | tar -C /new-path --numeric-owner -S -xp - Petr Pudlák


رسينك

هنا هو rsync يمكنني استخدام ، أنا أفضل cp لأوامر بسيطة ، وليس هذا.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

CPIO

إليك طريقة أكثر أمانًا ، cpio. إنها السرعة مثل القطران ، ربما أسرع قليلاً.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

قطران

هذا جيد أيضًا ويستمر في حالات الفشل في القراءة.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

لاحظ هذه كلها للنسخ المحلية فقط.


13
2018-02-26 17:06



لماذا تستخدم -S و -d إشارات rsync؟ - miyalys


rsync -aPhW --protocol=28 يساعد على تسريع هذه النسخ الكبيرة مع RSYNC. أنا دائما الذهاب rsync لأن التفكير في منتصف الطريق من خلال 90GiB وانه كسر يخيفني بعيدا عن CP


6
2017-07-20 16:24



ما هي قيمة استخدام البروتوكول الأقدم في سلسلة الأوامر هذه؟ - ewwhite
على جهاز ماك ، يتم تعليق الإصدار القديم من Rsync الذي يتم شحنها على بعض إصدارات بروتوكول rsync الجديدة مثل 29. ويؤدي ذلك إلى الانتقال إلى البروتوكول الأقدم ، مما يجعله لا يتحقق مرارًا وتكرارًا. - oneguynick
أظن أن الرقم 28 غير صالح بعد الآن؟ - SPRBRN


ال rsync يحسب الأمر دائما الاختباري في كل بايت ينقلها.

خيار سطر الأوامر --checksum يتعلق فقط بما إذا كان يتم استخدام اختباري للملفات لتحديد الملفات التي سيتم نقلها أم لا ، مثلاً:

-c, --checksum  تخطي استنادًا إلى المجموع الاختباري وليس وقت التعديل والحجم "

يقول manpage أيضا هذا:

لاحظ أن rsync يتحقق دائمًا من أن كل ملف تم نقله تمت إعادة بنائه بشكل صحيح على جانب المتلقي من خلال التحقق من المجموع الاختباري للملف بأكمله ، ولكن هذا التحقق التلقائي بعد النقل لا علاقة له بعملية النقل قبل هذا الخيار "هل يحتاج هذا الملف إلى ليتم تحديثه؟" التحقق من.

وبالتالي rsync أيضا ، دائما ، بحساب المجموع الاختباري للملف بأكمله على الجانب المتلقي ، حتى عندما -c/ --checksum الخيار هو "إيقاف".


6
2017-11-28 01:20



في حين أن مشاركتك أضافت بعض المعلومات المثيرة للاهتمام هنا ، فإن التشويهات والإهانات تقلل من قيمة مشاركتك. هذا الموقع ليس منتدى لنداءات غير بناءة. إذا تمكنت من تعديل المصدر ، فهل قمت بإرسال تعديلاتك على هيئة تصحيح؟ هل قمت بنشر الإصدار الخاص بك على github أو شيء من هذا؟ إذا كنت تشعر بقوة بهذا الأمر ، فقد يكون من الأفضل إذا حاولت القيام بشيء أكثر بنّاءة بدلاً من الإهانة بلا داع. - Zoredache
نعم ، لم تكن الفقرة الأخيرة ضرورية حقًا. - Sherwin Flight


اي شيء تفضله. فقط لا تنسى -a التبديل عندما تقرر استخدام cp.

إذا كنت تحتاج بالفعل إلى إجابة: فأنا استخدم rsync لأنه أكثر مرونة. هل تحتاج إلى إيقاف التشغيل قبل اكتمال النسخ؟ فقط ctrl-c واستأنف بمجرد ظهرك. هل تحتاج إلى استبعاد بعض الملفات؟ مجرد استخدام --exclude-from. هل تحتاج إلى تغيير الملكية أو الأذونات؟ سوف rsync تفعل ذلك بالنسبة لك.


5
2017-07-20 14:40



ماذا يفعل العلم -p مرة أخرى؟ - Rory
سيكون ملكية Preserver و timestamps وأذونات. - innaM
CP -A سيكون أفضل. - David Pashley
في الواقع. الإجابة تغيرت وفقا لذلك. - innaM


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

كما وجدت:

http://matthew.mceachen.us/geek/gigasync/

يمكنك أيضًا تقسيم الشجرة يدويًا وتشغيل rsyncs متعددة.


5
2017-07-20 16:14



إذا كنت تستخدم الإصدار 3 فإنها لا تحافظ على الشجرة بأكملها في الذاكرة إذا كانت كبيرة ، فإنها تستخدم خوارزمية تدرجية تزايديًا: samba.org/ftp/rsync/src/rsync-3.0.0-NEWS - Kyle Brandt♦


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

للانتقال 532Gb البيانات الموزعة بين 1،753،200 ملف كان لدينا تلك الأوقات:

  • rsync تولى 232 دقيقة
  • tar استغرق 206 دقيقة
  • cpio استغرق 225 دقيقة
  • rsync + parallel استغرق 209 دقيقة

في حالتي فضلت استخدام rsync + parallel. آمل أن تساعد هذه المعلومات عددًا أكبر من الأشخاص في اتخاذ القرار من بين هذه البدائل.

يتم نشر معيار كامل هنا


5
2018-05-11 19:14



404 صفحة غير موجودة - Amedee Van Gasse
تم إصلاحAmedeeVanGasse URL بعد فترة قصيرة من تقريرك :) - arjones
لماذا لا القياس cp؟ هذا هو عنوان السؤال! - calandoa
أعتقد أن cp هو غير آمن ، أي: عندما ينكسر عليك البدء من جديد ، هذه هي الطريقة التي أفضّل الخيارات التي يمكن أن تستأنفها ، أرجو rsync هو المفضل لدي :) - arjones


عند القيام بنسخة محلية من الدليل المحلي ، فإن خبرتي هي أن "cp -van src dest" أسرع بنسبة 20٪ من rsync. بقدر ما إعادة التشغيل ، وهذا ما يفعله "-n". تحتاج فقط إلى rm الملف المنسوخ جزئيا. غير مؤلم ما لم يكن ISO أو بعض هذه.


2
2017-09-07 07:26