SuperDuper scripts in Mountain Lion

January 28th, 2013 at 9:25 pm by Dr. Drang

When I got my new iMac and began working with Mountain Lion for the first time, I found that one of the scripts I use in conjunction with my SuperDuper backups was generating an error and preventing my nightly backup from proceeding. I soon got things working again, and didn’t think any more of it until this tweet arrived yesterday.

@drdrang Using your SuperDuper (un)mount scripts - leancrew.com/all-this/2009/… - but getting dl.dropbox.com/u/1371905/Scre… - do they still work in ML?
— jfield (@jfield) Mon Jan 28 2013 12:06 AM CST

Those scripts are so old, I didn’t think anyone else used them. Let me explain how I got my backups working again.

First, you should understand that I prefer having my backup disk unmounted except when the backing up is in progress. This keeps the backup safe from my inadvertent drags, drops, and double-clicks. SuperDuper needs the disk mounted to do its job, so I wrote a short shell script, called mount_backup to be called just before SuperDuper starts its work. And I wrote a similar script, unmount_backup, to tuck the backup disk away when SuperDuper is done. These scripts are called by SuperDuper itself, as specified in the Advanced options:

When I first wrote these scripts, Apple’s diskutil command wasn’t as smart as it is now (or maybe it was and I just wasn’t smart enough to realize it), and I had to go through a few manipulations to get the right argument to give it. Now, both mount_backup

bash:
1:  #!/bin/bash
2:  
3:  # BDISK=`/usr/sbin/diskutil list | awk '$3=="Backup" {print $6}'`
4:  # /usr/sbin/diskutil mount $BDISK > /dev/null
5:  
6:  /usr/sbin/diskutil mount Backup > /dev/null

and unmount_backup

bash:
1:  #!/bin/bash
2:  
3:  # BDISK=`/usr/sbin/diskutil list | awk '$3=="Backup" {print $6}'`
4:  # /usr/sbin/diskutil unmount $BDISK > /dev/null
5:  
6:  /usr/sbin/diskutil unmount Backup > /dev/null

are much simpler. “Backup” is the clever name I’ve given to my backup disk. I’ve kept the old code in there, commented out, in case diskutil stops being able to accept the name of the backup disk and I have to specify something like disk1s1 again.

When I started using Mountain Lion, SuperDuper would fail with an error message saying that the backup disk wasn’t mounted. I could see that SuperDuper was running mount_backup and I knew from testing at the command line that mount_backup worked, so this was a puzzler. One thing I did notice, though, was that sometimes mount_backup took a very long time to finish. If SuperDuper was running it asynchronously—starting its own process before mount_backup was done—that might explain the failure and the error message.

So I decided to set up a LaunchAgent that runs mount_backup a few minutes before SuperDuper is scheduled. The plist file, called com.leancrew.mount_backup.plist, looks like this:

xml:
 1:  <?xml version="1.0" encoding="UTF-8"?>
 2:  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3:  <plist version="1.0">
 4:  <dict>
 5:    <key>Label</key>
 6:    <string>com.leancrew.mount_backup</string>
 7:    <key>ProgramArguments</key>
 8:    <array>
 9:      <string>/Users/drdrang/bin/mount_backup</string>
10:    </array>
11:    <key>StartCalendarInterval</key>
12:    <array>
13:      <dict>
14:        <key>Hour</key>
15:        <integer>21</integer>
16:        <key>Minute</key>
17:        <integer>25</integer>
18:        <key>Weekday</key>
19:        <integer>1</integer>
20:      </dict>
21:      <dict>
22:        <key>Hour</key>
23:        <integer>21</integer>
24:        <key>Minute</key>
25:        <integer>25</integer>
26:        <key>Weekday</key>
27:        <integer>2</integer>
28:      </dict>
29:      <dict>
30:        <key>Hour</key>
31:        <integer>21</integer>
32:        <key>Minute</key>
33:        <integer>25</integer>
34:        <key>Weekday</key>
35:        <integer>3</integer>
36:      </dict>
37:      <dict>
38:        <key>Hour</key>
39:        <integer>21</integer>
40:        <key>Minute</key>
41:        <integer>25</integer>
42:        <key>Weekday</key>
43:        <integer>4</integer>
44:      </dict>
45:      <dict>
46:        <key>Hour</key>
47:        <integer>21</integer>
48:        <key>Minute</key>
49:        <integer>25</integer>
50:        <key>Weekday</key>
51:        <integer>5</integer>
52:      </dict>
53:    </array>
54:  </dict>
55:  </plist>
56:  
57:  <!-- @@@@LingonWhatStart:/Users/drdrang/bin/mount_backup@@@@LingonWhatEnd -->

As you can probably make out if XML doesn’t make your head swim with all the angled brackets, this causes the mount_backup script to run Monday through Friday at 9:25 pm. That’s five minutes before SuperDuper is scheduled to do its thing.

I’d like to say I wrote that plist file from scratch, but of course I didn’t. I used Lingon to both make it and load it.

Unfortunately, Lingon doesn’t have options for scheduling scripts to run on Mondays through Fridays, so I started out by scheduling it for Monday only and then found the plist file in ~/Library/LaunchAgents and added the other <dict>s for Tuesday through Friday. And I’m pretty sure I had to add the <array> tags that wrap all the days together.

If you’re used to the crontab format for scheduling, the plist above will make you either laugh or cry. It’s incredibly verbose considering how little it does. But Apple wants us to use this instead of cron, and bucking Apple on things like this is never a good idea.

Scheduling mount_backup to run five minutes before SuperDuper did the trick. I haven’t seen any error messages since.

Tags: backup, mac, superduper
Post #2027 | 18 Comments

18 Responses to “SuperDuper scripts in Mountain Lion”

Tj Luoma says:
January 28th, 2013 at 11:31 pm

I always want my SuperDuper drive unmounted for the same reason. Spotlight always seems to find the wrong whatever when it’s attached.

I solved this problem a bit differently: I have a Keyboard Maestro script which mounts the drive and then launches SuperDuper, and then presses the appropriate buttons to start the clone. I have that scheduled to run via KM’s scheduler rather than using SD’s scheduler.

Also, instead of using SuperDuper to run a script after the clone is finished, I just have SD quit when it’s done. Then I have another KM macro which unmounts my SD drive whenever SD quits.

Just thought I’d throw that out there as another alternative, especially for people who don’t want to write plists :-)
Dr. Drang says:
January 28th, 2013 at 11:58 pm

Makes sense if you’re a Keyboard Maestro user. I still think using SuperDuper to mount and unmount its drive is the cleanest solution and wish I didn’t have to do this LaunchAgent stuff.
David Avraamides says:
January 29th, 2013 at 7:31 am

Thank you, good doctor, for figuring this out. I’ve also experienced intermittent SD failures due to my backup drive not being mounted and did not consider that it was a timing issue. My unsatisfactory workaround had been to disable the scripts and just leave the backup drive mounted all the time.

Now I can fix it properly.

One question: while you point out that Apple recommends launchd over cron, SuperDuper still schedules its backups using cron. Have you replaced those jobs with plist files, too?
Dr. Drang says:
January 29th, 2013 at 11:57 am

I didn’t know SuperDuper used cron, David, but as soon as I read your comment I did a
```
crontab -e
```
and sure enough, there was the entry for my 9:30 backups.

I hesitate to change what SuperDuper is doing; you never know what can break. I assume that if Apple officially deprecates cron—rather than just saying launchd is preferable—Dave Nanian at Shirt Pocket will do a SuperDuper update that switches to launchd. Until then, I’m leaving well enough along.
NaOH says:
January 29th, 2013 at 3:37 pm

I keep my backup drive connected but not mounted. With no special scripts or anything, just a scheduled backup in SuperDuper, the software handles mounting the volume and then ejects the volume when it auto-quits afterward. Which is to say, there doesn’t appear to be any need for scripts or Keyboard Maestro (I used to use it for this) mounting/unmounting volumes.
Dr. Drang says:
January 29th, 2013 at 9:22 pm

You’re the first person I’ve heard from who does it this way, Sodium. How do you specify the backup disk to SuperDuper? I do it by name, and if a disk of that name isn’t mounted, SD stops and puts up an error message.
Matthew McVickar says:
January 30th, 2013 at 1:45 am

I’ve been meaning to set up something like this for months; I’m glad it resurfaced on your blog. My needs are slightly different, though. I have a single laptop that I work on from home and then bring with me if I’m working remotely or have a gig, so my external hard drives are not always plugged in and ready to be mounted and unmounted via diskutil. I plug the USB hub with my two backup drives on it when I come home, and run an Applescript with a keyboard shortcut to unmount them before unplugging it. This means I have to unmount the drives once their hub has been plugged in so they can later be mounted.

I haven’t come up with a way to automate this, so at the moment I’ve set up another keyboard shortcut (⌘⌥⌃U) to run the unmount_backup shell script and try to remember to run it when I plug in the drives. (Lingon has a ‘run whenever a drive’ is mounted, but that is logically flawed: it would unmount the backup drive every time it were mounted, even at the time I actually want it to be mounted.)
Michael says:
January 30th, 2013 at 1:58 pm

Is there a specific reason why you do not use SD’s option “On successful completion: Eject [Backupdisk]”? Otherwise, what NaOH said is very interesting.
Dr. Drang says:
January 30th, 2013 at 3:38 pm

All the reasons for the choices I made are lost in the mists of time, Michael, but I think the reason I didn’t choose Eject Backup is because I very much wanted SuperDuper to quit, and I wasn’t sure it would if Eject Backup were the choice. Does it quit after ejecting?
Matthew McVickar says:
January 31st, 2013 at 6:39 pm

SuperDuper does not quit when the ‘Eject [Volume]’ option is selected. In the progress window, it says ‘Eject [Volume] when SuperDuper! quits’, but that doesn’t mean it will quit when it’s finished. It will sit there, finished, and when the user quits SuperDuper, it ejects the volume.

I also can confirm that SuperDuper will mount a connected but unmounted volume.

My workflow is now to simply plug in my external hard drives and then eject the newly connected backup volumes with a keystroke. I have SuperDuper set up to eject the backup drive when the copy is finished, and also to run a shell script to quit itself upon completion:
```
#!/bin/sh  

osascript <<EOF  
  tell application "SuperDuper"  
    quit  
  end tell  
EOF
```
Matthew McVickar says:
January 31st, 2013 at 6:48 pm

So, since SuperDuper can handle mounting and unmounting of connected volumes itself, there should just be a new option: ‘Eject [Volume] and Quit SuperDuper!’ I have put in a support request asking for as much.

[Edit to the script above: It should be "SuperDuper!", not "SuperDuper".]
Dr. Drang says:
January 31st, 2013 at 6:51 pm

Thanks, Matthew. I turned off the mounting/unmounting scripts today to see what will happen to my nightly backup. Presumably, the backup will go ahead.

What bothers me the most about this is that I know I’ve gotten error messages from SuperDuper when the backup drive was connected but not mounted. Is it possible SD used to behave that way but that an update made it smarter? I guess I should email Dave Nanian and ask.
John says:
January 31st, 2013 at 7:23 pm

Dr. Drang: SuperDuper added the ability to mount a drive as required for a scheduled copy in Version 2.1.1(78) of May 17, 2006. But, any scheduled copies had to be deleted and re-created for this new functionality to take effect.
John says:
January 31st, 2013 at 7:32 pm

Matthew McVickar: It is currently possible to get SuperDuper to eject the destination volume and then quit by including the commands in a shell script to be run from the Advanced Option “Run shell script after copy completes”. This will however only run after a successful copy.
Matthew McVickar says:
January 31st, 2013 at 9:16 pm

OK, based on the advice above and my own testing, this is how I have things set up and running smoothly:
- As explained before, unmount backup volume with a key combination when it is plugged in for the first time (when my laptop has been away from my desk). I leave the drive unmounted—but physically connected to my computer—and SuperDuper! mounts it when it needs it.
- Backup script set up in SuperDuper! with standard settings, except for a shell script that runs at the end (screenshot) called eject_backup_and_quit_superduper:
```
#!/bin/sh
/usr/sbin/diskutil unmount 'Backup' > /dev/null
osascript -e 'tell application "SuperDuper!.app" to quit'
```
- I also have the General settings set to ‘Do Nothing’ under the ‘On successful completion’ heading. Since the end-of-copy shell script is handling both unmounting the drive and quitting SuperDuper!, I don’t need SuperDuper! to do anything more.
Took some trial and error, but I have this working successfully several times in a row when being run manually. I expect it to go smoothly tonight as well, but will report back if it doesn’t.
Dr. Drang says:
January 31st, 2013 at 9:36 pm

Thanks for the info, John. As it happens, my scheduled backup just started running. I’m looking at my office computer through Screen Sharing, and the dreaded “SuperDuper! cannot find target volume” error message is up. I would swear that I’ve deleted and recreated that scheduled task at least once since 2006, but maybe not. I’ll delete it now and see what happens.

Later
Nope. I deleted the scheduled task and made another one. Still got the “cannot find target” error. Then I deleted SuperDuper itself, and its Preferences plist and its folder in Application Support, and reinstalled it from scratch. Still got the “cannot find target” error. Why does SuperDuper hate me?
Dr. Drang says:
February 1st, 2013 at 7:44 pm

Via Twitter, Matthew McVickar has told me that SuperDuper’s automatic mounting for scheduled backups doesn’t work in Mountain Lion. That’s mentioned in this old post on the Shirt Pocket blog, and he’s gotten confirmation from Dave Nanian that that hasn’t been fixed yet.

So in summary:
- If you’re running Lion or earlier, there’s a good chance that a connected but unmounted backup disk will get mounted by SuperDuper just before copying. My mount_backup script won’t be necessary.
- If you’re running Mountain Lion, a connected but unmounted backup disk will not get mounted by the current version of SuperDuper (2.7.1), and you will need a script like mount_backup.
I suppose if I’d bothered to find out that Shirt Pocket had a blog, I would’ve known all this a while ago.
Des Dougan says:
February 11th, 2013 at 11:30 am

Thanks for posting this - I’ve the same issue on ML, so have taken your plist and customized it for my own requirement. I also duplicated it to unmount 3 hours later, as I also prefer having SuperSuper! quit on completion. It will run overnight - I’ll post if there were any further issues.