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