Developing on the BitTorrent Sync API? Our developer evangelist is here to work with you.

This is a guest post by Viktor Petersson, VP of Business Development at CloudSigma.

From Viktor:

Before using Sync, my backup strategy was largely based on a bunch of “rsync” scripts that pushed data to various servers and external drives. It was messy and somewhat hard to automate, given that it often involved encryption. As a result, it was often neglected.

Another challenge I had was to keep two devices in sync (i.e. two-way sync). This isn’t something that “rsync” supports and was initially one of the reasons why I was eager to try out Sync.

What I found after using Sync for a while was that it works great to sync even a large amount of data over a local network, while both devices were using a wired network connection. Unfortunately, this isn’t always the case.

What I really needed was a server with good connectivity that was always accessible to sync with. That way, even if the computer at home was powered off, there was still a server that would pick up and seed the changes. This also provided an additional copy of your data, should for some reason both the laptop and home computer break down simultaneously.

If you’re a Sync user, chances are you’re concerned about where and how you store your data. You should be, and so am I. Yet, it’s hard to overlook the benefits of putting such a server in the cloud.

There are two ways you can use a public cloud server, but still keep your data safe with Sync:

Encryption secrets, which is a built-in feature in Sync. This is the easiest approach, as it doesn’t require anything particular on the server. For more information about the various key/secret types, take a look at Aaron’s post A Look Into How Keys Work. It does however require a bit more work, as well as a developer key for the time being.
Disk encryption, which basically means that you’re storing your data into an encrypted partition/volume (or using Full Disk Encryption). This can of course be combined with *encrypted secrets* for additional security.

For the initial setup, I simply added an encrypted volume to an Ubuntu server in Zürich, Switzerland (running on CloudSigma). I then added the shares using the web interface. This worked out pretty well, but as I configured my second *seed* server, I realized that there was room for improvement.

Enter Docker
I had been playing with Docker for some time. It then hit me one day that that if I compartmentalized each share into its own Docker container, it would simplify deployments a lot. That way I could easily manage them over SSH, while also rapidly deploy new shares and swiftly roll out updates.

How to install Docker is outside the scope of this article (you’ll find a great guide here), but we will cover how to install the Sync container.

First, we pull down the Docker image from the repository:

$ docker pull vpetersson/btsync

With that done, we can now start spinning up instances using the following command:

$ docker run -d \
-p 55555 \
-e "SYNCKEY=YourSyncKey" \
-e "MYHOSTNAME=$HOSTNAME" \
--name "NameOfYourShare" \
-v /local/storagepath:/sync/storage \
vpetersson/btsync

As you can see, you pass on all the required parameters into Docker, which in turn will take them and spin up a “btsync” process. Given this approach, there is no need for a web interface.

There’s also a script that you can use that will simplify this a bit further.

You can find additional information about the various parameters, as well as the full source code, in the GitHub repo. If you’re having issues with the container, please open an issue on Github or submit a pull request.

Managing your containers is easy. Starting and stopping each individual container can be done with the following commands:

$ docker start NameOfYourShare
$ docker stop NameOfYourShare

You can create as many containers as you’d like. If you’d like to check in on the logs from the containers, simply run:

$ docker logs NameOfYourShare

That’s it. You now have a Dockerized BitTorrent Sync environment!

After running this setup now for a few months, I’ve come across a few ‘gotchas’:

Only use read-only and encrypted keys for *seed* nodes. This minimizes the risk, as you know that these nodes cannot send any data back to your workstation(s).
While it might be tempting to sync your entire home directory (or perhaps “~/Documents” on OS X), I’d discourage you from doing this. If you do this, chances are your computer will be in a constant sync state, as there will be changes written all the time. Instead, create a sync folder, such as “~/Sync” and then store the data there and simply symlink folders (i.e. “~/Pictures” -> “~/Sync/Pictures”). That way, you can keep your regular folder structure, but still keep them synced.
On OS X, you may need to manually add a few entries to the “.SyncIgnore” files. Here are the ones I’ve added.