Вопрос: Копирование большого дерева каталогов локально? cp или rsync?


Мне нужно скопировать большое дерево каталогов, около 1,8 ТБ. Это все локально. По привычке я бы использовал rsync, однако мне интересно, есть ли много смысла, и если я предпочитаю использовать cp,

Меня беспокоят разрешения и uid / gid, так как они должны быть сохранены в копии (я знаю, что rsync делает это). А также такие вещи, как символические ссылки.

Пункт назначения пуст, поэтому мне не нужно беспокоиться об условном обновлении некоторых файлов. Это все локальный диск, поэтому мне не нужно беспокоиться о ssh или сети.

Причина, по которой я соблазняюсь от rsync, заключается в том, что rsync может сделать больше, чем мне нужно. rsync контрольные суммы файлов. Мне это не нужно, и я обеспокоен тем, что это может занять больше времени, чем cp.

Итак, что вы считаете, rsync или cp?


209
2017-07-20 14:36


Источник


Если rsync делает именно то, что вы хотите, если вы уже знакомы с его использованием для этого конкретного приложения, и если он функционирует достаточно быстро, чтобы удовлетворить ваш вкус, то почему вы хотите переключиться? - eleven81
Потому что я обеспокоен тем, что rsync займет больше времени, чем cp, так как rsync делает много контрольных сумм, которые cp не будет делать - Rory
Средние затраты процессора на контрольную сумму малы по сравнению с дисковым / сетевым вводом / выводом. Если диск не находится в одной и той же системе, и ОС может сделать некоторую умную копию накопителя в контроллере шины. - Martin Beckett
Checksumming выполняется в файлах, которые отличаются по размеру и отметке времени. Если вы параноик (например, после отключения питания во время копирования), вы можете принудительно выполнить контрольную сумму во всех файлах, но при локальном переносе это обычно медленнее, чем начинать с нуля. - korkman
Может быть, ему любопытно улучшить его рабочий процесс, и он не зарывает голову в песок, думая, что он все знает. Этот комментарий меня действительно раздражает. - Martin Konecny


Ответы:


Я бы использовал rsync, так как это означает, что если он по какой-либо причине прерывается, вы можете легко перезапустить его с минимальными затратами. И будучи rsync, он может даже перезапустить часть пути через большой файл. Как отмечают другие, он может легко удалять файлы. Самый простой способ сохранить большинство вещей - использовать -a флаг - «архив». Итак:

rsync -a source dest

Хотя UID / GID и символические ссылки сохраняются -a (видеть -lpgo), ваш вопрос подразумевает, что вы, возможно, захотите полный копирование информации о файловой системе; а также -a не включает жесткие ссылки, расширенные атрибуты или списки ACL (в Linux) или выше ни (на OS X.) Таким образом, для надежной копии файловой системы вам необходимо включить эти флаги:

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

Значение cp по умолчанию начнется снова, хотя -u флаг будет «копировать только тогда, когда файл SOURCE является более новым, чем файл назначения или когда отсутствует файл назначения», И -a (архив) будет рекурсивным, а не recopy-файлами, если вам нужно перезапустить и сохранить разрешения. Так:

cp -au source dest

182
2017-07-20 14:40



Флаг -u cp, вероятно, не самый лучший вариант, так как он не обнаружит частично скопированный / поврежденный файл. Хорошая вещь о rsync заключается в том, что вы можете заставить его md5 суммировать файлы для обнаружения различий. - Chad Huneycutt
Добавление опции -w (-whole-file) ускорит прерывание rsync, поскольку оно просто скопирует файл вместо контрольных сумм. - hayalci
на самом деле, rsync обнаруживает локальные передачи и позволяет полностью копировать полный файл без контрольной суммы автоматически. - korkman
и -progress, который действительно удобен! - Matt
-P или --progress показывает прогресс для каждого файла отдельно. Он полезен для копирования больших файлов, а не для многих (тысяч) небольших файлов, так как это означает, что вы получаете больше информации, которую вы не можете прочитать. Он не показывает общий прогресс всех файлов в сочетании. - 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 -)

87
2018-05-07 19:09



У меня возникла следующая ошибка: rsync: --no-compress: unknown option @ Эллис Персиваль. - 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 -)

Обычно с большим количеством файлов будет некоторая проблема, с которой tar не может справиться по какой-либо причине. Или, может быть, процесс прервется, или если это миграция файловой системы, вы можете захотеть сделать первоначальную копию до фактического этапа миграции. Во всяком случае, после первоначальной копии, я делаю шаг rsync, чтобы синхронизировать все это:

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

Обратите внимание, что конечная косая черта /src/ это важно.


78
2017-07-20 15:15



+1 Я нашел tar, как правило, быстрее для больших копий, чем rsync. Мне нравится идея закончить окончательный rsync. - Geoff Fritz
tar - хороший выбор, если каталог dest пуст. Хотя мой путь был бы: cd $ DSTDIR; tar c -C $ SRCDIR. | деготь - asdmin
В этом красота этого метода. Вам не нужно удваивать пространство, потому что вы никогда не создаете промежуточный файл tar. Дегтя до того, как труба упаковывает данные и передает их в стандартный вывод, а tar после того, как труба захватывает его из stdin и распаковывает. - Chad Huneycutt
Я сделал cp -a для передачи 12gb, и этот метод для передачи 42gb. Метод смолы занял около 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

Я использую 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
На машине Mac старшая версия 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
Это будет сохранение владельца, временные метки и разрешения. - 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
Благодаря URL-адресу @AmedeeVanGasse исправлено короткое сообщение после того, как вы сообщили :) - arjones
Почему не бенчмаркинг cp? Это название вопроса! - calandoa
@calandoa Я думаю cp небезопасно, то есть: когда он ломается, вам нужно начинать сначала, вот так я предпочитаю варианты, которые могут возобновиться, ergo rsync мой любимый :) - arjones


Когда я делаю локальную копию локального каталога, мой опыт в том, что «cp -van src dest» на 20% быстрее, чем rsync. Что касается перезапуска, это то, что делает «-n». Вам просто нужно скопировать частично скопированный файл. Не больно, если это не ISO, а другое.


2
2017-09-07 07:26