PDA

View Full Version : SuperDuper not mounting disk images; copying to root volume


diamondsw
03-29-2010, 12:16 AM
This is going to sound truly strange, but yes, it did happen - twice.

My backups are done to disk images stored on a Time Capsule. When SuperDuper opens the backup script, it mounts the Time Capsule automatically to locate the image, and then mounts the image as part of running the backup script. This works 99% of the time.

A couple weeks ago I noticed some strange problems on one of my backups:
The backup image only had about half of the files it should - it just stopped halfway through the disk.
My root drive was missing about 50GB of space.
Running SuperDuper would faithfully examine all files, but the backup image remained the same.

What turned out to have happened is the first half of the files went to the backup image (we'll call the volume "BackupImage"). The remaining files were copied to the local hard drive at "/Volumes/BackupImage/". It's as if the backup image was unmounted halfway through and SuperDuper kept copying to the mount point. Like I said - strange. Finding that was tricky, as DaisyDisk, WhatSize, and others ignore /Volumes for obvious reasons, resulting in the Finder reporting one size and third party utilities reporting another. I finally found the files, cleaned up, and moved on - subsequent backups were fine.

Last night, one of my backups did this again, only this time all of the files went to the local drive, and I only had 10GB free to begin with. Did you know Mac OS X handles zero space free impressively well? :) Nothing crashed, just logs failed to be written and SD had an error on screen.

For last night's backup, I had just moved the backup image to a different location on the Time Capsule and updated the copy script to reflect that, but I didn't touch the scheduling thinking it would just pick up the changes by running the updated copy script. Perhaps this wasn't wise; I'm not sure.

Any ideas on this one? I don't know if there's any way to avoid this, especially if the volume disappears out from under SD, as it appeared to the first time.

dnanian
03-29-2010, 08:51 AM
Well, a copy script doesn't point to the destination location: if you moved the image, you'd need to update the schedule to update the destination pop-up.

There are definitely situations where OSX doesn't 'tell us' when a mount point fails, and it's converted from a mount point to a folder. Since, internally, it always 'looks' like a folder, we don't catch it.

We could re-'stat' ever file copied to make sure that its device is what it's supposed to be. This would slow copying down, not insignificantly. But it's something we're looking at, since while this is a rare situation, it's quite annoying...

diamondsw
03-29-2010, 11:55 AM
Well, a copy script doesn't point to the destination location: if you moved the image, you'd need to update the schedule to update the destination pop-up.

There are definitely situations where OSX doesn't 'tell us' when a mount point fails, and it's converted from a mount point to a folder. Since, internally, it always 'looks' like a folder, we don't catch it.

We could re-'stat' ever file copied to make sure that its device is what it's supposed to be. This would slow copying down, not insignificantly. But it's something we're looking at, since while this is a rare situation, it's quite annoying...

My apologies, bad terminology. I updated the backup settings document, not the copy script (those two always confuse me - but I also can't come up with anything better). I did not touch the schedule, thinking that all a schedule does is run a set of saved settings at a given time. I guess this is not the case.

Yes, checking the mountpoint (restating) for each file was about all I could come up with - and I knew that would be a performance no-no. Perhaps a middle ground - check it for every GB copied or at the end of a backup?

I figure there are two problems to address:

Early detection, to hopefully avoid filling the root partition unexpectedly, or even remount and continue
Cleanup, so if a problem occurs SD can delete the files off the root volume

Checking occasionally along the way might give some early warning without too much of a performance hit, but I imagine it would be difficult to gauge when to do so given massively different disk layouts (lots of small files, few large files, mixed, etc). Checking at the end of a backup might not be a bad idea though, as it would allow some cleanup to be done and alert the user (or retry the backup, depending on what makes sense).

Certainly this isn't something you should have to face - if OS X tells you a volume is mounted, it shouldn't just vanish mid-copy - but I know I'd appreciate it if you could. Now I know what to look for, but it can be very hard to track down the first time if happens.

dnanian
03-29-2010, 02:07 PM
An occasional check is something we're looking into. I'm hoping there are better ways, too. I have some ideas, but we'll see.