Comments 31
Можно ли при использовании btsync реализовать схему, когда много источников разных данных и один приемник? (т.е. разные данные с нескольких серверов сливаются на один сервер)
Я таким образом делаю синк рабочих данных между пятью машинами. Несколько десятков тысяч файлов от нескольких Кб до сотен Гб. Работает более/менее сносно, иногда только на больших файлах тупит. Больше всего напрягает то, что если изменить в большом файле несколько байт, он его полностью индексирует довольно долго, а потом целиком заново льёт. Я не совсем понял пока почему он считает что это другой файл и не льёт только изменения.
Может быть потому, что это BitTorrent протокол?
Наоборот, странно, почему так, несмотря на то, что это bittorrent-протокол. Я бы ожидал, что он перешлёт заново только изменившийся чанк.
А откуда ему знать что изменилось, а что нет?
Так каждый файл хешируется почанково. И тут достаточно сравнить хеши.
Может быть, длина фрагмента меняется и чанки “съезжают”?
Нет, не меняется. Файл фиксированной длины, условно — база данных. Там приложение меняет 20-30 страниц по 4Кб каждая. После того как приложение «отпустит» файл я наблюдаю сначала долгий процесс индексации (ну тут всё в принципе понятно), а потом вижу как на остальных машинах этот файл удаляется, создаётся новый и начинают литься данные. Что как-раз для bittorrent-протокола выглядит странно.
Может быть, я глупость предлагаю, но что если использовать для этого Git?
Там есть файлы размером в сотни гигабайт, которые мало меняются. Гит будет копировать их целиков, а BTSync вроде в новых версиях уже таки научился копировать только изменения. Да и в принципе вручную контролировать версии через VCS неудобно в данном случае. Нужна именно многосторонняя синхронизация. Данных очень много, но меняются они мало. Вероятность коллизии стремится к нулю. Раньше синхронизация работала через Wuala, сейчас через BTSync — очень удобно.
Нет, это понятно.
Как узнать какой чанк изменился, не перехэшировав весь файл?
Приложение которое изменило чанк, должно как-то ведь сообщить об этом.
Как узнать какой чанк изменился, не перехэшировав весь файл?
Приложение которое изменило чанк, должно как-то ведь сообщить об этом.
Наверное, вам больше подойдет lsyncd. Это обертка на rsync, соответственно передаваться будут только изменившиеся куски.
Да, с изменёнными большими файлами он ведёт себя, мягко говоря, некорректно. Благо в моём случае файлы не изменяются, а только добавляются и удаляются.
Так файлы же шифруются.
Да, возможно в этом проблема. Но только если они там реализовали поточное шифрование. При блочном всё должно быть ок.
Если там CBC (Cipher Block Chaining, Режим сцепления блоков), то зависимость блоков тоже есть.
Собственно, CBC — это одно из решений именно криптологической проблемы, возникающей при шифровании блоков независимо друг от друга, в режиме ECB (Electronic code book).
В “наивном” ражиме работы (ECB) у злоумышленника по сути есть множество шифротекстов, зашифрованных общим ключом. Для некоторых шифротекстов он знает и оригинальный текст. Например, в случае зашифрованного диска с файлами известно расположение и многие куски значений метаданных ФС, заголовки типичных форматов файлов и так далее. Это сильно облечгит ему работу — например, найдя 100 одинаковых кусков через одинаковые небольшие промежутки он может быть уверен, что набрёл на зашифрованном диске на что–то типа фотоальбома. Соответственно, поле перебора для него сокращается крайне чувствительно.
Если же мы будем подмешивать шифротекст предыдущего блока в текст последующего — никаких повторяющихся однотипных кусков злоумышленник обнаружить не сможет. Соответственно, такая атака (их на самом деле несколько родственных) против CBC не получится.
Собственно, по вышеуказанным причинам CBC — самый часто встречающийся режим шифрования на данный момент. Всем хорош, на несколько ядер только не парралелится, зараза:(
Собственно, CBC — это одно из решений именно криптологической проблемы, возникающей при шифровании блоков независимо друг от друга, в режиме ECB (Electronic code book).
В “наивном” ражиме работы (ECB) у злоумышленника по сути есть множество шифротекстов, зашифрованных общим ключом. Для некоторых шифротекстов он знает и оригинальный текст. Например, в случае зашифрованного диска с файлами известно расположение и многие куски значений метаданных ФС, заголовки типичных форматов файлов и так далее. Это сильно облечгит ему работу — например, найдя 100 одинаковых кусков через одинаковые небольшие промежутки он может быть уверен, что набрёл на зашифрованном диске на что–то типа фотоальбома. Соответственно, поле перебора для него сокращается крайне чувствительно.
Если же мы будем подмешивать шифротекст предыдущего блока в текст последующего — никаких повторяющихся однотипных кусков злоумышленник обнаружить не сможет. Соответственно, такая атака (их на самом деле несколько родственных) против CBC не получится.
Собственно, по вышеуказанным причинам CBC — самый часто встречающийся режим шифрования на данный момент. Всем хорош, на несколько ядер только не парралелится, зараза:(
Вот меня тоже интересовала проблема бэкапов через BT Sync.
Но есть одно такое НО:
Если на главной машине каким-то образом удаляются данные из расшаренной папки, при это сервис BT Sync-a продолжает рабоать, то бэкапы соответственно пропадают и на удаленных машинах. А потом внезапно главный сервер схлопывается. В итоге не имеем доступа ни к клавному серверу, ни к бэкапах на серверах-зеркалах, потому что бэкапов там уже нет.
Возможно это можно решить копированием из расшаренной папки на сервере для бэкапов всего содержимого в другую нерасшаренную папку и выполнять это по крону. Но, опять же, костыль и задержки.
Но есть одно такое НО:
Если на главной машине каким-то образом удаляются данные из расшаренной папки, при это сервис BT Sync-a продолжает рабоать, то бэкапы соответственно пропадают и на удаленных машинах. А потом внезапно главный сервер схлопывается. В итоге не имеем доступа ни к клавному серверу, ни к бэкапах на серверах-зеркалах, потому что бэкапов там уже нет.
Возможно это можно решить копированием из расшаренной папки на сервере для бэкапов всего содержимого в другую нерасшаренную папку и выполнять это по крону. Но, опять же, костыль и задержки.
установил btsync у себя на QNAP NAS. Загружает на него «на ура», а вот NAS отдаёт по 0.4Кб/сек, хотя лимитов в конфиге btsync нет. Это можно было бы списать на недонастройку NAS или роутера, но на нём же отлично крутится Transmission…
Кто-нибудь сталкивался с такой проблемой?
Кто-нибудь сталкивался с такой проблемой?
Для себя вижу 2 беды (как битторент-клиент загрузка):
— невозможно загрузить один файл из тысячи (сервер раздает, клиенты забирают)
— в цепочки много клиентов — 1 сервер, клиенты (IP) постоянно отображаются на сервер, что беспокоит если клиентов > 1000.
— невозможно загрузить один файл из тысячи (сервер раздает, клиенты забирают)
— в цепочки много клиентов — 1 сервер, клиенты (IP) постоянно отображаются на сервер, что беспокоит если клиентов > 1000.
Топикстартер подскажите как элегантнее организовать через БитСинх схему с 3 серверами и синхронизации между ними определённой папки, в которую каждый из серверов кладёт свои файлы, а остальные забирают эти файлы.
-del-
прошу прощения, не в то окошко написал
прошу прощения, не в то окошко написал
Sign up to leave a comment.
Некоторые наблюдения и советы по использованию Bittorrent Sync для синхронизации резервных копий