I recently signed up for an account at Jungle disk, http://www.jungledisk.com.
I’m paranoid about backups, I use Time Machine to do a full weekly backup and Jungle Disk as an off-site backup solution. It seemed the cheapest option since you only pay for what you upload, and although I have a full 160GB hard drive, my sensitive files only total about 10 GB. At 0.18$/Month that’s 1,8$/Month + bandwidth.
Jungle Disk Uploads files to an Amazon S3 disk, in my case, located in Europe. I chose to pay 0.03$/Month + bandwith extra for that location because I thought latency would influence the speed of my backups, that’s why I went with Amazon over Rackspace. I’ll probably migrate anyway when Jungle Disk offers a migration tool for this.
I have access to an internet connection with a symmetric 100 Mbit link so I was surprised when I noticed jungle disk was only using about 40 KB/s. After thinking about it, it actually makes sense.
The reason for the slowness of the backup is due to several factors.
Jungle Disk Uploads Individual files, not a big compressed file containing all files to be backed up.
In practice, this means JD does not have a continuous stream of bytes to upload like with a big file, instead it has to stop sending information while preparing to send the next file (including encrypting, it see next item). Besides, it needs to setup the S3 file system to receive the new file. During this time, the TCP connection is almost stopped. When JD starts uploading the next file, the TCP connection already lost all it’s speed, that’s why the speed is only high when JD is uploading big files, the TCP connection has enough time to adjust and recognize the speed of the link.
Jungle Disk Encrypts the files using AES before sending it over the internet through a SSL connection. (UPDATE: This is wrong, see comments)
This means JD has to stop sending files until it finishes encrypting and entire file. This could be solved if JD could encrypt files at the same time it sends the previous file. This could reduce the time the TCP connection is stopped.
Uploading only differences is not really an improvement.
While it’s true that uploading only new files or changed files is a big improvement, uploading only the differences of the files themselves it’s not that big of an improvement. When you think about it, what files have you edited lately with small differences? Text files? So you only send 10 KB instead of 50KB? You gain 40KB? That’s nothing in today’s bandwidth speeds. When you edit a big file, like a big image, you most likely edited a big part of the file and you still have to upload most bytes of the file.
Jungle Disk is a really nice service, and I think it’s the best you can get. Probably there’s not an off-site backup solution that isn’t slow. Besides, it’s only slow the first time, when you have to upload 10GB in one time, after that you only have to upload new or changed files, that’s about 1GB per backup in my case.
If you don’t have an off-site backup solution yet, Jungle Disk is the way to go. And you DO need an off-site backup solution, right?
Comments 2
You’re right on at least one point, but a few of these aren’t accurate. It’s true that JD uploads files one at a time, and that does cause lower throughput when uploading smaller files. That’s something we’ll be addressing in the near future.
Posted 26 Jun 2009 at 2:07 am ¶Regarding encryption, encryption is done in real-time as the file is uploaded and doesn’t affect transfer speed at all.
Block level updates are only done for large files (>1MB in size) so they don’t affect small files at all.
Hello!
OK, I thought JD encrypted a file entirely before sending it. Actually I was stupid to think that because even with more complex block cipher modes of operation JD can begin sending the file before finishing it’s encryption. My bad.
About the block level updates, that’s my point exactly, there’s no use in uploading differences for small files and when I edit big files I probably change most of the bits in the file so JD still has to send most of the new file.
Thanks for your comment.
Posted 26 Jun 2009 at 2:19 am ¶Post a Comment