Как передать сжатые данные на 35 ГБ данных с локального на удаленный сервер? [закрыто]

Finnaly Я сделал сам! Это заняло больше времени, чем я просмотрел, но он просто работает ...

Использовал только сетевые настройки. Фотографии показывают историю.

Графическая настройка для OpenVPN в Mint 17 и / или Ubuntu 14.10

0
задан 8 November 2017 в 13:23

9 ответов

ftp и http являются самыми быстрыми, ftp быстрее для меньшего количества больших файлов и http быстрее для большего количества небольших файлов (не удивительно, учитывая природу http-трафика).

См. https : //stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Дополнительные этапы - https://stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Примечание. Ваш интернет-провайдер может ограничить скорость загрузки в зависимости от вашего провайдера. Если ваш провайдер вводит скорость или ограничение данных, это может быть неважно.

Вы также можете использовать другие методы, см. Http://moo.nac.uci.edu/~hjm/HOWTO_move_data .html

4
ответ дан 22 May 2018 в 16:25
  • 1
    Вы забыли упомянуть, что FTP и HTTP не защищены и могут быть перехвачены. – NerdOfLinux 7 November 2017 в 23:52
  • 2
    Я согласен, но, вопрос касается самого быстрого, не самого безопасного. OP не любит scp из-за скорости (так заявлено). Лично я использую rsync поверх ssh, но это не быстрее ftp или http. – Panther 7 November 2017 в 23:55
  • 3
    Я не думаю, что ОП или вопрос является одним из вопросов безопасности, однако, если вы считаете, что безопасность является главной задачей, продолжайте и отредактируйте мой ответ или опубликуйте свои собственные, до вас. Я бы поднял безопасный ответ. – Panther 8 November 2017 в 00:03
  • 4
    Для одного рода передачи, безопасность может быть обеспечена с помощью gpg для шифрования и подписи файла. – vidarlo 8 November 2017 в 00:25
  • 5
    Общие алгоритмы шифрования не увеличивают размер данных (кроме заполнения). Я сомневаюсь, что накладные расходы или накладные расходы протокола будут иметь значение для 35 ГБ при 1 Мбайт / с. -1 – David Foerster 8 November 2017 в 14:24

ftp и http являются самыми быстрыми, ftp быстрее для меньшего количества больших файлов и http быстрее для большего количества небольших файлов (не удивительно, учитывая природу http-трафика).

См. https : //stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Дополнительные этапы - https://stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Примечание. Ваш интернет-провайдер может ограничить скорость загрузки в зависимости от вашего провайдера. Если ваш провайдер вводит скорость или ограничение данных, это может быть неважно.

Вы также можете использовать другие методы, см. Http://moo.nac.uci.edu/~hjm/HOWTO_move_data .html

4
ответ дан 18 July 2018 в 03:41

ftp и http являются самыми быстрыми, ftp быстрее для меньшего количества больших файлов и http быстрее для большего количества небольших файлов (не удивительно, учитывая природу http-трафика).

См. https : //stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Дополнительные этапы - https://stackoverflow.com/questions/9707900/what-is-the-fastest-way-to-transfer-files-over-a-network-ftp-http-rsync-etc

Примечание. Ваш интернет-провайдер может ограничить скорость загрузки в зависимости от вашего провайдера. Если ваш провайдер вводит скорость или ограничение данных, это может быть неважно.

Вы также можете использовать другие методы, см. Http://moo.nac.uci.edu/~hjm/HOWTO_move_data .html

4
ответ дан 24 July 2018 в 17:54

35GiB займет около 25 дней со скоростью 1 МБ / мин (17 кБ / с). Поскольку это займет много времени, я бы сосредоточился на пути, который позволяет легко возобновить работу. Это исключает scp, насколько мне известно, и я бы рассмотрел следующие кандидаты:

http (s) rsync Sneakernet

Настройка веб-сервера для обслуживания одного файла довольно легко; стандартная установка Ubuntu может сделать это без какой-либо конфигурации, если машина доступна из Интернета. Просто поместите файл в /var/www/html/ (или свяжите его там).

Используйте wget -c http://example.com/file.tar, чтобы возобновить загрузку, если прервано. Это работает довольно надежно. Поскольку это одно время, не беспокойтесь о сертификатах ssl - зашифруйте и подпишите данные, если вас беспокоит безопасность и целостность.

Rsync передается через SSH, поэтому он безопасен. Он поддерживает непрерывное продолжение. rsync -P localfile user@example.com:remotefile должен поддерживать резюме и передавать файл без каких-либо забот.

