Как стать автором
Обновить

Комментарии 80

BitTorrent Sync радует меня следующим образом: Я разбросал синхронизируемую, зашифрованную EncFS, папку по своим серверам (места свободного на них предостаточно) и компьютерам родителей / знакомых (в обмен на их папочки, конечно). Все видят лишь зашифрованные данные, я вижу её как примонтированный диск, точек синхронизации получилось порядка 15. С одной из «нод» моего «облака» я периодически делаю синхронизацию с Glacier. С месяц назад я, за ненадобностью, удалил Dropbox, которым пользовался с момента его анонса.
Кстати, если кто-то хочет сохранить у меня копию своих данных, обязательно зашифрованных, в обен на мою папочку (~800Mb сейчас, но будет расти) — можем обсудить в ЛС. Больше точек хранения, — меньше вероятность потери.
Т.е. 15 точек Вам ещё и мало?
Мне-то достаточно. Сама идея понравилась. Это ж, по-сути: бесплатный, нецензурируемый, защищённый (насколько сами пожелаете), p2p недо-dropbox без единственной точки отказа. Если найти такой бартер с более чем 3 людьми (желательно из разных стран, городов), то можно не переживать за сохранность данных. Важный момент: ключ не своим компьютерам раздаётся readOnly.
Похожая фишка, кстати, есть в CrashPlan
«Без единой точки отказа» — а если завтра сервера Bittorrentsync навернутся, как Ваши клиенты друг-друга найдут?
а если завтра сервера Bittorrentsync навернутся

Если они есть и их выключение способно погасить одноранговую p2p сеть (а разработчики её именно так позиционируют), то у Вас останется Ваша локальная папка. Но я не слышал, что бы были какие-то центральные сервера. Не поделитесь источником?
Ну дык вот же. Коротко: если ваши устройства не в одной локалке и не со статическими IP — вы зависите от серверов Bittorrent sync. Можно настроить свой трекер — но это опять-таки «единая точка отказа». В общем, чудес не бывает.
Значит, p2p не совсем честный и «дополнительные средства обеспечения связи, такие как серверы-ретрансляторы и трекеры» имеют место быть. По крайней мере до тех пор, когда любой не сможет легко поднять у себя такой сервис.

Но в том же документе сказано: «если у вас есть известный узел со статическим IP-адресом и портом, эти данные можно указать в клиенте Sync, чтобы он соединялся с пиром на основе этой информации». Как костыль на крайний случай — подойдёт.
Про DHT забыли. Плюс демон будет помнить адреса пиров.
Статические — будет, а при всех узлах с динамическими IP и без сервера — по какому волшебству найдутся первые пиры для DHT?
Магия… DHT вообще таинственная вещь)
А вы отличную идею подали! Браво.
Я уже давно думал о такой схеме, когда пиры хранят не голые файлы, а определённого размера контейнер. Можно сделать инструкцию «для тупых», как организовать такое облако самому?
Под windows используете encfs? Насколько он стабилен и пригоден?
О, думал я один такой. Я через BTSync из Китая назад в Украину слал большие файлы. Долго и мучительно, но лучше чем dropbox/scp/rsync. По ночам скорость выше заметно была. Для особо больших файлов (>40GB) до сих пор используем старый добрый способ передачи данных «SD карточки + fedex».
«SD карточки + fedex» — вспомнилась байка времен, когда пишущие CD-приводы были не распространены в силу своей дороговизны, мол, дискеты после поездки в трамвае/троллейбусе переставали читаться.

