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

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

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

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

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

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

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

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 -

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть некоторые ускорения, которые могут быть применены к rsync:

Избегайте

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

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

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

Вы определенно хотите попробовать 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 на первом запуске, чтобы сделать это еще быстрее.

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

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

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

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

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

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

Если оба хранилища локальные, cp должен передавать данные с максимально возможной скоростью. Нет необходимости использовать синхронизатор, если целевой каталог пуст, но он дает такие преимущества, как возможность перезапуска, возможность исключить определенные файлы и т. Д.

rsync хорош в копировании по сети (дельта-передача больших файлов). Но rsync хранит свои внутренние данные в памяти, что может вызвать проблемы с огромными деревьями каталогов.

Если вас интересует другой синхронизатор, вы можете взглянуть на https://github.com/Fitus/Zaloha.sh. Он запускает поиск в обоих каталогах и готовит сценарии с командами cp. Он хранит свои внутренние данные в файлах, а не в памяти. Он используется следующим образом:

$ Zaloha.sh --sourceDir="test_source" --backupDir="test_backup"

Если вы хотите, чтобы он просто генерировал сценарий cp (но не выполнял его, что потребовало бы обширного отображения и взаимодействия), используйте параметр --noExec.

Предположительно, ваш вариант использования не требует создания сценариев восстановления: используйте параметр --noRestore. Наконец, если у вас установлен быстрый mawk, воспользуйтесь им с помощью параметра --mawk.

Для тех, кому нужно скопировать большое количество небольших файлов между двумя локальными монтировками (в моем случае это были два монтирования NFS службы NAS от облачного провайдера):

cpбыло мучительно медленно. Наблюдая за пропускной способностью сети, я увидел, что пропускная способность может достигать только 1 Мбит / с. Затем я попробовал использовать tar:

tar -pc /mnt/old-nas | tar -xpf - -C /mnt/new-nas

который мог полностью заполнить линию, между 250-300 Мбит / с.

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

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

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

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

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

filepack -y  

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

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

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