Some observations and tips on using Bittorrent Sync to synchronize backups

As soon as Bittorrent Sync was released, I immediately began using it for backing up files on my home computer, setting up it in a regular manner via a web interface. The program showed itself from the best side, and I had a desire to use it also to copy backups to servers ...

I have been setting up and using Bitorent Sync for about a month in production and am ready to share some observations.

So, there is a server with some data. At night, a script is launched according to crown, which collects them, archives, encrypts, and puts them on a separate partition on the same server. Then another server downloads these archives to itself. As a result, we have 2 copies of backups.
I created the archives with a self-written script, copying it with rsync.

If you change rsync backups on Bitorent Sync in the chain (hereinafter referred to as btsync), then nothing changes radically, but there are some differences:
')

Backup Relevance

In the case of rsync, copying either by crown at a set time, obviously later than the time of creating a backup. Either the initiation of copying is not from the backup storage server, but from the server on which they were created and immediately after their creation. In the second case, the complexity of scripts and doubts about the reliability of storage (in the sense that copies can be deleted remotely with access to the server from which these copies were taken)
In the case of btsync, files begin to be copied immediately as they are created (and there is a nuance about which at the end of the article).

Copy speed and CPU load

I measured, copying from server to server via crossover.
rsync produces a stable speed of 165 Mbit / s with a processor load of 70-80% in one stream
btsync delivers a speed of 180-220 Mbit / s with a strongly skipping processor load: 40-150% in several streams
At real speeds when copying via the Internet, the difference will not be noticeable.

Transmission Security

rsync works via ssh.
btsync uses its own protocol with encryption, but there are no source codes (I'm not really worried about this, since all my files are encrypted with a long key through openssl).
Initially, knowing the btsync encryption key, you can download files from anywhere and anywhere, but this is disabled by settings.
btsync allows you to use a readonly password to receive data, thus providing protection against deleting data at the source.

Understanding the essence of the process

rsync with the -v and --progress options gives full information about the copy status.
btsync lives its own life, its logs are extremely scarce, and it is sometimes impossible to understand what is currently busy with.

Installation and configuration in relation to Ubuntu or Debian

On the manufacturer's website, btsync is distributed as a binary file, which, when launched, unpacks its components along hardwired paths. To prevent such behavior, you need to create a config and point the way to it. I went a longer way and created a deb package (by reference its source and build script).

After installation, you must edit the file /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" //     ] } ] } 

Adding elements to the “shared_folders” array can be done so that one server distributes and accepts several resources.
Also, the presence in the config section of the “shared_folders” section completely disables the web interface.

Next, you need to create all the directories specified in the config, give the rights to write to the btsync user, and restart the service:

 service btsync restart 

The log can be found along the path /usr/local/lib/btsync/sync.log.
If there are lines in it with a scolding that the files have changed during the indexing process, then you have to redo the scripts a bit so that this situation does not arise.
The .SyncIgnore file contains file masks that it ignores, I use one of the ones already there: "._ *". When creating new files, I first give them a name starting with a dot and underscore, and then, after archiving and encryption, I rename it.

Conclusion

Whether to use btsync in this mode or not - let everyone decide for themselves. I definitely like this option, and I'm not going back. The only serious drawback of this program is the closeness of the code. Does anyone know if you can expect the disclosure of the source?