Но 25 дней - это долгое время. Скорее всего, вы можете скопировать диск на USB-накопитель и быстрее отправить его по почте. 64-гигабайтные USB-накопители могут иметь около 20USD. Если вы это сделаете DHL, это будет почти в любом месте в течение 3-4 дней.

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

Или пойдите куда-нибудь с приличным соединением - 35GiB при соединении 100 Мбит / с займет менее часа.

Для шифрования и подписания файла вы можете использовать gpg. Настройте пару ключей, зашифруйте файл и подпишите его. На удаленном конце вы проверяете подпись и расшифровываете ее. Это обеспечивает безопасность и целостность при транспортировке через ненадежный канал, например, почту или http. Если вы используете rsync, ssh позаботится об этом для вас.

3
ответ дан 22 May 2018 в 16:25

Как заявила Пантера, наиболее быстрыми могут быть незашифрованные параметры, такие как FTP или HTTP. Однако, если есть что-то, что вы предпочитаете не публиковать в Интернете, я рекомендую использовать зашифрованный метод. Вы можете попробовать что-то вроде создания простой страницы входа в PHP (с использованием оператора if), установки и настройки nginx или apache для HTTPS и иметь ссылку для загрузки, к которой вы можете получить доступ. HTTPS должен быть быстрым, так как он использует сжатие, и вы можете использовать такую ​​программу, как axel, чтобы установить этот файл с помощью нескольких соединений.

Самый простой ответ, если ваше интернет-соединение является узким местом, а не CPU, было бы использовать SFTP с флагом -C для включения сжатия, хотя, поскольку вы уже сжимаете его, количество, которое может быть дополнительно сжато, довольно невелико. Самый простой способ - сжать файлы с помощью более эффективного метода.

1
ответ дан 22 May 2018 в 16:25
  • 1
    Не перекомпилируйте сжатые данные. Это может фактически увеличить размер. Кроме того, шифрование не является большой накладной. – vidarlo 8 November 2017 в 00:37
  • 2
    Вот что я пытаюсь сказать. Другой ответ заключается в том, чтобы не зашифровать его вообще, что я не думаю, что это умная идея. – NerdOfLinux 8 November 2017 в 00:38
  • 3
    Зависит от данных. Но шифрование само по себе не имеет никакого отношения к сжатию. – vidarlo 8 November 2017 в 00:39
  • 4
    Я знаю. Но HTTPS делает оба – NerdOfLinux 8 November 2017 в 00:40
  • 5
    Это необязательная настройка. – NerdOfLinux 8 November 2017 в 01:03

Как заявила Пантера, наиболее быстрыми могут быть незашифрованные параметры, такие как FTP или HTTP. Однако, если есть что-то, что вы предпочитаете не публиковать в Интернете, я рекомендую использовать зашифрованный метод. Вы можете попробовать что-то вроде создания простой страницы входа в PHP (с использованием оператора if), установки и настройки nginx или apache для HTTPS и иметь ссылку для загрузки, к которой вы можете получить доступ. HTTPS должен быть быстрым, так как он использует сжатие, и вы можете использовать такую ​​программу, как axel, чтобы установить этот файл с помощью нескольких соединений.

Самый простой ответ, если ваше интернет-соединение является узким местом, а не CPU, было бы использовать SFTP с флагом -C для включения сжатия, хотя, поскольку вы уже сжимаете его, количество, которое может быть дополнительно сжато, довольно невелико. Самый простой способ - сжать файлы с помощью более эффективного метода.

1
ответ дан 18 July 2018 в 03:41

35GiB займет около 25 дней со скоростью 1 МБ / мин (17 кБ / с). Поскольку это займет много времени, я бы сосредоточился на пути, который позволяет легко возобновить работу. Это исключает scp, насколько мне известно, и я бы рассмотрел следующие кандидаты:

http (s) rsync Sneakernet

Настройка веб-сервера для обслуживания одного файла довольно легко; стандартная установка Ubuntu может сделать это без какой-либо конфигурации, если машина доступна из Интернета. Просто поместите файл в /var/www/html/ (или свяжите его там).

Используйте wget -c http://example.com/file.tar, чтобы возобновить загрузку, если прервано. Это работает довольно надежно. Поскольку это одно время, не беспокойтесь о сертификатах ssl - зашифруйте и подпишите данные, если вас беспокоит безопасность и целостность.

Rsync передается через SSH, поэтому он безопасен. Он поддерживает непрерывное продолжение. rsync -P localfile user@example.com:remotefile должен поддерживать резюме и передавать файл без каких-либо забот.

