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

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

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

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

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

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

207 голосов | спросил Rory 20 J000000Monday09 2009, 18:36:34

14 ответов


181

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

rsync -a source dest

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

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

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

cp -au source dest
ответил Hamish Downer 20 J000000Monday09 2009, 18:40:58
87

При копировании в локальную файловую систему я всегда использую следующие параметры 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 -)
ответил Ellis Percival 7 Maypm13 2013, 23:09:48
78

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

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

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

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

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

ответил Chad Huneycutt 20 J000000Monday09 2009, 19:15:34
13

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 -

Обратите внимание, что все они предназначены только для локальных копий.

ответил AskApache 26 FebruaryEurope/MoscowbSun, 26 Feb 2012 21:06:33 +0400000000pmSun, 26 Feb 2012 21:06:33 +040012 2012, 21:06:33
6

rsync -aPhW --protocol=28 помогает ускорить эти большие копии с помощью RSYNC. Я всегда иду rsync, потому что мысль о том, чтобы быть на полпути через 90GiB, и это разбивание меня пугает от CP

ответил oneguynick 20 J000000Monday09 2009, 20:24:51
6

Команда rsync всегда вычисляет контрольные суммы для каждого переданного им байта.

Параметр командной строки --checksum относится только к тому, используются ли контрольные суммы файлов для определения файлов для передачи или нет, например:

  

-c, --checksum пропустить на основе контрольной суммы, а не mod-time & размер "

В manpage также сказано следующее:

  

Обратите внимание, что rsync всегда проверяет, что каждый переданный файл был правильно восстановлен на принимающей стороне, проверив контрольную сумму всего файла, но эта автоматическая проверка после передачи не имеет ничего общего с этой опцией, передача «Нужно ли обновлять этот файл?» проверить.

Так что rsync также всегда вычисляет контрольную сумму всего файла на принимающей стороне, даже если опция -c/ --checksum отключена.

ответил John 28 32012vEurope/Moscow11bEurope/MoscowWed, 28 Nov 2012 05:20:32 +0400 2012, 05:20:32
5

Что бы вы ни выбрали. Просто не забудьте использовать переключатель -a, когда вы решите использовать cp.

Если вам действительно нужен ответ: я бы использовал rsync, потому что он намного более гибкий. Нужно ли завершить работу до завершения копирования? Просто ctrl-c и возобновите работу, как только вы вернетесь. Нужно ли исключать некоторые файлы? Просто используйте --exclude-from. Необходимо изменить права собственности или разрешения? rsync сделает это за вас.

ответил innaM 20 J000000Monday09 2009, 18:40:59
5

rsync замечательный, но имеет проблемы с действительно большими деревьями каталогов, поскольку он хранит деревья в памяти. Я просто смотрел, чтобы устранить эту проблему, когда я нашел эту тему.

Я также нашел:

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

Вы также можете вручную разбить дерево и запустить несколько rsyncs.

ответил n3bulous 20 J000000Monday09 2009, 20:14:37
4

Эта тема была очень полезна и потому, что было так много вариантов для достижения результата, я решил сравнить некоторые из них. Я считаю, что мои результаты могут быть полезны для других, у них есть ощущение того, что работает быстрее.

Чтобы переместить 532Gb из данных, распределенных между 1 753 200 файлами , мы имели те времена:

  • rsync занял 232 минуты
  • tar занял 206 минут
  • cpio занял 225 минут
  • rsync + parallel занял 209 минут

В моем случае я предпочел использовать rsync + parallel. Я надеюсь, что эта информация поможет большему количеству людей решить эти альтернативы.

Полный бенчмарк публикуется здесь

ответил arjones 11 Maypm17 2017, 22:14:58
2

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

ответил Ron 7 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 07 Sep 2011 11:26:19 +0400 2011, 11:26:19
2

ARJ - СТАРЫЙ ШКОЛ !! Я действительно сомневаюсь, что ARJ и /или rsync дадут производительность.

Определенно, что я всегда делаю, используйте cpio:

find . -print | cpio -pdm /target/folder

Это почти быстро, чем CP, определенно быстрее, чем tar, и ничего не работает.

ответил Gonzalo Gorosito 9 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 09 Sep 2012 08:09:46 +0400 2012, 08:09:46
0

Оба будут работать отлично.

ответил pauska 20 J000000Monday09 2009, 18:41:20
0

tar также выполнит задание, но не будет возобновлен из-за прерывания, как это делает rsync.

ответил pgs 20 J000000Monday09 2009, 19:09:24
0

Что делать, если вы используете ARJ?

arj a -jm -m1 -r -je filepack /source

, где -jm -m1 - уровни сжатия, а -je делает его исполняемым. Теперь у вас есть инкапсулированные файлы bash.

Затем для извлечения на целевую карту

filepack -y  

, где будет создана исходная карта (где -y всегда принимает, перезаписывает, пропускает и т. д.)

Затем можно скопировать ftp-файл в целевую область и выполнить его, если это возможно.

ответил herauthon 18 Mayam11 2011, 10:20:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132