<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Mozy (the backup client): damn close, but still no cigar...</title>
	<atom:link href="http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/feed" rel="self" type="application/rss+xml" />
	<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar</link>
	<description>&#34;Lazy people are efficient.&#34; - My boss.</description>
	<lastBuildDate>Mon, 30 Apr 2012 14:27:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: mike</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-22344</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Thu, 17 Feb 2011 06:55:21 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-22344</guid>
		<description>&lt;a href=&quot;#comment-22274&quot; rel=&quot;nofollow&quot;&gt;@Oh Loki &lt;/a&gt; 
Well, for that you just have to put trust in them, I suppose. I don&#039;t know if anyone has done an audit that they don&#039;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&#039;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.</description>
		<content:encoded><![CDATA[<p><a href="#comment-22274" rel="nofollow">@Oh Loki </a><br />
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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oh Loki</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-22274</link>
		<dc:creator>Oh Loki</dc:creator>
		<pubDate>Mon, 14 Feb 2011 18:11:17 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-22274</guid>
		<description>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 &#039;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

&quot;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. &quot;

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?

.

&quot;We destroy the unencrypted 128-bit AES key at the end of each backup session and never write it to disk.&quot;

And that makes the trust model better how?

.

&quot;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. &quot;

Oh how nice.  Then I /merely/ need provide my key &quot;safely&quot; over https to their datacenter for it to apply my key there and then &quot;safely&quot; be destroyed.

So safe!!?

Explain how that is client side encryption?

The /data/ they receive from me must NEVER be /information/.


]SH[</description>
		<content:encoded><![CDATA[<p>mozy /seems/ nice until one reads their tos/privacy.  It lacks client side encryption.</p>
<p>@nomad<br />
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 <img src='http://michaelshadle.com/wordpress/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
<p>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.</p>
<p>@mike</p>
<p>client side encryption with BB appears promising: <a href="http://blog.backblaze.com/2008/11/12/how-to-make-strong-encryption-easy-to-use/" rel="nofollow">http://blog.backblaze.com/2008/11/12/how-to-make-strong-encryption-easy-to-use/</a></p>
<p>But can I avail myself of my symmetric 40 megabit/s fios connection fully?  </p>
<p>.</p>
<p>hmmm</p>
<p>"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. "</p>
<p>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?</p>
<p>.</p>
<p>"We destroy the unencrypted 128-bit AES key at the end of each backup session and never write it to disk."</p>
<p>And that makes the trust model better how?</p>
<p>.</p>
<p>"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. "</p>
<p>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.</p>
<p>So safe!!?</p>
<p>Explain how that is client side encryption?</p>
<p>The /data/ they receive from me must NEVER be /information/.</p>
<p>]SH[</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-13671</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Sun, 09 Aug 2009 17:45:30 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-13671</guid>
		<description>&lt;a href=&quot;#comment-13670&quot; rel=&quot;nofollow&quot;&gt;@veggie monkey &lt;/a&gt; 

Actually, now I use &lt;a href=&quot;http://www.backblaze.com/&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&gt;Backblaze&lt;/a&gt; - it&#039;s kind of the same concept as Mozy, except it&#039;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&#039;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 &quot;set it and forget it&quot;

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.</description>
		<content:encoded><![CDATA[<p><a href="#comment-13670" rel="nofollow">@veggie monkey </a> </p>
<p>Actually, now I use <a href="http://www.backblaze.com/" target="_blank" rel="nofollow">Backblaze</a> - it's kind of the same concept as Mozy, except it's upload and download are -way- faster.</p>
<p>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"</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: veggie monkey</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-13670</link>
		<dc:creator>veggie monkey</dc:creator>
		<pubDate>Sun, 09 Aug 2009 17:44:42 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-13670</guid>
		<description>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 &quot;abuse&quot; question?</description>
		<content:encoded><![CDATA[<p>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?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-1984</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Mon, 17 Sep 2007 07:08:44 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-1984</guid>
		<description>Thanks for the tip. I&#039;ve used BestCrypt in the past. It isn&#039;t as &quot;open&quot; or repurposeful as TrueCrypt. I actually made a script to sync two BestCrypt containers together by mounting and rsyncing. I wasn&#039;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&#039;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&#039;s my most promising idea yet. The hard copies of the files would be named in a generic format and then it doesn&#039;t matter if the service encrypts the filenames or not.</description>
		<content:encoded><![CDATA[<p>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)</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nomad</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-1983</link>
		<dc:creator>Nomad</dc:creator>
		<pubDate>Mon, 17 Sep 2007 06:14:30 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-1983</guid>
		<description>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&#039;s the script I used.

First, I run the SyncToy profile &quot;Dellbert Data&quot; - an unencrypted &#039;echo&#039; backup
Then, I mount the encrypted Backup.tc file onto the U: drive
Then I run the SyncToy profile &quot;Dellbert Encrypted&quot;, an &#039;echo&#039; 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 ...
&quot;C:\Program Files\synctoy\SyncToy.exe&quot; -R&quot;Dellbert Data&quot;
&quot;C:\Program Files\TrueCrypt\TrueCrypt.exe&quot; /v c:\Backup.tc /lu /b /q
&quot;C:\Program Files\synctoy\SyncToy.exe&quot; -R&quot;Dellbert Encrypted&quot;
&quot;C:\Program Files\TrueCrypt\TrueCrypt.exe&quot; /q /du</description>
		<content:encoded><![CDATA[<p>Try this. It works great for me.</p>
<p>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.</p>
<p>First, I run the SyncToy profile "Dellbert Data" - an unencrypted 'echo' backup<br />
Then, I mount the encrypted Backup.tc file onto the U: drive<br />
Then I run the SyncToy profile "Dellbert Encrypted", an 'echo' backup to the encrypted file.<br />
Then the encrypted file is unmounted.</p>
<p>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.</p>
<p>@echo off<br />
echo .Backing up and Encrypting ...<br />
"C:\Program Files\synctoy\SyncToy.exe" -R"Dellbert Data"<br />
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /v c:\Backup.tc /lu /b /q<br />
"C:\Program Files\synctoy\SyncToy.exe" -R"Dellbert Encrypted"<br />
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /du</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/comment-page-1#comment-735</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Tue, 29 May 2007 07:35:12 +0000</pubDate>
		<guid isPermaLink="false">http://michaelshadle.com/2007/05/07/mozy-the-backup-client-damn-close-but-still-no-cigar/#comment-735</guid>
		<description>&lt;p&gt;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.)&lt;/p&gt;

&lt;p&gt;If I recall I was told they were working on this. But I am trying to figure out where I saw that.&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>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.)</p>
<p>If I recall I was told they were working on this. But I am trying to figure out where I saw that.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

