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

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

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

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

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

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

Я бы использовал 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флаг (архив) будет рекурсивным, а не переписывает файлы, если вам придется перезапускать и сохранять разрешения. Так:

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всегда вычисляет контрольные суммы для каждого передаваемого байта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

filepack -y  

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

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

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

избежать

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

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

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