Неужели в 2013-2014 году кто-то передает объемы данных сравнимые с объемом распространенных флеш-карт курьерами?
Интересовался у кинематографистов, как они пересылают огромные объемы видеоданных, оказалось на HDD посредством курьеров.
Не знаю… Несколько сотен гигабайт перелить на обычном для крупных городов канале — не проблема. Я как-то около 3 Тб так вытащил за пару недель.
Ээх, Даже в развитых странах есть проблемы с интернетом. Я бы сказал что в России интернет один из самых лучших по отношению цена-качество (и количество доступной выделенки). Радуйтесь ;)
НЛО прилетело и опубликовало эту надпись здесь
Не спорю. Но у меняи канал за 750 рублей. А если таких десяток обьединить?
Ну если говорить о ситуации «из-за баррикад китайского правительства», то 3 Тб вряд ли можно будет перекинуть быстрее, чем курьером. С другой стороны, торренты в целом здесь качаются нормально, поэтому при наличии разветвлённой сети на BT Sync такой объем вполне возможно перекинуть. Но здесь, видимо, должна быть какая-то критическая плотность пиров и более-менее их равномерное географическое распределение, т.е. те же проблемы mesh-сетей.
Не путайте свои домашние потребности и потребности профессионалов. Дома вы можете хоть месяц ждать когда вам терабайты зальются. А в реальном производстве эти данные как обычно нужны «еще вчера» и никто не будет ждать пару недель…
Кстати было дело. Я так Warcraft II 3 раза на дискетах возил.
На третий раз решил прогуляться и ни одного битого куска. :)
Да, честно говоря. Из-за странностей китайского файервола скорости падают до ниже 3 кБ/сек очень быстро, а скажем исходники прошивки андроида весят больше 15 гиг. Разумеется, про git они тоже не слышали, поэтому здоровенный такой tar.gz. Залить его за неделю так и не вышло, а вот карточка/флешка доходит запросто за это время. То же самое про всякий видео-контент который десятками гиг измеряется.
пользую rsync
хватает с головой

перебрал кучу софта для синхронизации, но так и не смог найти ничего лучше
Как им глобальный прогресс показывать, чтобы было ясно, сколько ещё ждать хоть примерно?
-v --progress
image

Это не глобальный, а для каждого файла в отдельности, если у меня десятки тысяч не сильно больших файлов — он бесполезен.
таки да. в базовой версии глобальный прогресс — нетривиальная задача
но, как было сказано ниже, отца русской демократии спасёт devel-версия rsync с поддержкой параметра --info=progress2
выглядит так:
image

это rsync из testing (Debian)
если ли такая версия для Windows — вопрос (ггулить щас лень)
Попробуйте, может, у вас уже доступна новая опция --info=progress2

А ещё есть же pv:
rsync -ai /source remote:/dest | pv -les [number of files]

Или чтобы не считать кол-во файлов вручную:
rsync -aix /source remote:/dest | pv -les $(df -i /source | perl -ane 'print $F[2] if $F[5] =~ m:^/:')

Правда, это будет «прогресс по количеству файлов», без учёта их размеров.
Но если файлы примерно одинакового размера, должно быть довольно точно.
А причем тут вообще rsync? Он же немного не для этого.
ну не то, чтобы не совсем
просто если люди качали файлы через файлообменники…

rsync очень быстрый. я через bluetooth каждый день синхронизирую 40 ГБ музыки
и был как-то момент, что я обновил 90% тегов. так вот rsync при этом перекачивал файлы не полностью, а только их дельту. как он это делал — хз, но у него в статистике (--stats) есть два очень интересных значения: literal data и matched data (фактические данные и сопоставленные данные)
Торент передается блоками, накаждый блок имеется хеш и нет необходимости перекачивать куски хеш которого совпадает с оригинальным. Вы теги обновили так что они полностью поместились в предыдущие и измененными оказались только некоторые блоки. Если бы новые теги были хоть на байт длиннее… перекачивало бы с нуля.
про принцип работы торрента мне известно
мне неизвестно, каким образом rsync определяет, что именно в файле было изменено
он не хранит никаких метаданных на диске
Видимо, все же хранит. Либо синхронизирует и их прямо на лету.
да мне стало самому интересно

сгенерировал файл размером 10МБ из /dev/urandom и начал его мучить:
* удалил один байт
* добавил один байт
* вставил в середину файла мусор на 500 байт
* случайным образом удалил из файла несколько кусков по килобайту
* дописал в конец файла мусор на 2МБ

после каждой операции файл передавался через rsync
итого было замечено, что передаётся не весь файл, а только дельта + служебный трафик объёмом до нескольких КБ (до 6)

и если на дельте в 1 байт паразитный трафик получался существенным (в процентном отношении), то для дельты в 2 МБ паразитный трафик был мизерным (~600 байт)
по-моему это очень круто. я начал уважать rsync ещё больше

википедия показала, что в rsync используется некий «rolling checksum» алгоритм, основанный на хеш-функции adler-32 Марка Адлера
что это за страшные слова, я не знаю, но вдруг кому-то будет интересно :)
Делит файл на блоки, считает для каждого блока хэш — быстрый rolling хэш, и полный MD4. Затем на отправляющей стороне пытается подобрать начало блока принимающей стороны байт за байтом. И отправляющая сторона сообщает либо по какому смещению блок начинается, либо передает весь новый блок целиком, если он не найден.

