Mozy (the backup client): damn close, but still no cigar...
Mozy's got what seems to be a nicely integrated Windows client (not sure how good their Mac client is) - their service seems simple enough, and you can't go wrong with two gigs free or unlimited (I've been questioning how much it takes before it becomes "abuse") for an extremely low $4.95/month.
However, this going back to my blog post a while ago about the end all backup solution, it still is missing one key thing. While the transfer is encrypted and the file contents are encrypted (optionally), the file and directory names are not. When I asked support, the response back was "how would you know what the file is then?" - to me, it's simple. You have an encryption key, why can't the filenames be encrypted as well using the same key, and decrypted on demand? I understand this complicates things then (how do you store junky filenames/etc...) - you'd most likely need a customized filesystem or some virtual layer between the two to do the translation. However, that would basically make Mozy the king in my book for Windows and I assume Macs (read: any level of savvy end-user who wants their data backed up.)
I would still be shopping though for one to use to backup my servers. Duplicity still seems like the best, as it will compress, encrypt, and do differential/incremental backups and due to the nature of how it works, will also mask the file contents so only the user can see them. Rsync.net has recently announced funding and support to help pump some life back into the project, which is promising. It needs native Windows support (which may be tricky... it needs a POSIX compliant backend) and proper S3 integration without patches or external libraries and hacks.
Of course, I was having fun developing my own little PHP interface to S3, which if possible I could then wind up creating my own tools; however, do I really trust my own coding for my critical data and extremely large filesizes? Because it's over HTTP, it's tricky (or maybe impossible) to byte-serve the data in PHP without precaching it into memory first... ah well.
Someone needs to create an efficient C-based one that can be compiled in Windows, OS X, and Linux. Any takers? I'll pay...
Actually, on hindsight, if Mozy can figure out how to encrypt filenames on the client end, store it in a database that is backed up as well (and encrypted!) and work that into their client, they might have it made for Windows and Mac machines. Still have the Linux segment to deal with though (and headless server/command line clients, cough cough.)
If I recall I was told they were working on this. But I am trying to figure out where I saw that.
Try this. It works great for me.
You need TrueCrypt, SyncToy, and a Mozy account. Create a TrueCrypt file bigger than what you need for backup. For instance, my critical files are about 250MB, so I created a TrueCrypt file of 400MB. Write a little script, using the command line capabilities of both SyncToy and TrueCrypt to open the encrypted storage, mount it as a drive, do your backup to it, then unmount it. Now use Mozy to backup the encrypted file. Here's the script I used.
First, I run the SyncToy profile "Dellbert Data" - an unencrypted 'echo' backup
Then, I mount the encrypted Backup.tc file onto the U: drive
Then I run the SyncToy profile "Dellbert Encrypted", an 'echo' backup to the encrypted file.
Then the encrypted file is unmounted.
All I have to do now is use Mozy to Backup.tc. Since Mozy uses block transfer, only the changed parts of the encrypted file are transferred over.
@echo off
echo .Backing up and Encrypting ...
"C:\Program Files\synctoy\SyncToy.exe" -R"Dellbert Data"
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /v c:\Backup.tc /lu /b /q
"C:\Program Files\synctoy\SyncToy.exe" -R"Dellbert Encrypted"
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /du
Thanks for the tip. I've used BestCrypt in the past. It isn't as "open" or repurposeful as TrueCrypt. I actually made a script to sync two BestCrypt containers together by mounting and rsyncing. I wasn't a fan though; Windows refused to cleanly unmount the drives sometimes. Putting large amounts of data into single file containers scares me sometimes though... not to mention file size limitations, lack of being able to individually diff the files (it would wind up transferring the entire thing each time)
I actually have an idea for a local filename obfuscation system with links setup based on file type and metadata (much like an iPod does) - however I don't know filesystem mechanics good enough and trying to get a PHP-driven WebDAV server was a failure. Symlinks off a UNIX-based filesystem works great, but needs proper garbage collection for dead links. That's my most promising idea yet. The hard copies of the files would be named in a generic format and then it doesn't matter if the service encrypts the filenames or not.
I backed up 120GB on my account. Did so for months. Their tech support said I could do a terabyte if I wanted to. Does that answer your "abuse" question?
@veggie monkey
Actually, now I use Backblaze - it's kind of the same concept as Mozy, except it's upload and download are -way- faster.
The biggest thing that bugs me is it backs up everything (besides a select few system areas) by default. You have to make a blacklist of what you don't want. I like Mozy in the sense of you flag what you DO want. I submitted a request for them to make it a feature for a whitelist vs. blacklist approach, but who knows. Their philosophy is "set it and forget it"
I have successfully downloaded 60+ gigs of content back from their servers too, and it was about as fast (if I recall) as my connection would allow. Everything with Mozy included their upload to their servers seemed slow.
mozy /seems/ nice until one reads their tos/privacy. It lacks client side encryption.
@nomad
TC is an interesting approach. You must have excellent discipline to keep only those files you would wish to archive in that TC file volume
I use Amazon S3. There are several functional free clients for Android that place nicely on the motorola (throttled) firmware [mmm class action], or throttlefree roms. There are some free 'doze clients that provide an FTP interface to S3.. or rely completely on XUL for cross platform. Amazon has a long history of pouring money into something until it works. These other l*feh*cker sanctioned services are in retrospect fly-by-night bandits.
@mike
client side encryption with BB appears promising: http://blog.backblaze.com/2008/11/12/how-to-make-strong-encryption-easy-to-use/
But can I avail myself of my symmetric 40 megabit/s fios connection fully?
.
hmmm
"We generate a new 2048-bit RSA public/private key pair when our client is installed, store the public key on the local disk and transmit the private key to our datacenter via https. Then, for each backup session, we generate a new random 128-bit AES symmetric key which we use to encrypt the user’s data. "
How nice of them to store my private key for me on their gear? I must trust them loads? And they generate and keep my symmetric key for me.. thanks?
.
"We destroy the unencrypted 128-bit AES key at the end of each backup session and never write it to disk."
And that makes the trust model better how?
.
"But for some users this is not good enough and we allow the user to secure this file with their own password. When this is done it is impossible to access the data without the user’s password. "
Oh how nice. Then I /merely/ need provide my key "safely" over https to their datacenter for it to apply my key there and then "safely" be destroyed.
So safe!!?
Explain how that is client side encryption?
The /data/ they receive from me must NEVER be /information/.
]SH[
@Oh Loki
Well, for that you just have to put trust in them, I suppose. I don't know if anyone has done an audit that they don't actually have actual unencrypted files from people. I also would like to have the file *names* to be encrypted too - so they have no idea of the file structure, etc.
Both Mozy and BB allow you to create your own key based on a password. Mozy is dead to me though, I've been loyal to BB for a long time and they continue to be transparent with their communications. I have a more recent blog post relating to leaving Mozy.