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

230

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

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

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

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

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

Рори
источник
2
Если rsync делает именно то, что вы хотите, если вы уже хорошо знакомы с его использованием для данного конкретного приложения, и если он работает достаточно быстро, чтобы удовлетворить ваш вкус, то с какой стати вы захотите переключиться?
одиннадцать81
2
Потому что я обеспокоен тем, что rsync займет больше времени, чем cp, так как rsync делает много контрольных сумм, которые не делает cp
Rory
1
Накладные расходы процессора на контрольную сумму невелики по сравнению с дисковым / сетевым вводом-выводом. Если диск не находится в той же системе, и ОС не может сделать некоторую умную копию привода диска в контроллере шины.
Мартин Беккет
3
Контрольная сумма выполняется для файлов, которые отличаются по размеру и проверке временных меток. Если вы параноик (например, после отключения питания во время копирования), вы можете принудительно установить контрольную сумму для всех файлов, но при локальной передаче это обычно медленнее, чем начинать с нуля.
korkman
3
Может быть, ему любопытно улучшить свой рабочий процесс, и он не прячет голову в песке, думая, что знает все. Этот комментарий действительно раздражает меня.
Мартин Конечни

Ответы:

204

Я бы использовал 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
Хэмиш Даунер
источник
5
Флаг -u cp, вероятно, не лучшее решение, так как он не обнаружит частично скопированный / поврежденный файл. Хорошая вещь о rsync в том, что вы можете использовать md5 для суммирования файлов, чтобы обнаружить различия.
Чад Хьюникутт
3
Добавление опции -w (--whole-file) ускорит прерывистую rsync, так как она просто скопирует файл вместо контрольной суммы.
Хаялчи
13
На самом деле, rsync обнаруживает локальные передачи и включает автоматическое копирование всего файла без контрольной суммы.
korkman
22
и - прогресс, который действительно удобен!
Мэтт
12
-P или --progress показывает прогресс для каждого файла в отдельности. Это полезно для копирования больших файлов, а не для многих (тысяч) маленьких файлов, так как это означает гораздо больший вывод, который вы не можете прочитать. Он не показывает общий прогресс всех файлов вместе взятых.
СПРБРН
106

При копировании в локальную файловую систему я всегда использую следующие параметры 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 -)
Эллис Персиваль
источник
1
У меня rsync: --no-compress: unknown optionпоявляется следующая ошибка: @Ellis Percival.
Alper
Это молниеносно. Быстрее сделать это, чем rm -rf /src/.
КГВР
2
Как и @alper, --no-compress не был опцией для моей версии rsync (в CentOS 7); Вместо этого я использовал --compress-level = 0.
Пол
79

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

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

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

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

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

Чад Хунейкутт
источник
6
+1 Я обнаружил, что tar обычно быстрее для больших копий, чем rsync. Мне также нравится идея завершить финальный rsync.
Джефф Фриц
2
tar - хороший выбор, если каталог dest пуст. Хотя мой путь был бы: cd $ DSTDIR; tar c -C $ SRCDIR. | tar
asdmin
19
В этом прелесть этого метода. Вам не нужно удваивать пространство, потому что вы никогда не создаете промежуточный файл tar. Tar перед конвейером упаковывает данные и передает их в stdout, а tar после конвейера извлекает их из stdin и распаковывает.
Чад Хьюникутт
4
Я сделал cp -a для передачи 12 ГБ, и этот метод для передачи 42 ГБ. Метод tar занял около 1/4 времени.
Нгаида
3
Я также положил pvв середину, чтобы иметь возможность наблюдать за прогрессом, оценивая размер всех данных, используемых df. Я также использовал --numeric-owner, так как исходный диск был из другой системы, и я не хотел tarсвязываться с владельцами:tar -C /old-path --numeric-owner -S -c . | pv -tpeba -s 100G | tar -C /new-path --numeric-owner -S -xp
Петр Пудлак
14

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 -

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

AskApache
источник
Почему вы используете флаги -S и -D для rsync?
miyalys
7

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

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

InnaM
источник
Что снова делает флаг -p?
Рори
1
Это сохранит права собственности, временные метки и разрешения.
ИннаМ
5
CP-а будет лучше.
Дэвид Пашли
На самом деле. Ответ изменился соответственно.
ИннаМ
7

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

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

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

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

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

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

Джон
источник
14
В то время как ваш пост добавил сюда некоторую интересную информацию, недовольство и оскорбления снижают ценность вашего поста. Этот сайт не является форумом для неконструктивных пустяков. Если вы смогли изменить исходный код, отправили ли вы свои модификации в виде патча? Вы разместили свою версию на GitHub или что-то? Если вы так сильно настроены по этому поводу, возможно, было бы лучше, если бы вы попытались сделать что-то более конструктивное, а не безосновательно оскорблять.
Зоредаче
Да, последний абзац не был действительно необходим.
Шервин Рейс
6

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

oneguynick
источник
2
Какова ценность использования старого протокола в этой командной строке?
ewwhite
1
На компьютере Mac старая версия поставляемой Rsync зависает на некоторых новых версиях протокола rsync, таких как 29. При указании перехода на более старый протокол он НЕ проверяется снова и снова.
oneguynick
Я думаю, что номер 28 больше не действителен?
СПРБРН
5

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

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

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

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

n3bulous
источник
12
Если вы используете версию 3, она не сохраняет все дерево в памяти, если оно большое, она использует алгоритм инкрементной рекурсии: samba.org/ftp/rsync/src/rsync-3.0.0-NEWS
Кайл Брандт,
5

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

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

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

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

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

arjones
источник
404 страница не найдена
Амеди Ван Гасс
1
Спасибо @AmedeeVanGasse URL был исправлен вскоре после того, как вы сообщили :)
arjones
Почему не бенчмаркинг cp? Это название вопроса!
Calandoa
@calandoa Я думаю, что cpэто небезопасно, то есть: когда перерывы, вы должны начать все сначала, поэтому я предпочитаю варианты, которые могут возобновиться, поэтому rsyncмой любимый
вариант
3

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

Рон
источник
2

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

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

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

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

Гонсало Горосито
источник
2
«Оригинальные утилиты cpio и find были написаны Диком Хейтом во время работы в группе поддержки Unix AT & T. Они впервые появились в 1977 году в PWB / UNIX 1.0» - справочная cpioстраница FreeBSD .
Крис С
3
cpioк сожалению, верхний предел для файлов составляет 8 ГБ.
" ничего не пуская по трубам " [sic]. Кроме findкоманды, как вы ее перечислили, в ней есть труба:find . -print | cpio -pdm /target/folder
Уоррен
1

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

Фредерик Н.
источник
0

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

pauska
источник
0

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

PGS
источник
Старый ответ, но не TAR для создания сжатых архивов файлов? Как это можно использовать для передачи файлов, таких как rsync или cp?
Шервин Рейс
@SherwinFlight cd source; см см. | (cd dest; tar xf -)
pgs
0

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

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

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

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

filepack -y  

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

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

herauthon
источник
1
Arj? Разве это не вымерло в 80-х?
Майкл Хэмптон
может быть, в начале 90-х, если верить википедии
Мэтт
0

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

избежать

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

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

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