Да впрочем что это я, вот же — rsync.samba.org/tech_report/
Вопрос — BitTorrent Sync синхронизирует только измененную часть файла или весь файл?
Любопытствую почему — хочется TC контейнер синкать.
Насколько мне известно, файлы делятся на блоки, каждый из которых хешируется независимо. При изменении синхронизируются только изменившиеся блоки.
обычно трукрипт перемешивает контейнер при работе с ним.
ТС не перемешивает весь созданный контейнер.
Дефрагментацию тома главное не делать (или как можно реже хотя бы) и все будет 'ОК'.
Никто не промахивался с удалением и не сносил всю папку к чертям? :)
В последних версиях файлы не удаляются, помещаясь в .SyncArchive. Не самый удобный вариант, но хоть что-то.
НЛО прилетело и опубликовало эту надпись здесь
А меня это выручало пару раз. Хотя жаль, что нельзя задать предельный размер этого хранилища наподобие «восстановления системы» в Windows.
А как вы используете Sync в жизни?
Использовал для сихронизации пользовательских папок между двумя компами, но потом отказался, так как:
1. При активной работе с файлами и папками (сортировка и редактирование большого количества документов, фотографий и т.п.) иногда получалось, что удалённые папки и файлы спустя какое-то время вдруг появлялись на старом месте (это было прошлым летом, может быть уже и пофиксили) — в итоге я получил по голове от жены и отключил синхронизацию её пользовательской папки между компами.
2. BTSync понимает только первый поток файлов, т.е. аттрибуты и прочие метаданные файлов не синхронизируются. Думаю, это можно обойти переводом пользовательской папки на exFAT, но было лень разбираться.
3. Не нашёл, как запустить BTSync в виде службы, чтобы синхронизация работала при включенном компьютере всегда, без необходимости логина всех пользователей.

В итоге от синхронизации пользовательских папок я отказался, а для синхронизации документов вернулся на DropBox, тем более, что его понимает уже почти каждый калькулятор.

Жду, когда авторы лучше интегрируют BTSync с ОС или же откроют исходники, чтобы это могло сделать сообщество.
Как вы альтернативные потоки используете? Майкрософт и то загнал фичу куда подальше (уже нельзя навешивать любые свойства любым файлам), потому что выживаемость потоков никакая. Для «метки веба» только и используется, из того что видел.
Именно альтернативными потоками я не пользуюсь, но использую метки файлов, которые хранятся в расширенных атрибутах HFS+, в com.apple.metadata:_kMDItemUserTags.
DropBox сохраняет их при синхронизации, причём даже кроссплатформенно, на NTFS хранит их в потоке :com.dropbox.attributes, т.е. при бережном обращении файл можно редактировать, переименовывать и перемещать в Windows, и он сохранит проставленные в Finder-e метки.
3. Я для этого запускаю BTSync через планировщик по условию «При запуске» и указываю «Выполнять вне зависимости от регистрации пользователя».
Спасибо за материал. Даже пропустил как-то такую полезную софтину. Почитав материал, уже даже прикинул, где мне может быть полезно.

