Какой самый быстрый и надежный способ передачи большого количества файлов?

Я пытаюсь передать около 100 тыс. Файлов общим объемом 90 Гб. Прямо сейчас я использую демон rsync, но он медленный 3.4mb / s, и мне нужно делать это несколько раз. Мне интересно, какие у меня есть варианты, которые позволили бы максимально использовать 100-битное соединение через Интернет и были бы очень надежными.

Вы рассматривали Sneakernet ? При больших наборах данных доставка за ночь часто происходит быстрее и дешевле, чем через Интернет.

Как? Или TL; DR

Самый быстрый метод , который я нашел это сочетание tar, mbufferи ssh.

Например:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Благодаря этому я добился устойчивой передачи по локальной сети со скоростью более 950 Мбит / с по каналам 1 Гбит. Замените пути в каждой команде tar, чтобы они соответствовали тому, что вы переносите.

Почему? mbuffer!

Самым большим узким местом в передаче больших файлов по сети является, безусловно, дисковый ввод-вывод. Ответ на это mbufferили buffer. Они во многом похожи, но mbufferимеют некоторые преимущества. Размер буфера по умолчанию составляет 2 МБ для mbufferи 1 МБ для buffer. Большие буферы, скорее всего, никогда не будут пустыми. Выбор размера блока, который является наименьшим общим кратным собственного размера блока как в целевой, так и в целевой файловой системе, даст наилучшую производительность.

Буферизация это то , что делает все различия! Используйте это, если у вас есть это! Если у вас его нет, получите! Использование (m}?bufferплюс что-либо лучше, чем все само по себе. это почти буквально панацея для медленной передачи файлов по сети.

Если вы передаете несколько файлов, используйте tarих для объединения их в один поток данных. Если это один файл, который вы можете использовать catили перенаправление ввода / вывода. Накладные расходы по tarсравнению со catстатистически незначимы, поэтому я всегда использую tar(или zfs -sendтам, где могу), если это не tarball . Ни один из них не гарантирует вам метаданные (и, в частности cat, не даст). Если вы хотите метаданные, я оставлю это в качестве упражнения для вас.

Наконец, использование sshдля транспортного механизма является безопасным и несет очень мало накладных расходов. Опять же, накладные расходы по sshсравнению ncстатистически незначимы.

Вы упоминаете «rsync», поэтому я предполагаю, что вы используете Linux:

Почему бы вам не создать файл tar или tar.gz? Сетевое время передачи одного большого файла быстрее, чем многих маленьких. Вы даже можете сжать его, если хотите ...

Тар без сжатия:

На исходном сервере:

tar -cf file.tar /path/to/files/

Затем на приемном конце:

cd /path/to/files/
tar -xf /path/to/file.tar

Гудрон со сжатием:

На исходном сервере:

tar -czf file.tar.gz /path/to/files/

Затем на приемном конце:

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

Вы бы просто использовали rsync для фактической передачи файлов (tar | tar.gz).

Вы можете попробовать tarи sshтрюк описано здесь :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

это должно быть перезаписано следующим образом :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"

Вы потеряли бы --partialчерты rsyncв процессе, все же. Если файлы меняются не очень часто, жизнь с медленными начальными значениями rsyncможет оказаться весьма полезной, поскольку в будущем она будет развиваться гораздо быстрее.

Вы можете использовать различные параметры сжатия rsync.

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

Степень сжатия бинарных файлов очень низкая, поэтому вы можете пропустить эти файлы, используя --skip-compress, например iso, уже заархивированные и сжатые архивы и т. д.

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

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