Why not just use RSync?


Recommended Posts

The topic "Why not just use RSync?" - you're kidding, right?

Sorry for my levity, not meaning to take the mickey. But rsync is a strictly one to one protocol.

Here's a scenario for you: let's assume we have 5 web servers that has to be kept in sync - code, assets (i.e. documents, videos, mp3's and more). Then one of the server goes down. You now need to rebuild it, ensuring the new server is fully updated with all the latest code and documents. It's got a new IP address. Using rsync you'll at the very least have to change configuration files to get it to work. And which is your "master" rsync host? What if your "master" host goes down? Where do you then initiate rsync from? How do you reconfigure your rsync pushing of data?

And how do you maintain and manage the network of computers? Which server updates the others? Which is the backup for the master? How do you change the configuration on the fly if the master goes down? What if the data center goes down and you need to very quickly migrate your whole structure to a different data center?

Here's how I will use BT Sync: simply install it on all the servers, plus on an off-site backup server or two. Server goes down? No problem, just install BT Sync, add the secret, and all resources, code, assets and everything is automatically restored.

Server config? Well, it's just another synchronised directory.

Backups? Dump my MySQL backups to a synchronised directory, and it will be stored off-site. Automatically, without any effort. No need to push anything, or pull anything. My home PC is a backup for my online server, but I'm on a dynamic IP? No problem - I don't need to know when the backup routine runs, I don't need to know when it finishes (so I can pull the data), I don't need to worry about Dynamic DNS, I don't need to worry about firewalls and port redirection.

In fact, it took me a minute to install on my PC, it took me another minute to install my server. And files were starting to synchronise within another minute. Wow, that was easy. I'm just about to install it on 3 other servers under my control, and you know, I think I will just delete the old backup rsync routines I had written.

My wish list?

1) Detect shifted data as it saves time, potentially a lot of time, during transfer.

2) Notifications or script execution when transfers are fully synchronised - I would use this to automatically shut down the backup server, or even to send an email, write to a log file or send a gtalk notification that things are happening as they should.

So from me: a big, big HUUUUGE thank-you for developing this!!!

Link to post
Share on other sites

If we're talking about beat practices, you shouldn't be using sync to manage a web server. What you should be doing is having a development code base, in a version control system (assume git) you have release and testing branches, and your production server just pulls the release branch. The fact that you can check in any tweaks (usually config mgt) from the production webserver and inegrate them into the dev branch is a very valuable back-flow.

Link to post
Share on other sites

Sure - let me add, btw, that if anyone uses BTSync to distribute web code to various production web servers you're likely to have a severe issues with file versions being out of sync, and your whole application may fail whilst the servers are updating. I would NOT recommend that as the normal way to update code base.

Link to post
Share on other sites

Whilst on the topic of backup - very importantly, to make it 100% clear - using BTSync as a backup solution is only suitable for disaster recovery.

If you have a malicious attack on your server, and they succeed in deleting files, the deletion of those files will also replicate and the files will be deleted in all of your backups.

Link to post
Share on other sites


This topic is now archived and is closed to further replies.