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

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

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

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

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

Так что ты считаешь, rsync или же cp?

14 ответов

Решение

Я бы использовал 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

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

cp -au source dest

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

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы определенно хотите попробовать 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).

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

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

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

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

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

filepack -y  

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

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

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

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

Другие вопросы по тегам