Эффективно копируем гигабайтные файлы по сети в Linux / Unix / Mac OS

[@starikoff72]

У nc есть один существенный минус. Порт на сервере для передачи данных надо открыть в файрволле, а после передачи не забыть закрыть. А для передачи данных с локального ПК на сервер, надо пробрасывать порт на локальный комп на маршрутизаторе (если конечно сквозная маршрутизация не настроена средствами ВПН или напрямую). Для ssh порт как правило открыт для подключений извне, так что дополнительных лействий совершать не придется. Далее, хорошо сжимаемые данные (текстовики, образы виртуалок, дампы баз) принято гонять в сжатом виде. Жать можно на лету, либо встроенными в scp инструментами, либо жать сторонними утилитами вроде pigz и гонять данные через ssh и пайпы. Например так: dd bs=4M if=template.img | pv | pigz -9c | ssh user@host "unpigz -c > /vm/template.img" Подобным способом можно не только гонять файлы, но и переливать образ на удаленное устройство. sudo dd bs=4M if=/dev/ssd1/vm | pv | pigz -9c | ssh user@host "unpigz -c | sudo dd bs=4M of=/dev/ssd2/vm"

[@ТимурСафаров-в1ч]

Каканы всем привет - классное приветствие я такого ещё не слыхал

[@t0digital]

Котаны:)

[@HELLO_AGAIN]

Подобные видео очень даже интересны! Благодарю!

[@RuchejAlex]

Когда он начал передавать файлы, у меня видео залагало.

[@t0digital]

да, на 1080p почему-то ютуб лагает в этом моменте на этом видео - на большем или меньшем разрешении всё ок

[@RuchejAlex]

@@t0digital это к тому, что передача данных высосала весь инет)

[@t0digital]

@@RuchejAlex Magic:)))

[@plgrm44]

и у меня залагало, в следующий раз зипуй перед отправкой

[@vasiliynet3425]

Огонь! Как и в комментах ниже, тоже в основном через rsync льем. Мелочевку, так и вообще в mc по F5 удобней :)

[@МаксКошевой-щ2б]

а мне чет кажется rsync быстрее, сравни скорости в след видео, или это допиши)

[@AlieXAndreX]

Блин! Как охрененно, а я то думал как мне по быстрому передать виртуалку на другой сервак. Спасибо!

[@LinuxbyDmitry]

rsync, пожалуй самый не удобный инструмент), но для передачи например сайта размером 500 гигов, на мой взгляд лучше чем rsync не найти. Правда он частенько разрывает соединение, но если написать не сложный скрипт, то он будет возобновлять передачу сам и в обще поможет в организации передачи. rsync может налету сжимать и шифровать данные, проконтролирует целостность файлов и структуры директорий, да и сама доставка будет гарантированной. Пользуюсь на работе rsync, в качестве быстрого (инкрементного способа), копирование всякого рода софта, юзер документов и т.д.. Проверяет на изменения более 200 гигов за несколько секунд, с около десяти ПК и копирует только изменения или новые файлы, старые (которых нет в оригинале) в моём случае удаляет.

[@LinuxbyDmitry]

@@Александр-у7м2у Давно это было, да и комментарию уже четыре года)). Я ответил с ссылкой, но похоже KZbin не пропускает).

[@GrinRuslan]

не знал о такой штуке. до этого использовал только scp

[@olegssh6452]

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

[@aleksandrdevelopment3321]

Очень крутые и действительно полезные видосы!

[@nikolaysokolov9027]

Обалдеть). Только для трассировки http get/post использовал. Не знал, что можно файлы передавать по сети.

[@SergeyChernetsky]

Крутяк 👍🏼

[@ntrl78]

можно добавить команду pv в поток приемнику или передатчику, тогда будет виден прогресс. я бы в конце md5sum у файликов сравнил на всякий случай :)

[@VadimMolchanov]

Класс, красивое использование утилит!

[@t0digital]

спасибо!

[@cleverscript]

Супер спасибо!

[@eugenstakhursky9604]

Спасибо дружище, интересно, буду пробовать! С меня лайк и подписка)

[@t0digital]

Отлично!

[@DmitryLopatkov]

nc прикольно. есть ещё rcp, оно может копировать без шифрования (или для scp задать шифрование слабее дефолтного, чтобы меньше процессор грузить, в него обычно упирается скорость). А ещё можно на стороне источника взмахом пера поднять питонячий вебсервер (с корнем в каталоге где запускается команда, по умолчанию на порту 8000 и всех доступных интерфейсах, но можно задать если надо) и с него по http забрать любым удобным клиентом. python -m $(python -c 'import sys; print("http.server" if sys.version_info[:2] > (2,7) else "SimpleHTTPServer")') Serving HTTP on 0.0.0.0 port 8000 ...

