Мне нужно скопировать большое дерево каталогов, около 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 флаг будет "копировать только в том случае, если файл ИСТОЧНИК новее, чем файл назначения, или когда файл назначения отсутствует". И -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, который я использую, я предпочитаю cp для простых команд, а не this.
$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/
Вот способ, который еще безопаснее, 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пропускать на основе контрольной суммы, а не времени модификации и размера "
На странице руководства также говорится следующее:
Обратите внимание, что rsync всегда проверяет, что каждый переданный файл был правильно реконструирован на принимающей стороне, проверяя его контрольную сумму всего файла, но эта автоматическая проверка после передачи не имеет ничего общего с этой опцией перед передачей "Требуется ли этот файл быть обновленным?" чек.
Так rsync также всегда вычисляет контрольную сумму всего файла на принимающей стороне, даже если -c/ --checksum опция "выключена".
Эта ветка была очень полезной, и, поскольку было так много вариантов для достижения результата, я решил протестировать несколько из них. Я считаю, что мои результаты могут быть полезны другим, я понимаю, что сработало быстрее.
Двигаться 532 ГБ данных, распределенных между 1,753,200 файлов у нас были те времена:
rsync заняло 232 минутыtar заняло 206 минутcpio заняло 225 минутrsync + parallel заняло 209 минутВ моем случае я предпочел использовать rsync + parallel. Я надеюсь, что эта информация поможет большему количеству людей выбрать между этими альтернативами.
Публикуется полный тест Вот
Что вы предпочитаете. Только не забывай -a переключитесь, когда вы решите использовать cp.
Если вам действительно нужен ответ: я бы использовал rsync, потому что он намного более гибкий. Необходимо завершить работу до завершения копирования? Просто ctrl-c и возобновите, как только вернетесь. Нужно исключить некоторые файлы? Просто используйте --exclude-from. Необходимо изменить владельца или разрешения? rsync сделает это за вас.
rsync -aPhW --protocol=28 помогает ускорить создание больших копий с помощью RSYNC. Я всегда использую rsync, потому что мысль о том, что я нахожусь на полпути через 90GiB, и это ломается, пугает меня от CP
rsync хорош, но имеет проблемы с действительно большими деревьями каталогов, потому что он хранит деревья в памяти. Я просто хотел посмотреть, решат ли они эту проблему, когда нашел эту ветку.
Я также нашел:
http://matthew.mceachen.us/geek/gigasync/
Вы также можете вручную разбить дерево и запустить несколько rsync.
По моему опыту, при выполнении локального копирования в локальный каталог "cp -van src dest" на 20% быстрее, чем rsync. Что касается возможности перезапуска, это то, что делает "-n". Вам просто нужно rm частично скопированный файл. Не больно, если это не ISO или что-то в этом роде.
АРДЖ ТАК СТАРШАЯ ШКОЛА !! Я действительно сомневаюсь, что ARJ и / или rsync дадут производительность.
Конечно, я всегда использую cpio:
find . -print | cpio -pdm /target/folder
Это почти быстро, чем CP, определенно быстрее, чем tar, и без конвейерной обработки.
Для тех, кому нужно скопировать большое количество небольших файлов между двумя локальными монтировками (в моем случае это были два монтирования NFS службы NAS от облачного провайдера):
cp было мучительно медленно. Наблюдая за пропускной способностью сети, я увидел, что пропускная способность может достигать только 1 Мбит / с. Затем я попробовал использовать tar:
tar -pc /mnt/old-nas | tar -xpf - -C /mnt/new-nas
который мог полностью заполнить линию, между 250-300 Мбит / с.
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 (256 ГБ) и на него.
Можете добавить --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 чтобы избежать копирования файла (но только если ничего не читает место назначения, пока не завершится вся передача)Если оба хранилища локальные, cp должен передавать данные с максимально возможной скоростью. Нет необходимости использовать синхронизатор, если целевой каталог пуст, но он дает такие преимущества, как возможность перезапуска, возможность исключить определенные файлы и т. Д.
rsync хорош в копировании по сети (дельта-передача больших файлов). Но rsync хранит свои внутренние данные в памяти, что может вызвать проблемы с огромными деревьями каталогов.
Если вас интересует другой синхронизатор, вы можете взглянуть на Фитус / Zaloha.sh. Это работает найти в обоих каталогах и готовит сценарии с cp команды. Он хранит свои внутренние данные в файлах, а не в памяти. Он используется следующим образом:
$ Zaloha.sh --sourceDir="test_source" --backupDir="test_backup"
Если вы хотите, чтобы он просто генерировал cp скрипт (но не выполнять его, что потребовало бы обширного отображения и взаимодействия), используйте параметр --noExec.
Предположительно, ваш вариант использования не требует создания сценариев восстановления: используйте параметр --noRestore. Наконец, если у вас есть пост пасть установлен, используйте его с помощью опции --mawk.