it-swarm.xyz

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

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

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

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

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

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

244
Rory

Я бы использовал 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 flag будет "копировать только в том случае, если файл SOURCE новее, чем целевой файл или отсутствует целевой файл". И -a (архив) будет рекурсивным, а не будет переписывать файлы, если вам нужно перезапустить и сохранить права доступа. Так:

cp -au source dest
214
Hamish Downer

При копировании в локальную файловую систему я склонен использовать 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 -)
120
Ellis Percival

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

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

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

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

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

79
Chad Huneycutt

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

Это тоже хорошо, и продолжается при сбое чтения.

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

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

14
AskApache

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

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

7
innaM

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

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

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

Manpage также говорит это:

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

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

7
John

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

6
oneguynick

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

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

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

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

Полный тест опубликован здесь

6
arjones

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

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

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

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

5
n3bulous

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

3
Ron

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

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

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

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

2
Gonzalo Gorosito

Вы определенно хотите попробовать rclone . Эта вещь сумасшедшая быстро:

Sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Это локальная копия с и на LITEONIT LCS-256 (256GB) SSD.

Можете добавить --ignore-checksum при первом запуске, чтобы сделать его еще быстрее.

1
Frédéric N.

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

0
pauska

Есть несколько ускорений, которые можно применить к rsync:

Избегайте

  • -z/--compress: сжатие будет загружать только процессор, так как передача происходит не по сети, а по ОЗУ.
  • --append-verify: возобновить прерванную передачу. Это звучит как хорошая идея, но имеет опасный случай сбоя: любой файл назначения того же размера (или больше), что и источник, будет игнорироваться. Кроме того, он проверяет суммы всего файла в конце, что означает отсутствие значительного ускорения за --no-whole-file при добавлении опасного случая сбоя.

Использование

  • -S/--sparse: превратить последовательности нулей в разреженные блоки
  • --partial или -P который --partial --progress: сохранить частично переданные файлы для последующего возобновления. Примечание: файлы не будут иметь временного имени, поэтому убедитесь, что больше никто не ожидает использовать место назначения, пока не будет завершена полная копия.
  • --no-whole-file так что все, что нужно отправить, использует дельта-передачу. Чтение половины частично переданного файла часто происходит намного быстрее, чем повторная запись.
  • --inplace, чтобы избежать копирования файла (но только если ничто не читает место назначения, пока не завершится вся передача)
0
Tom Hale

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

0
pgs

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

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

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

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

filepack -y  

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

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

0
herauthon