SD! can't automount unmounted internal disk(s) after system software update(s)

[Michael@wengam]

With yesterday's upgrade to OSX 10.6.7, a daily scheduled run of SuperDuper! failed this morning because the program did not successfully mount the internal backup disk (the disk is normally unmounted to conserve energy etc).

I know this because, when the backup disk is not mounted, SD! creates a folder named the same as the backup disk, within the folder /Volumes/ on the boot drive, and then proceeds to copy the whole of my startup disk into it. Sometimes I only discover this when SD! runs out of space on the startup disk.

This seems to happen every time that Apple upgrades the system software, for example from 10.6.6 to 10.6.7

The cure is fairly simple: I delete all my scheduled backups and then recreate them.

My question is: is there something that can be done in SD! to avoid recreating schedules every time there is a system software upgrade?

[dnanian]

I don't think that has anything to do with it. If a drive fails while we're copying to it, some system calls will convert its mount point to a folder. The drive *did* mount, otherwise SuperDuper! wouldn't find it at all when it tried to run the schedule and wouldn't even start.

What really happened is that, during the copy, the drive ejected itself. Why that happened is hard to say, but it could be a flaky drive, bad cables, compatibility issues with OSX, etc.

Recreating the schedule would have no effect on this at all (if you *didn't* recreate the schedule it would work if the drive was reliable, etc).

[Michael@wengam]

I don't know the detail of what happens, my daily backup runs at 7:00 AM and I do not witness it.

But the backup drive(s) have not generally given problems inbetween system software updates, and the correlation between the updates and this problem is strong enough that I recall thinking yesterday: "I wonder if the upgrade to 10.6.7 will result in SD! backing up to an 'ordinary' folder in '/Volumes/' tomorrow morning".

I was not at all surprised to see that that did indeed happen, and my solution -- of recreating the schedule -- fixed it as it has after previous incremental system updates.

My backup scheme is a single startup drive in my MacPro that backs up by schedule to daily, weekly and monthly internal disks, not normally mounted. On previous system upgrades, I have recreated only the daily schedule, only to find that the next weekly or monthly upgrade fails the same way, and then I have to recreate that schedule. I am not sure how likely it is that these relatively unused drives are all failing at the same time.

[dnanian]

It's more likely that the software upgrade caused problems with the drive communication, Michael.

[Michael@wengam]

Oh yes, I was assuming that, and did not mean to point the finger at SD!

Nevertheless, it would be nice if SD! could work around this