[@kprohorow]

Незаменимая вещь в спартанских условиях. Однажды я даже звук с микрофона одного компьютера netcat-ом передавал на другой комп.

[@КонстантинАнсимов]

Есть еще rclone (rclone.org/). Работает так же быстро и просто, есть поддержка шифрования (при желании), а также куча протоколов облачных хранилищ.

[@oleg9ff]

Благодарю за видео. netcat вообще швейцарский нож - мало чего из него сделать _нельзя_ 8)

[@rabotavsem_biz]

какая разница в скорости передачи, если передавать через файл зиллу используя sftp ?

[@bessonov_mr]

Спасибо, взял на вооружение)))

[@markplay6466]

Спасибо, мне пригодится, я не знал= )

[@pvinnie3827]

у rsync есть преимущество он с ключем --progress показывает собственно прогресс копирования

[@t0digital]

Можно показать прогресс и для nc с pv linuxhint.com/use-netcat-to-transfer-files/

[@Владислав-и3б9н]

Коротко и полезно )

[@t0digital]

Спасибо:)

[@touchdownscale]

Cпасибо, очень помог!

[@t0digital]

Отлично!

[@ДанькаЛобанов-у6ю]

знал о ней, но на принимающей стороне писал питоновский скрипт на сокетах для приёма файлов. Для копирования большого количества файлов вы что выберете. nc или rsync?

[@t0digital]

Даа, питон+сокеты = love:) если размер диска на сервере позволяет и файлы хорошо жмутся, я бы pigz'ом их пожал (он для архивации использует все ядра) и потом перенес с nc. Если жать не хочется и файлов много, то объединить их в один с tar и тоже через nc выгрузить. Nc с tar в среднем может быть быстрее rsync до 5 раз, но rsync хорош именно для периодической синхронизации данных

[@8scarsboy]

Вполне не плохо, в локальной сети на удалённых серверах хорошо файлы перекидывать

[@kosatchev]

Ого! какое колдунство!

[@t0digital]

Магия!

[@alexander199740]

как ты разделил экран так на линуксе?)

[@t0digital]

tmux

[@abyrva1g491]

Спасибо! Пользуюсь NFS для передачи если в одной сети.

[@ДаниилЧайка-ч3в]

Годно!))

[@alexxx4434]

А ужать и зашифровать (каким нибудь пакером и передать по трубе) во время отправки нельзя?

[@t0digital]

сначала ужать и зашифровать, затем передать - можно. Делать это всё одновременно, думаю, тоже можно, но надо искать способ

[@boson_higgs]

Почему не rsync? По-моему главное удобно и скорость не уступает.

[@t0digital]

Скорость уступает

[@igorshlyakov9321]

Круто! Спасибо большое, ща буду осваивать, а можно передавать из сервака на виндовс машину?

[@t0digital]

Да, на виндоус тоже есть nc

[@igorshlyakov9321]

спасибо! нашел где можно вкурить подробнее: www.8host.com/blog/ispolzovanie-netcat-dlya-sozdaniya-i-testirovaniya-soedinenij-tcp-i-udp-na-vps/

[@denisdragomirik]

Не знал. Учитывая, что скоро будем мигрировать сервис с файлами на пару десятков Гб, очень кстати

[@t0digital]

Отлично! Успешной миграции:)

[@fensrg]

Если файлов много воспользуйтесь лучше rsync'ом в таком случае вам не понадобится пространство под архив и не потребуется отдельно перекидывать множество файлов. Можно воспользоватся ssh выполнить команду создания tar архива только не в файл а в stdout и через pipe ловить либо в файл либо сразу распаковывать

[@fensrg]

бинарщину большого размера недоводилось передавать а дампы сливал всегда так ssh host 'mysqldump dbname | gzip' > dbname_date.sql.gz ну или через пайп кинуть в gzip -d и потом либо в файл либо опять же через еще один пайп уже сразу в БД секьюрно быстро без создания промежуточных файлов.

[@t0digital]

Спасибо! Да, это выручает, когда места на сервере не хватает

[@jeep456789]

Очень круто, а в роутере получается тоже нужно порт пробрасывать ?

[@t0digital]

Нет, если грузим с сервера на локал, то можно поступить по сценарию в видео (сервер отдает в свой порт данные, клиент забирает с него), если с локала на сервер, то можно на сервере открыть порт на получение, а с локала послать туда в этот порт данные с файлом

[@jeep456789]

@@t0digital понятно, спасибо

[@antmixxx]

достаточно использовать IPv6 и забыть о пробросе портов совсем.

[@igorshlyakov9321]

А у меня эта штука не работает на Shared хостинге timeweb. При указании порта пишет: grab 0.0.0.0:8888 with bind : Operation not permitted Что делать?

[@fensrg]

использовать ssh например так: ssh host 'mysqldump -uusername -ppassword dbname | gzip' | gzip -d > dbdump_date.sql

[@vinc9846]

Все ж таки, логичнее на приемнике открывать порт на прослушивание (опция -l), а вот на ПК с файлом делать отправку в удаленный порт, т.е. команды наоборот.

[@t0digital]

Да, тоже вариант. Но если надо выдернуть с сервера на локальный комп, не имеющий статического ip, то в него и не постучишься - вероятно, у нас это более частая задача была

[@paulstrong1656]

Я пока что так и не понял, как это взлетело :) всегда делаем как раз наоборот, как пишет @dervish Я всегда этот способ понимал так: мы запускаем прослушку порта 8888, по идее чтобы туда данные по сети наливать, а потом с хоста где лежит файл - отправляем его в сокет.. а в текущем случаем мы слушает порт 8888 и сразу же туда наливаем файл, а как этот поток прилетает на клиентскую часть - я пока что мозг сломал) завтра посмотрю в strace, че там происходит

[@cleverscript]

а как потом закрыть этот файл на удаленном сервере после того как он скачался уже?

[@t0digital]

Ctrl+c для закрытия открытого в сессии nc вроде как

[@cleverscript]

то есть просто закрыть nc?@@t0digital

[@oleksandrkachynskyi1013]

Привет, с одним большим файлом как правило проблем нету. У меня другая проблема, есть проект, в котором 1 000 000 ( условно, на самом деле сильно больше) файлов размером в пару килобайт. Задача перенести/склонировать на другой сервер, но архивировать не выйдет, потому что запас свободного места не позволит. Как быстро перенести все это добро ?

[@t0digital]

Ну а как - если в один файл каким-нибудь tar'ом места не хватит на сервере упаковать, то в любом случае надо переносить по одному или жать по несколько и переносить. Но по одному это не значит вручную - простой bash скрипт, например

[@oleksandrkachynskyi1013]

@@t0digital Спасибо.

[@cyber-ru]

@@oleksandrkachynskyi1013 www.linux.org.ru/forum/general/7603723 tar, pipeline чтобы налету, утилита отправки

[@oleksandrkachynskyi1013]

Нашел для себя оптимальное решение. Дано: 40 млн мелких файлов. Основная проблема не с копированием, а построением списка файлов. лучший результат показал rsync -avzhe ssh user@ip:/folder/to/copy/ /folder/destination/ (синхронизировать удаленную папку с локальной) У меня вышло 36-50 mb/sec. Можно еще выжать скорости если делать это не через ssh а настроить rsync сервер. Пробовал так же вариант с архивами в пайп, много нагрузки на ЦПУ, так как там рабочий проект, то это плохо.

[@GexPlayerMD]

Про nc знал, про watch нет, каждый раз как дурак тыкал вверх и энтер =))

[@t0digital]

Watch крут:)!

[@vitalyvlasenko5495]

Сорри за некропостинг, у меня алиас в .basrc с while : и sleep 1. Я гордился этим алиасом... ООО "Костыли и велосипеды": программируем, как умеем.

[@rsenmakh]

Всегда использую SCP. А почему передавали в nc файл db-2019.......sql, а скачивали db.sql ?

[@t0digital]

потому что мы можем указать любое имя файла при его сохранении

[@sashasashovic91]

Знал NC, но не знал про key q. Используйю scp безопасность и скорость есть.

[@oleg-medovikov]

разве rsync медленнее копирует файлы? или я чего-то не понимаю

[@t0digital]

netcat копирует файлы быстрее, чем rsync, до 5 раз moo.nac.uci.edu/~hjm/HOWTO_move_data.html#tarnetcat

[@oleg-medovikov]

@@t0digital а я только с ним разобрался и алиасов понаписывал и скрипты для бекапов

[@oleg-medovikov]

@@t0digital подписался

[@t0digital]

