<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>The BFC Computing Weblog: SuperDuper considered Harmful</title>
    <link>http://blog.bfccomputing.com/articles/2007/04/11/superduper-considered-harmful</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>My God, It's Full of Source!</description>
    <item>
      <title>SuperDuper considered Harmful</title>
      <description>&lt;p&gt;I&amp;#8217;ve recommended &lt;a href="http://www.shirt-pocket.com/SuperDuper/SuperDuperDescription.html"&gt;SuperDuper&lt;/a&gt; to a few folks looking at Mac Backup solutions based on &lt;a href="http://blog.plasticsfuture.org/2006/04/23/mac-backup-software-harmful/"&gt;this survey&lt;/a&gt; so I figured it was time I implemented it myself.  I&amp;#8217;m sorry to report results are poor.&lt;/p&gt;

&lt;p&gt;For some reason SuperDuper gets confused when copying some files.  I think there&amp;#8217;s probably a race condition with transient files.  It reports I/O errors on files that no longer exist when I look at them, and I/O errors on files that I can copy by hand, with cp, and with ditto just fine.  It&amp;#8217;s not open source, so it&amp;#8217;s hard to say exactly why that happens.&lt;/p&gt;

&lt;p&gt;Now, that, in and of itself, wouldn&amp;#8217;t be a huge problem - I see the same kind of thing with rsync, and any other backup tool (but perhaps not with ZFS snapshots &amp;#8211; but that&amp;#8217;s another article).  However, SuperDuper stops the backup process when it hits a few of these errors, leaving a potentially not-backed up disk, for a few file copy errors.&lt;/p&gt;

&lt;p&gt;Since I was planning to purchase SuperDuper, I sent the developer a note about it.  His built-in reporting tool is very smart about integrating with AppleMail and used the Keychain appropriately - a nice touch.  He wrote back with a link to &lt;a href="http://www.shirt-pocket.com/blog/index.php/comments/i_o_error_recovery/"&gt;a blog article&lt;/a&gt; he wrote about this issue as a response, and assured me that not to worry, most of the files were backed up anyway.&lt;/p&gt;

&lt;p&gt;His point is that if there&amp;#8217;s an I/O error, then you have a disk problem and need to get that looked at.  Now, he has a point - if there&amp;#8217;s a real disk error his tool isn&amp;#8217;t going to fix it.  But, in this case, there&amp;#8217;s no apparent disk error, so the behavior of SuperDuper is incorrect.  Even if there were a disk error, I&amp;#8217;d be trying to use a disk backup tool to recover the data.  Sure, if you have $2K, send it off to DriveSavers - they&amp;#8217;ll do a better job, but most people don&amp;#8217;t.&lt;/p&gt;

&lt;p&gt;But besides that, his assertion that most of the files were copied anyway was incorrect, by SuperDuper&amp;#8217;s own reporting (and a visual inspection of the target disk image) &amp;#8211; in my case, SuperDuper stopped after 553,643 of 1,987,938 files.  So, not so complete.&lt;/p&gt;

&lt;p&gt;Clearly, for my usage, SuperDuper wasn&amp;#8217;t copying most of the files, and was stopping on false I/O errors.  This makes for an unusable backup tool. &lt;/p&gt;

&lt;p&gt;So, I wrote back to the developer, explaining what I had seen and asking if he could include an option to allow the user to decide whether continuing after I/O errors was the right thing to do (most tools - rsync, dd, etc. all have such an option).&lt;/p&gt;

&lt;p&gt;This is the entirety of his response:&lt;/p&gt;

&lt;blockquote&gt;
    &lt;p&gt;From:    support@shirt-pocket.com&lt;br&gt;
    Subject:   Re:(Case 38299) SuperDuper!: Error during copy - copy stops due to I/O errors&lt;br&gt;
    Date:  April 10, 2007 18:51:38 EDT&lt;br&gt;
    To:      bill@bfccomputing .com&lt;br&gt;
    &lt;br&gt;
    I&amp;#8217;m sorry this is a problem for you, Bill, but I wish you the best in finding a good alternative.&lt;br&gt;
    &lt;br&gt;
    Dave Nanian&lt;br&gt;
    Shirt Pocket&lt;br&gt;&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Clearly, he feels so strongly that his behavior is the correct one that he&amp;#8217;s willing to forgo many sales to not give the user a choice in the matter.  I respect his conviction while strenuously disagreeing with his conclusion.  So, if I&amp;#8217;ve recommended SuperDuper to you previously, please consider that recommendation rescinded and accept my apologies for not testing it thoroughly enough first.  I&amp;#8217;ll try to e-mail a link here to everybody I can recall.&lt;/p&gt;

&lt;p&gt;Now, that leaves the problem of what to use for Mac backup software.  I have some Enterprise clients using a version of rsync I patched up.  I&amp;#8217;ve done some ditto backups locally.  But all of those things have problems, and none are currently the right answer.  rsync is probably the one with a chance, since it&amp;#8217;s open source, but the patch sets to date are inadequate.  If the entire problem with &lt;a href="http://lists.apple.com/archives/Darwin-dev/2006/Jun/msg00276.html"&gt;copyfile()&lt;/a&gt; is fixed in Leopard (perhaps via ZFS) then rsync can start working.  I&amp;#8217;ll be testing that once I&amp;#8217;m confident I have a good backup of my laptop (a Catch-22, no?).  Otherwise, it&amp;#8217;s probably going to be time to start up a SourceForge project to get interested collaborators together to come up with a working solution.&lt;/p&gt;</description>
      <pubDate>Wed, 11 Apr 2007 08:16:00 -0400</pubDate>
      <guid isPermaLink="false">urn:uuid:620ac7a2-0862-4831-827d-5aa056b793bd</guid>
      <author>Bill McGonigle</author>
      <link>http://blog.bfccomputing.com/articles/2007/04/11/superduper-considered-harmful</link>
      <category>Mac</category>
      <category>backup</category>
      <trackback:ping>http://blog.bfccomputing.com/articles/trackback/4638</trackback:ping>
    </item>
  </channel>
</rss>
