I've Given Up on Super Duper
 

I'm really sick and tired of having SuperDuper fail during smart updates. It really has cost me far too much time and energy. The problem?

When smart updating large volumes (100's of GB's or several TB's) SD will copy first then delete. 90% of the time in this situation I will run out of disk space on my destination volume because often times a project folder (I'm a composer writing music for feature films so you can probably imagine my project folders often exceed 40GB's) will be moved to another location on my source volume or even possibly get renamed.

Even though the volume I'm mirroring to is of equal size as the source, the backup consistently fails because SD is DELETING said project folders from the destination only AFTER it has tried to copy the seemingly new project folder (even though it may really just have been renamed or moved)

The argument the developer uses to justify this as the ONLY reasonable smart update behavior is that deleting before copying starts is dangerous because what if there is a hardware failure during the backup operation, you'd loose that project folder and any others that have been moved or renamed on the source volume.

This is flawed logic for two very important reasons:

1. A failed smart update under these circumstances means the user has to perform an erase and backup to get it to work, thus exposing their ENTIRE volume to data loss in the event of a hardware failure. (Not to mention the needless wasting of their time and system availability)

2. Any half-way experienced sys admin keeps AT LEAST 3 backups of their critical data with one being located off-site in case of theft, fire or natural disaster.

I'm not saying this should be the default mode of operation (preference setting would do just fine). But seriously it's been over 2 years and nothing has been done to address what I and many others in the audio and video industry see as an obvious and serious short-coming of this software.

So, I've decided to discontinue use of this software (with the exception of creating bootable system backups) until the developer does something to address the situation. For the foreseeable future I'll be using RSYNC to perform my mirroring operations with the, oh so nice -DELETE-BEFORE command line argument.

It adds an extra 5 minutes to my backup routine, but compared to having SD continually erasing and backing up a 4 TB volume, it's a small price to pay.

I'm sorry for your frustration. As I've said elsewhere, and in the User's Guide, we do not "copy before". We "act on encounter", which means we may copy before, depending on where the files fall.

As I've also said, we do have some ideas here, but -- unfortunately -- implementation of those ideas has been slower than I think all of us would like.

This is my first post.

I bought SuperDuper! last year and I use it every day to make reliable bootable backups (aka clones or duplicates).

Dave, you are a real gentleman in these fora. I enjoy reading them to pick up tips and insights. No matter what issue anyone brings up, you always respond with aplomb, diplomatically and fairly. You set an excellent example for customer service in any type of business.

_____________
Patrick Holaday

Thanks, Patrick!

He certainly does!

I'm in EXACTALLY the same situation
 

I too write music for film production. I am currently working on a film. The working disk is close to 500g and I have experienced THE EXACT SAME THING.

Routinely.

Major Bummer

Mr. Bummer: if you're experiencing this problem, I suggest that you try a larger destination and (as I said in response to your other note) try not to work while you're backing up.

Is this still the way SuperDuper operates? I stopped using it because of this since I routinely work on drives that are usually about 90% full, and a Smart Update blows up every time because of this (flawed) logic of "copy first". I've warned other people away from SD who are in my situation also because of this. Are there any plans to offer a Delete Before Copy option? Unfortunately, SD is useless for me without this choice. I'd love to use it if only the developers would make this simple fix. At the very least, copy one file, delete it, and move on to the next; don't copy all files first before deleting any.

We don't "copy first", nor do we "copy all files first before deleting any". We act on encounter in a single pass (as I explain in the Troubleshooting section of the User's Guide).

And, yes, we have some ideas for how to improve this, but they're not yet in the product.

To be clear: most users do not run with disks that are 90% full.

My main boot disk isn't 90% full, it's various working drives that I backup that are full. When you're working on data drives that have lots of audio, video or other media for a project, relatively full drives are common. And doing an Erase then Copy on multiple drives that are 1TB or more just isn't practical - it takes forever. Thanks for the quick response. I'll give it a try again, an hopefully you guys have time to implement some of your ideas in a future update.

The best way to avoid this particular error in that case is to help Smart Update a tad. If you rename/move a large folder of media data, etc, perform the same operation on the backup as well. That way, no data will need to be recopied...

Mostly oddball exceptions like me, a data hoarder on the cheap. :)

Important critical files should be backed up
 

I use several methods to backup my most critical files.
Super Duper! gives me a bootable backup with my important files.
I use an external drive with Super Duper!
As inexpensive as external drives are now, I use one for Time Machine also.
I make sure my external drives have extra room to be able to fully backup
my information.

One can never have too many backups or extra space.

-larco