@@oleg-medovikov спасибо за подписку! Rsync хорошая штука именно для синхронизации директорий/файлов, потому что умеет работать с diff'ами, то есть гонять по сети не полностью файл/все файлы, а разницу. Это очень круто для своих задач. Разовая выгрузка тяжеленного файла - другая задача. Ну или постоянные выгрузки, но именно разных файлов, не частично меняющихся, и тяжелых

[@oleg-medovikov]

@@t0digital а ну тогда значит для моих задач нужен именно rsync

[@AndreyChursin]

Wget не сделает тоже самое(скачает файл)?

[@t0digital]

сделает, но медленнее

[@fensrg]

@@t0digital на сколько медленее? учитывая что до сервака от клиента идет не оптика и потери на шифрование через scp и оверхед на http мелочи и сильно на скорость передачи не повлияют.

[@t0digital]

@@fensrg попробуйте. Оверхед огого:) сеть 100 мбит хотя бы есть наверняка, а это 12.5 метров в сек, почти гиг в минуту

[@fensrg]

@@t0digital я немного удивлен результатом... nc оказался всего на 25% быстрее. За то ssh оказался на целых 83% быстрее O_o возможно сказалась передача по локалхост... но ssh это же не мускуль который ломится на файловый сокет если у него в конфиге прописан localhost или 127.0.0.1 забавный момент надо еще потестить

[@wMwPlay]

rsync использую

[@EvgenyRejnovskey]

И скорость можно резать

[@NarkotikAsd]

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

[@t0digital]

Ась?

[@ВиталийТуров-э3б]

Добрый день. А что у тебя за книга на столе?

[@t0digital]

Добрый день! "Python. К вершинам мастерства"

[@sergeyf7459]

@@t0digital и как книга, стоит почитать?

[@t0digital]

@@sergeyf7459 да, она хороша

[@АртемЗайцев-с2д]

ssh?

[@t0digital]

Что ssh?

[@АртемЗайцев-с2д]

@@t0digital не так услышал, всё хорошо) спасибо за видео)

[@sashasashovic91]

scp на основе ssh для передачи байтов

[@sammygun84]

Не знал о такой штуки ты подвидео оставляей команды из урока удобно потом к ним возвращаться если можно конечно. Хотел уточнить к примеру мой ip такой как указан ниже то я просто захожу на сервер и пишу так nc 172.178.132.144 > db.sql и скачиваю себе на сервер правильно? И почему в примере файл db-2019-01-15__16-16-47.sql название такое, но при скачивании указано db.sql?

[@ge_bassist8232]

идёт передача файла (сюрприз) пакетами, т.е. по частям. имя файла на принимающем сервере не имеет никакого значения. Просто содержимое db-2019-01-15__16-16-47.sql по частям записывается в новый файл. Если проводить аналогию из реальной жизни, то это как переливать воду из зелёного стакана в прозрачный, суть от цвета стакана не меняется.

[@ВладимирГригорьевич-у2р]

за watch спасибо

[@boonya41]

Огнище! А я долбаюсь тут чтобы полтора ГБ через vpn прокси протянуть с помощью scp. Он то залипает, то еще что-то. Спасибо

[@t0digital]

Спасибо:)!

[@boonya41]

@@t0digital вчера стянул... Походу openvpn скорость душит. 470kbps максимум. Нужно какой-то p2p vpn придумать

[@ДмитрийР-г4у]

👍

[@nizdiminov]

Cool

[@andrey_kapro]

использую rsync

[@D_r_._C_r_A_z_Y]

а "scp" уже не канает? и только на одной стороне команду давать надо. я сотни гигов без проблем по шурику копирую

[@t0digital]

Медленнее. Если устраивает - ок

[@D_r_._C_r_A_z_Y]

@@t0digital хм... С чего бы? По гигабитной сетке 110-115MB/s

[@t0digital]

@@D_r_._C_r_A_z_Y с чего бы инструмент, имеющий меньше оверхеда, работает эффективнее? Ну так вот все устроено в жизни)

[@D_r_._C_r_A_z_Y]

@@t0digital По теории всё верно говорите, но на практике-то скорость копирования равна пропускной скорости канала без накладных расходов. Плюс копирование групп файлов и вложенных директорий. Попробуйте - не пожалеете! Вариант с "nc" не отвергаю - пойдёт для развития и разнообразия ))

[@t0digital]

@@D_r_._C_r_A_z_Y скорость копирования никогда не равна скорости канала

[@denwerxampp4035]

+