Кстати вопрос. А если папку вдруг сносят, но потом теневое копирование приходит нам на помощь, как софтина себя ведёт? Или не было таких случаев?
Кстати, отличная штука этот bittorrent sync — я свой семейный фотоархив так синхронизирую… на своём компе + на родительском + на сервере бэкап… Очень удобно… кто бы фото не добавил — оно везде появляется!
У меня тот же вариант. Плюс бэкап фотографий в телефоне.
Пытаюсь уже год запустить версию под FREEBSD — глючит и воз и ныне там.
Запускаю, добавляю папку, останавливаю, все. Больше битторент не запускается пока не снесешь ему базу в его директории. Тупо падает при запуске и все. То есть три дня хэшировать с каждого запуска, что никуда не годится.
Чего ему не хватает?
Меня поразило, что BT Sync не умеет восстанавливать частично поврежденные или не докачаные файлы — при отсутствии мета-данных вручную подставленные файлы удаляются, либо портят данные на ответной стороне. Буквально, чтобы докачивать поврежденные файлы или синхронизировать большие папки в одну сторону оказалось удобнее поднять на сервере торрент трекер.
Подскажите, а оно в linux умеет работать с символическими ссылками?
Неа, я mount --bind делаю.
Ну тут есть большой минус, как я понимаю, если удалишь ссылку, то удалится только ссылка, а тут исходный файл/каталог.
:-(
Используйте жёсткие ссылки. Тогда источник ссылки выживет.
Поставил на работе на Ubuntu для папки с проектами (Android, Eclipse)
Дома поставил для синхронизации в режиме readonly.
Со временем BTSync глючит и перестает синхронизировать папку с проектами вообще, хотя папку с ТЗ и т п синхронизирует и дальше.
Помогает только пересоздать папку на работе и соответственно заново подключить ее дома.
Почему-то в моих трёх виндовых ноутбуках и одном дебиан-серваке программа запуталась — постоянно висели недокачанные «размеры», которые почему-то не начинали качаться и в конце концов осталось куча файлов с расширением .!sync, часть из которых не восстанавливались даже, при стирании этого расширения… Несколько раз замечал конфликты и нелогичность поведения. Типа после удаления файл, вместо удаления во всех местах, скачивался назад. Возможно как раз из-за вышеописанных багов. Что-то в общем у меня бета не пошла и, в результате, окончательно перешёл на owncloud — доволен.
Не совсем по теме.
Но для всех, кто страдает из-за связи, Китай-Россия, есть такое слово Гонконг :)
Если использовать его как точку обмена трафиком, то все получается вполне себе достойно, пинг получается 100мс между Москвой и остальным Китаем.
OneDrive забодал глюками — удаленные файлы почему-то всплывают когда включаю машину которая долго была в оффлайне и получается каша. Нет ли таких глюков у битторрент синка?
Это как так? всплывают.? пользуюсь и такого не наблюдаю.
Ситуация такова: имеется одна папка-помойка содержащая кучу картинок, которые я накидываю с работы или мобильника, потом эпизодически разгребаю на основном компьютере. Так вот, после того как я их рассортирую и включу другой компьютер, то папка снова наполняется файлами.
Один раз был такой глюк — маленький файл никак не хотел синхронизироваться, крутился значок прогресса, но он не появлялся на облаке и других машинах почти сутки. Решилось после того как вручную снес папку с кешем.
Этой программой, кстати, моды игрового сервера ArmA 2 Тушино синхронизируются с игроками.
Благодаря статье узнал про директорию с удалённым файлами и sync_max_time_diff.
Лично меня напрягает, что помимо секрета нельзя указать еще и пароль. Достаточно ли это все безопасно?
Я до прошлой недели тоже не мог нарадоваться. Но добавил ScrapBook фолдер на 150000 файлов, и начались проблемы — то синхронизируется, то нет, причём разные папки и разные устройства. Кроме того, где-то в описании я нашёл упоминание о деградации производительности обена при перегрузках на центральных серверах.

Вообще для обмена большими файлами существуют специальные программы со своими протоколами, не tcp-ip. Скорость увеличивается значительно.
Вот только не понятен один момент.
Была папка создана в BTSync, синхронизируется на 3 других ПК (readonly).
Требуется переустановить Windows на основном ПК, как сохранить настройки BTSync, чтобы не создавать папку заново и не давать новый readonly ключ другим 3-м ПК?
Сохраните ключ полной синхпонизации. По идее так.
С утра нашел папку с файлом настроек, как у uTorrent, возможно достаточно ее сохранить, чтобы все папки вручную не добавлять. Если никто раньше не проверит, то вечером отпишусь о результатах.
У меня Linux и BTSync в виде демона без графики работает. Так что не помогу.
Все работает, для Windows достаточно сохранить папку в %APPDATA%\BitTorrent Sync.
Извените, я тут влезу с MS. Как бы он не был нелюбим, вы не рассматривали делать ФП с использованием из техлогий? Или жестко упераемся в бюджет?
НЛО прилетело и опубликовало эту надпись здесь
Всё как в обычном торренте: трекер, DHT, поиск в локальной сети и обмен пирами. Есть возможно включать/выключать каждую из опций, добавить свой трекер или список пиров.
Жаль, но придётся признать: после обновления bt-клиент стал говном. Для работы под виндой требует IE11, зависает, тормозит, вылетает. Вместо ясных и понятных ключей R/RW запихали мутные «ссылки», так что до изначальных ключей добраться стало настоящей головоломкой. Убрали поддержку XP.
Очень, очень жаль.
Согласен полностью. Начали кривую монетизацию с искусственными проблемами. Пошёл тыкать syncthing.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории