Is SD! corrupting my data ?

[barrysharp]

This is a FYI for SD! users.

I've been using SD! to backup my /Users Volume. This was done by first Cloning my /Users volume and then periodically using the Smart update.

Recently I purchased Drive Genius 2 and decided I would defrag the /Users cloned volume. It failed quickly saying the file system was corrupted with severe overlapping extents. I then used the Drive Genius 2's facility for repairing the /Users clone volume and it failed. I then used Disk Utility to repair and it failed.

I've used the /Users cloned volume at times and the system had not reported problems to me.

I'm now thinking that either SD! has been doing bad things during its Smart Update or somehow my running system has somehow corrupted the /Users cloned Volume when being used of when simply mounted in read/write mode.

I'm now in the process of deciding if to continue using SD! for cloning and Smart Updating my /Users clone volume or to use the Drive Genius 2 to replicate my /Users to a backup volume, or to use some completely different process or Application.

This is just a heads up and will also say this may in fact be a problem unique to me and my system.

It seems to me that for any SD! operations the disks/volumes must either be unmounted on a running system of be done in single user mode.

I've been cloning my boot volume regularly while running on my boot volume - this now doesn't sound like a 'good practice'.

I can say the same thing for initial Cloning and Smart Updating the clone of my /Users Volume.

I notice that Drive Genius 2 refuses to do any of the above type SD! operations unless the system is booted from its special Leopard boot disc. This ensures all disks/volumes are unmounted and not in use.

[dnanian]

Barry, SuperDuper! does nothing of the sort. We cannot cause overlapping extents, because we don't deal with extents at all. We simply ask high level functions to copy files. Extents are "allocated" parts of the file system, handled entirely by the file system itself.

The problem here is either that the OS failed, something you ran against the volume at a low level (e.g. DriveGenius) corrupted the low-level structures, you crashed, powered down improperly, ejected improperly, or that Leopard's own file system has a bug.

[barrysharp]

Dave: Thanks much for responding to my issue. Seriously, your words give me comfort.

I do have a followup for you though. When cloning or even doing a smart update of a 'live' volume to another mounted not in use volume isn't there some danger or risk that the source volume has ongoing i/o. This ongoing i/o may cause SD! some grief maybe. For example, say a very large download is taking place to the source volume while SD! clone or smart update is in progress - does this cause an issue for SD! ?

From my knothole I would think this type activity be done when there's a guarantee there's no activity being done to the source volume.

[dnanian]

A large download can cause problems, yes, but not this kind of thing. (We tell you, in the documentation, to try to quit most programs.)

Basically, files being actively updated might look larger than they actually are, and cause a destination drive to fill. But it won't cause overlapping extents: that kind of thing is at a much, much lower level than a 'file'.

[barrysharp]

Again Dave - thanks.

I agree about the "overlapping extents" issue not being a SD! cause.

It sure would be nice (if there were just a few overlapping extents) for Disk Utility and even Drive Genius 2 to identify the files having the overlapping disk allocations. This might help with recovery although a difficult one for user to figure out. If a directory is involved recovery will be quite hairy to say the least.

Thanks for your inputs.

I will be doing more frequent file system verifies from now on.

[dnanian]

Especially if you have anything unusual happen, Barry -- power offs, crashes, forced restarts, bad unplugs... those are the kinds of things that cause issues.