Некоторые наблюдения и советы по использованию Bittorrent Sync для синхронизации резервных копий

    Как только выпустили Bittorrent Sync, я сразу его стал использовать для резервирования файлов на домашнем компьютере, настроив штатным образом через web-интерфейс. Программа показала себя с наилучшей стороны, и у меня появилось желание использовать её также для копирования резервных копий на серверах…

    Я настроил и использую уже около месяца Bitorent Sync в продакшене и готов поделиться некоторыми наблюдениями.

    Итак, есть сервер с какими-то данными. Ночью по крону запускается скрипт, который их собирает, архивирует, шифрует, складывает на отдельный раздел на этом же сервере. Потом другой сервер скачивает эти архивы себе. В итоге имеем 2 экземпляра резервных копий.
    Созданием архивов у меня занимался самописный скрипт, копированием — rsync.

    Если поменять в цепочке создания резервных копий rsync на Bitorent Sync (далее btsync), то кардинально ничего не меняется, но есть некоторые отличия:

    Актуальность резервных копий

    В случае с rsync копирование либо по крону в установленное время, заведомо позже чем время создания бэкапа. Либо инициирование копирования не с сервера хранения бэкапов, а с сервера на котором они создались и сразу после их создания. Во втором случае усложнение скриптов и сомнения в надёжности хранения (в том плане, что копии можно удалить удалённо имея доступ к серверу, с которого эти копии снимались)
    В случае с btsync — файлы начинают копироваться сразу по мере создания (и тут есть нюанс, о котором в конце статьи).

    Скорость копирования и загрузка процессора

    Я замерял, копируя с сервера на сервер через кроссовер.
    rsync выдаёт стабильную скорость в 165Мбит/сек при загрузке процессора 70-80% одним потоком
    btsync выдаёт скорость 180-220Мбит/сек при сильно скачущей загрузке процессора: 40-150% в несколько потоков
    На реальных скоростях при копировании через интернет разница будет незаметна.

    Защищённость данных при передаче

    rsync работает через ssh.
    btsync использует свой протокол с шифрованием, но исходных кодов нет (я не особо переживаю по этому поводу, так как все мои файлы зашифрованы длинным ключом через openssl).
    Изначально, зная ключ шифрования btsync, можно скачать файлы откуда угодно и куда угодно, но это отключается настройками.
    btsync позволяет использовать для приёма данных readonly пароль, таким образом обеспечивая защиту от удаления данных на источнике.

    Понимание сути процесса

    rsync с параметрами -v и --progress выдаёт полную информацию о состоянии копирования.
    btsync живёт своей жизнью, логи его крайне скудны, и понять чем он в данный момент занят порой невозможно.

    Установка и настройка применительно к Ubuntu или Debian


    На сайте производителя btsync раздаётся в виде бинарного файла, который при запуске распаковывает свои компоненты по зашитым путям. Для недопущения такого поведения нужно создать конфиг и указать к нему путь. Я пошел более длинным путём и создал deb пакет (по ссылке его исходники и скрипт для сборки).

    После установки надо отредактировать файл /etc/btsync/sync.conf

    { 
      "device_name": "<имя>",   // тут имя компьютера
      "listening_port" : 8889,  // порт, который слушаем (на забудьте открыть в файрволе)
      
      "storage_path" : "/usr/local/lib/btsync/", // путь к хранилищу служебных данных
    
      "pid_file" : "/var/run/btsync/btsync.pid",
    
      "check_for_updates" : false, 
      "use_upnp" : false,
    
      "download_limit" : 0,  // 0 - значит без ограничений
      "upload_limit" : 0, 
    
      "shared_folders" :
      [
    // далее пример настройки ресурса на отдачу
        {
          "secret" : "<secret>", // пароль на ресурс. создаётся командой btsync --generate-secret
          "dir" : "<dir>",   // путь к ресурсу
    
          "use_relay_server" : false, 
          "use_tracker" : false, 
          "use_dht" : false,
          "search_lan" : false,
          "known_hosts" :
          [
          ]
        }
    ,
    // далее пример настройки на приём ресурса
        {
          "secret" : "<secret>", // пароль на ресурс. берётся либо из настройки отдачи, либо генерируется readonly пароль командой btsync --get-ro-secret <пароль>
          "dir" : "<dir>",   // куда складывать принятое
    
          "use_sync_trash" : true,  // складывать удалённые на источнике файлы в локальную "корзину"
    
     // далее отключаем все возможные пути соединения кроме прямого
          "use_relay_server" : false, 
          "use_tracker" : false, 
          "use_dht" : false,
          "search_lan" : false,
          "known_hosts" :
          [
            "<ip-адрес-источника>:8889"   // указываем куда конкретно идти 
          ]
        }
    
      ]
    
    }
    
    


    Добавляя элементы в массив «shared_folders» можно сделать чтоб один сервер раздавал и принимал несколько ресурсов.
    Также наличие в конфиге раздела «shared_folders» начисто отключает web-интерфейс.

    Далее нужно создать все указанные в конфиге директории, дать на них права на запись юзеру btsync, и перезапустить сервис:
    service btsync restart
    


    Лог можно найти по пути /usr/local/lib/btsync/sync.log.
    Если в нем есть строки с руганью на то, что файлы изменились в процессе индексирования, значит придётся немного переделать скрипты чтоб такой ситуации не возникало.
    В файле .SyncIgnore указаны маски файлов которые он игнорирует, я использую одну из уже там имеющихся: "._*". При создании новых файлов сначала даю им имя, начинающееся с точки и подчёркивания, а потом, после завершения архивирования и шифрования, переименовываю.

    Заключение


    Стоит использовать btsync в таком режиме или нет — пусть каждый решает для себя. Мне этот вариант определённо нравится, и возвращаться обратно я не собираюсь. Единственный серьёзный недостаток этой программы — закрытость кода. Не знает ли кто, можно ли ожидать раскрытия исходников?
    Share post

    Similar posts

    Comments 31

      0
      Можно ли при использовании btsync реализовать схему, когда много источников разных данных и один приемник? (т.е. разные данные с нескольких серверов сливаются на один сервер)
        +1
        Конечно. Несколько записей в shared_folders
        0
        Я таким образом делаю синк рабочих данных между пятью машинами. Несколько десятков тысяч файлов от нескольких Кб до сотен Гб. Работает более/менее сносно, иногда только на больших файлах тупит. Больше всего напрягает то, что если изменить в большом файле несколько байт, он его полностью индексирует довольно долго, а потом целиком заново льёт. Я не совсем понял пока почему он считает что это другой файл и не льёт только изменения.
          0
          Может быть потому, что это BitTorrent протокол?
            0
            Наоборот, странно, почему так, несмотря на то, что это bittorrent-протокол. Я бы ожидал, что он перешлёт заново только изменившийся чанк.
              0
              А откуда ему знать что изменилось, а что нет?
                0
                Так каждый файл хешируется почанково. И тут достаточно сравнить хеши.
                  +1
                  Может быть, длина фрагмента меняется и чанки “съезжают”?
                    +1
                    Нет, не меняется. Файл фиксированной длины, условно — база данных. Там приложение меняет 20-30 страниц по 4Кб каждая. После того как приложение «отпустит» файл я наблюдаю сначала долгий процесс индексации (ну тут всё в принципе понятно), а потом вижу как на остальных машинах этот файл удаляется, создаётся новый и начинают литься данные. Что как-раз для bittorrent-протокола выглядит странно.
                      0
                      Может быть, я глупость предлагаю, но что если использовать для этого Git?
                        0
                        Там есть файлы размером в сотни гигабайт, которые мало меняются. Гит будет копировать их целиков, а BTSync вроде в новых версиях уже таки научился копировать только изменения. Да и в принципе вручную контролировать версии через VCS неудобно в данном случае. Нужна именно многосторонняя синхронизация. Данных очень много, но меняются они мало. Вероятность коллизии стремится к нулю. Раньше синхронизация работала через Wuala, сейчас через BTSync — очень удобно.
                          0
                          Git как раз инкрементальный.
                    0
                    Нет, это понятно.
                    Как узнать какой чанк изменился, не перехэшировав весь файл?
                    Приложение которое изменило чанк, должно как-то ведь сообщить об этом.
                      +1
                      Файл не хэшируется полностью. Файл делится на чанки опредленного размера, затем каждый чанк хэшируется по отдельности и потом полученные хэшируется сверяются с эталонными, которые хранятся в torrent-файле. Собственно после этого узнать у какого чанка не сошелся хэш и перекачать
                        0
                        Прошу прощения, я изначально неправильно понял суть вопроса.

                        Мне показалось, что речь идет о том, почему он хэширует все чанки, а не те которые изменились.
                        А суть в том, почему он не дополняет удаленный файл измененными чанками как это делает rsync.
                  0
                  Наверное, вам больше подойдет lsyncd. Это обертка на rsync, соответственно передаваться будут только изменившиеся куски.
                0
                Да, с изменёнными большими файлами он ведёт себя, мягко говоря, некорректно. Благо в моём случае файлы не изменяются, а только добавляются и удаляются.
                  +1
                  Так файлы же шифруются.
                    0
                    Да, возможно в этом проблема. Но только если они там реализовали поточное шифрование. При блочном всё должно быть ок.
                      0
                      Если там CBC (Cipher Block Chaining, Режим сцепления блоков), то зависимость блоков тоже есть.
                      Собственно, CBC — это одно из решений именно криптологической проблемы, возникающей при шифровании блоков независимо друг от друга, в режиме ECB (Electronic code book).
                      В “наивном” ражиме работы (ECB) у злоумышленника по сути есть множество шифротекстов, зашифрованных общим ключом. Для некоторых шифротекстов он знает и оригинальный текст. Например, в случае зашифрованного диска с файлами известно расположение и многие куски значений метаданных ФС, заголовки типичных форматов файлов и так далее. Это сильно облечгит ему работу — например, найдя 100 одинаковых кусков через одинаковые небольшие промежутки он может быть уверен, что набрёл на зашифрованном диске на что–то типа фотоальбома. Соответственно, поле перебора для него сокращается крайне чувствительно.
                      Если же мы будем подмешивать шифротекст предыдущего блока в текст последующего — никаких повторяющихся однотипных кусков злоумышленник обнаружить не сможет. Соответственно, такая атака (их на самом деле несколько родственных) против CBC не получится.
                      Собственно, по вышеуказанным причинам CBC — самый часто встречающийся режим шифрования на данный момент. Всем хорош, на несколько ядер только не парралелится, зараза:(
                  0
                  Вот меня тоже интересовала проблема бэкапов через BT Sync.
                  Но есть одно такое НО:
                  Если на главной машине каким-то образом удаляются данные из расшаренной папки, при это сервис BT Sync-a продолжает рабоать, то бэкапы соответственно пропадают и на удаленных машинах. А потом внезапно главный сервер схлопывается. В итоге не имеем доступа ни к клавному серверу, ни к бэкапах на серверах-зеркалах, потому что бэкапов там уже нет.
                  Возможно это можно решить копированием из расшаренной папки на сервере для бэкапов всего содержимого в другую нерасшаренную папку и выполнять это по крону. Но, опять же, костыль и задержки.
                    +1
                    Против этого есть опция
                    "use_sync_trash" : true
                    в моём конфиге.
                    Все подлежащие удалению при синхронизации файлы складываются в поддиректорию .SyncTrash
                      0
                      Хм. Это, видимо, то что надо. Спасибо за подсказку.
                        0
                        Все равно возможен вариант, что файл остался, но нулевой длины.
                        Версионность ведь не поддерживается?
                        Видимо тут надо использовать уже сторонние инструменты.
                      0
                      установил btsync у себя на QNAP NAS. Загружает на него «на ура», а вот NAS отдаёт по 0.4Кб/сек, хотя лимитов в конфиге btsync нет. Это можно было бы списать на недонастройку NAS или роутера, но на нём же отлично крутится Transmission…
                      Кто-нибудь сталкивался с такой проблемой?
                        0
                        Я тоже столкнулся с такой траблой. Как лечить, пока неизвестно…
                          0
                          Если про QNAP, то в новой прошивке появился специальный пакет bitsync в приложениях. А до этого вылечил обновлением прошивки qnap на новую версию
                        0
                        Для себя вижу 2 беды (как битторент-клиент загрузка):
                        — невозможно загрузить один файл из тысячи (сервер раздает, клиенты забирают)
                        — в цепочки много клиентов — 1 сервер, клиенты (IP) постоянно отображаются на сервер, что беспокоит если клиентов > 1000.
                          0
                          Топикстартер подскажите как элегантнее организовать через БитСинх схему с 3 серверами и синхронизации между ними определённой папки, в которую каждый из серверов кладёт свои файлы, а остальные забирают эти файлы.
                            0
                            всё разобрался… проблема была в правах доступа… попробовал сначала через вебинтерфейс всё реализовать задуманное, а потом чисто в консоли и всё получилось.
                            0
                            -del-
                            прошу прощения, не в то окошко написал

                            Only users with full accounts can post comments. Log in, please.