Но 25 дней - это долгое время. Скорее всего, вы можете скопировать диск на USB-накопитель и быстрее отправить его по почте. 64-гигабайтные USB-накопители могут иметь около 20USD. Если вы это сделаете DHL, это будет почти в любом месте в течение 3-4 дней.

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

Или пойдите куда-нибудь с приличным соединением - 35GiB при соединении 100 Мбит / с займет менее часа.

Для шифрования и подписания файла вы можете использовать gpg. Настройте пару ключей, зашифруйте файл и подпишите его. На удаленном конце вы проверяете подпись и расшифровываете ее. Это обеспечивает безопасность и целостность при транспортировке через ненадежный канал, например, почту или http. Если вы используете rsync, ssh позаботится об этом для вас.

3
ответ дан 18 July 2018 в 03:41

Как заявила Пантера, наиболее быстрыми могут быть незашифрованные параметры, такие как FTP или HTTP. Однако, если есть что-то, что вы предпочитаете не публиковать в Интернете, я рекомендую использовать зашифрованный метод. Вы можете попробовать что-то вроде создания простой страницы входа в PHP (с использованием оператора if), установки и настройки nginx или apache для HTTPS и иметь ссылку для загрузки, к которой вы можете получить доступ. HTTPS должен быть быстрым, так как он использует сжатие, и вы можете использовать такую ​​программу, как axel, чтобы установить этот файл с помощью нескольких соединений.

Самый простой ответ, если ваше интернет-соединение является узким местом, а не CPU, было бы использовать SFTP с флагом -C для включения сжатия, хотя, поскольку вы уже сжимаете его, количество, которое может быть дополнительно сжато, довольно невелико. Самый простой способ - сжать файлы с помощью более эффективного метода.

1
ответ дан 24 July 2018 в 17:54
  • 1
    Не перекомпилируйте сжатые данные. Это может фактически увеличить размер. Кроме того, шифрование не является большой накладной. – vidarlo 8 November 2017 в 00:37
  • 2
    Вот что я пытаюсь сказать. Другой ответ заключается в том, чтобы не зашифровать его вообще, что я не думаю, что это умная идея. – NerdOfLinux 8 November 2017 в 00:38
  • 3
    Зависит от данных. Но шифрование само по себе не имеет никакого отношения к сжатию. – vidarlo 8 November 2017 в 00:39
  • 4
    Я знаю. Но HTTPS делает оба – NerdOfLinux 8 November 2017 в 00:40
  • 5
    Это необязательная настройка. – NerdOfLinux 8 November 2017 в 01:03

35GiB займет около 25 дней со скоростью 1 МБ / мин (17 кБ / с). Поскольку это займет много времени, я бы сосредоточился на пути, который позволяет легко возобновить работу. Это исключает scp, насколько мне известно, и я бы рассмотрел следующие кандидаты:

http (s) rsync Sneakernet

Настройка веб-сервера для обслуживания одного файла довольно легко; стандартная установка Ubuntu может сделать это без какой-либо конфигурации, если машина доступна из Интернета. Просто поместите файл в /var/www/html/ (или свяжите его там).

Используйте wget -c http://example.com/file.tar, чтобы возобновить загрузку, если прервано. Это работает довольно надежно. Поскольку это одно время, не беспокойтесь о сертификатах ssl - зашифруйте и подпишите данные, если вас беспокоит безопасность и целостность.

Rsync передается через SSH, поэтому он безопасен. Он поддерживает непрерывное продолжение. rsync -P localfile user@example.com:remotefile должен поддерживать резюме и передавать файл без каких-либо забот.

Но 25 дней - это долгое время. Скорее всего, вы можете скопировать диск на USB-накопитель и быстрее отправить его по почте. 64-гигабайтные USB-накопители могут иметь около 20USD. Если вы это сделаете DHL, это будет почти в любом месте в течение 3-4 дней.

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

Или пойдите куда-нибудь с приличным соединением - 35GiB при соединении 100 Мбит / с займет менее часа.

Для шифрования и подписания файла вы можете использовать gpg. Настройте пару ключей, зашифруйте файл и подпишите его. На удаленном конце вы проверяете подпись и расшифровываете ее. Это обеспечивает безопасность и целостность при транспортировке через ненадежный канал, например, почту или http. Если вы используете rsync, ssh позаботится об этом для вас.

3
ответ дан 24 July 2018 в 17:54

Другие вопросы по тегам:

Похожие вопросы: