View Full Version : Is SD2 less aggressive in mounting last BU Vol

12-21-2005, 02:22 PM
I thought I had a working system with applescript for a rotating offsite backup, but it seems that the problems with SD attempting to mount the last connected volume persist.

What I'd like is to name 3 different FW drives "backup" and have SD treat them all equally, smart updating each. We rotate two of these offsite (one in a secure place, one in transit). SD 1.5 was using something more than just the volume name, and threw up a dialog that would screw the automated script.

I thought I had gotten around this by naming the volumes backup1/backup2/backup3 and creating a different settings file for each. My backup script then looks to see which volume is mounted, and then launches SD with the appropriate settings. In my first tests this seemed to work, but now SD continues to try and connect to an old volume as soon as it launches.

The scheduler in SD2 is nice, but given that we rotate these drives in a rough weekly schedule, and there are three drives, there is no way for it to work for us, so I'll be sticking with Cron/Applescript which I'm fine with.

If SD2 still uses more than the volume name, how can I get it to stop trying to look for the old volume. I remember finding a thread here about the particular entry in the plist, which I think I can now nuke with applescript - looks like its SDSessionSettings.

If SD2 is unchanged in this behavior, can I assume that that same entry in the plist is the one thats causing the problem?


12-21-2005, 02:39 PM
We're still using the UUID to manage this, but here's a solution for you. NOTE: please, this is only for advanced users. Normal users shouldn't be doing this, so -- if you're a regular user, don't, OK?

For the advanced, though:

We have a little program called SDDiskTool that's inside the SuperDuper bundle you can use to do this. It's in SuperDuper!.app/Contents/MacOS/SDDiskTool. You'd use:

SDDiskTool -g /Volumes/some-disk-name

to get the UUID. Then, to set it, you'd use:

SDDiskTool -s the-UUID /Volume/some-other-disk-name

So, pick the one you want to be the original, and set all the other UUIDs to be the same. At that point, we're going see any of them as the same drive...

Hope that helps!

12-21-2005, 05:25 PM
Dave, Thanks - this looks like a good solution, as I can now use SD2's scheduler, set to nightly :)

Does the scheduler use launchd? If so where are you storing the launchagent? Otherwise I didn't see a background helper process that SD runs, which I'm very glad to see as there is no reason to do things that way anymore.

Is this a system UUID thats being used, or just one that SD generates? I can't imagine any gotchas doing this, other than maybe the startupdisk setting if two disks with the same UUID were mounted (not gonna happen in this scenario).

The only thing this new approach doesn't have that my scripted one had, is that if there was any error, the system sent me a warning email.

Where does SD store its log? Maybe I'll just read the last entry of that and if it was not "OK" send the warning.

I'm still prechecking that the backupvolume is mounted with the old applescript (just with the SD bit commented out). I should do this with the SD preflight builtin option - does SD make any decisions about whether to perform the backup based on what the script returns?

Wow - that is more questions than I originally thought I had. Thanks for the great support and thanks for making the product easy to use for anyone, but flexible for us out there managing os x server systems. We are using it to backup for our school server with hundreds of user folders - a godsend.


12-21-2005, 05:28 PM
The scheduler uses cron, not launchd (which isn't available on Panther, and is still a little new for us to rely on). The UUID is the system's UUID.

You can modify the script inside the scheduled copied entry (open the package) and change it to do what you want. The log itself is in there, too... and you can use a preflight there, too.

Hope that helps, Preston -- let me know.

12-23-2005, 01:33 PM

The schedule didn't run last night, and looking around I don't see any entry in any of the crontabs at /var/cron/tabs

Does it use the users tab, or the systems? Could be a permissions issue?

Also for anyone who stumble's on this thread down the road, make sure you use sudo for setting the UUID with SDDiskTool


12-23-2005, 01:34 PM
It users the user's tab. Use "crontab -l".

If the crontab wasn't run because you weren't logged in or were in the BG of a FUS session, then you wouldn't even see an attempt.

12-23-2005, 04:16 PM
If the crontab wasn't run because you weren't logged in or were in the BG of a FUS session, then you wouldn't even see an attempt.Maybe just a small clarification for the curious: crontab jobs are run when 'in the BG of a FUS session', but only non-GUI jobs will be able to execute successfully. As SD! needs the GUI it will only run if the user is logged in and in the foreground. (Don't you love all those acronyms? :))

12-23-2005, 04:19 PM
Fair enough -- though I thought we had checked this and found that the tasks (in the user's crontab) weren't run. I should re-test it again... but either way, it won't work if not the FG user.

12-23-2005, 04:42 PM
OK, the schedule didn't write because I had the crontab open in cronnix - thats fixed.

It looks like if the target volume isn't mounted, your the error is generated in the SuperDuper log, but no error is triggered in in the applescript (and so the nice little error stub you put in is not called). I need this because I have to make sure that the people who are rotating the drives are getting them plugged back in correctly.

So I'm going back to my own applescript called by cron (since I use these tools all the time anyway, if I have to go back in 6 months to change something, I'll figure out my way of doing it faster than remembering to open up your package, but bravo on the layout).


12-23-2005, 04:47 PM
Is the "after" trigger called, Preston? There's a pending issue with the "volume not present" error where the intention was to leave SD open, but I think it's both open and never tells the calling script that it's done... which is why the onError isn't called...