Некоторые наблюдения и советы по использованию 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 в таком режиме или нет — пусть каждый решает для себя. Мне этот вариант определённо нравится, и возвращаться обратно я не собираюсь. Единственный серьёзный недостаток этой программы — закрытость кода. Не знает ли кто, можно ли ожидать раскрытия исходников?