Меня смущают преимущества rsync (3.1.1), если нет удаленного демона, например копирование с диска, смонтированного по SMB2 (через VPN), на внешний жесткий диск (к сожалению, USB 2.0). Оба соединения медленные (а мои данные составляют ~ 1 ТБ), но я не понимаю, как сжатие или тщательное сравнение могут ускорить работу, если все это требует, чтобы мой процессор считывал данные в первую очередь, нет? Оба диска в этом смысле локальны. (Я не могу заменить SMB-соединение на SSH через rsync, так как он не может обрабатывать мой пароль.) Или даже с удаленным диском, я не понимаю, как rsync может творить чудеса, если на другом конце никто не выполняет сжатие до того, как данные попадают в локальный процессор.
Подходит ли это для такой копии? rsync -vhcrC --progress src dest
-c: Maybe checksums are a bad idea, file size and timestamp might be the only thing rsync can check without loading the data in in the first place.
-h: human-readable output
-v: verbose
-C: skipping what CVS skips
опуская:
-a: I am not interested in archiving, as files move from Windows to mac, permissions will change anyway, I think
-z: this is the compression issue
-W: sometimes copying whole-files-only use less of the CPU, but some files are really big here (~100GB), and an interrupted transfer is better restarted
Примечание: все нижеизложенное выходит за рамки теории - настоящий правильный способ убедиться, что это правильно в вашей ситуации, - это запустить тесты с различными комбинациями параметров.
Подключения к данным в операции rsync выглядят примерно так:
Source disk <-> rsync instance <-> other rsync instance <-> destination disk
В общем, rsync разработан для случая, когда первая и последняя ссылки (между экземплярами rsync и их дисками) являются быстрыми, а средняя ссылка (между экземплярами rsync) медленными. Особенно это касается -z (сжатие) и -c (файлы контрольной суммы, чтобы решить, что передать); в ситуации, когда оба rsync находятся на одном компьютере (следовательно, при быстром подключении), эти параметры в основном не имеют смысла.
Более конкретно: -z опция сжимает данные по среднему каналу, компенсируя более высокую нагрузку на ЦП на обоих концах ради более низкой пропускной способности на среднем канале. Если средняя ссылка работает быстро, сэкономьте CPU, пропустив эту опцию.
Для -c параметр, это заставляет оба rsyncs читать все файлы, которые не нужно синхронизировать полностью, чтобы действительно убедитесь их не нужно синхронизировать. Если одна или обе дисковые ссылки работают медленно и есть много файлов, которые уже синхронизированы, это пропорционально замедлит процесс. Если вам не нужно беспокоиться об изменении содержимого файлов без изменения их временных меток, вам следует избегать этого. Обратите внимание, что опускание этого не имеет большого смысла, если вы также не добавите -t вариант (или -a), поэтому он будет копировать временные метки - без них ему все равно придется все сравнивать.
Вы также можете добавить -W вариант (просто скопируйте файлы целиком, пропустите сравнение и поиск только изменений), так как это позволит избежать дополнительного чтения измененных файлов. Однако в этом, вероятно, нет необходимости, поскольку все версии rsync, с которыми я знаком, делают это автоматически, когда и источник, и место назначения указаны как локальные пути (что должно применяться, даже если один из этих локальных путей находится в сети. точка крепления).
Краткое содержание: удалить -c, Добавить -t и возможно -W.