A strategy for managing SD! jobs via AppleScript
My strategy for managing SD! jobs via AppleScript is this:
First, schedule each desired SD! job from within SD!, with any schedule that won't execute in the near future. This creates a settings package in the folder Library/Application Support/SuperDuper!/Scheduled Copies/, with a name such as Smart Update aOSX from OSX.sdsp. Move these settings packages to your own folder; this allows them to run independently of SD!'s built-in scheduling feature, as I noticed by reading their AppleScript code. Now go back in SD! and delete these scheduled jobs. The settings packages will survive intact; for the moment, SD! has no idea where they went. Each of these settings packages contains a compiled AppleScript called Copy Job. One can Show Package Contents and then manually launch Copy Job, to run the corresponding SD! job. The log files for these jobs are also stored in these settings packages. Alternatively, one can call these Copy Job scripts from within AppleScript. The calling script can then be run manually, or scheduled using cron or a GUI for cron such as CronniX. I describe below how I resolved the issues that arose for me in writing and testing such a script. For a variety of reasons, I don't want my backup hard drives mounted when I'm not backing up to them. I also rotate hard drives as backup media, and I want a script to gracefully notice when media is unavailable, and move on. So I mount each volume as needed from within AppleScript, and eject it afterwards. I found that I needed to eject volumes by telling the Finder, but this has the effect of ejecting all volumes on a given physical hard drive. This affects both one's strategy in partitioning one's drives, and one's code: One needs to avoid timing issues where ejecting the last volume used could also eject the next volume needed. Along the same lines, all available volumes are mounted whenever a user logs in, so it is necessary to write another AppleScript (not shown, but similar) to eject unwanted volumes on login. My AppleScript mount routine is written to be as robust as possible for my purposes, rather than to be as concise as possible: Some code fragments that I found for mounting partitions were vulnerable to volume name issues. The egrep pattern matches an entire line of the diskutil list output, and sed removes the volume name, so awk can find the disk locator in a consistent column. This allows for volume names with embedded spaces, and volume names that contain one another. Still, it is poor form to have two identical volume names available, and this code will behave unpredictably in that event. I also want to return the status of mount attempts as quickly as possible. mount executes two shell scripts, rather than combining these into one, in order to detect immediately if a volume name isn't even listed in the diskutil list output. Presumably, this is rotating backup media that is intentionally unavailable. If SD! is open, my script waits for SD! to quit. Similarly, it waits for SD! to quit before proceeding to subsequent copy jobs. This code is based on the source code for the SD! Copy Job scripts. Each top level copyJob call takes two arguments, the name of the destination volume, and a full AppleScript alias for the SD! Copy Job script to run. AppleScript aliases need to exist at compile time, but they have the advantage of automatically updating themselves when files are moved. The relative unreadability of this argument is a small price to pay for the convenience and feedback one gains. Links to related threads: Mounting an external volume before backup An (Applescript) hack to automate mounting and unmounting external volumes Here is my complete AppleScript for managing SD! jobs: Note: I have revised this code at least once. I am preserving the sequence of posted versions in this thread, so that the discussion makes sense. However, I recommend modifying the latest version to your needs, after you understand the code. Code:
on mount(diskname) |
Thanks, Syzygies! Hopefully this'll give people even more ideas for what they can do with the SuperDuper! AppleScript interface and built-in Copy Job script...
|
Revised code
Here is a revised version of my code to selectively mount and unmount volumes, and call SD! scripts unattended. I've sorted out various issues, and it now works fine as a cron job; I rely on it nightly.
Overall, the code has been improved by never telling anything to the Finder. 'unmount' now only unmounts the given volume, without ejecting other volumes on the same disk. It is possible to have an AppleScript such as this that calls 'diskutil' crash on rare occasions. I don't know why, and I'm not sure that I'm actually doing anything wrong. (SD! itself sometimes uses 'disktool' instead of 'diskutil', despite Apple's efforts to wean us from it; perhaps Dave can explain why?) Also on rare occasions, I'd run a prior version of this script unattended, and one of the volumes failed to unmount. I considered what I would have done manually had I been there, and wrote a wrapper 'unmountVol' to do exactly that. It looks like massive overkill in the calm light of day, but its precautions are entirely harmless for unattended operations. I leave diagnostic journaling on at all times, as SD! does. If anything odd happens, this is invaluable. Note that all shell script commands are logged, together with any errors returned, even for commands that always return an error. (We wouldn't want to miss it, if one of them returned a different error.) All forums have a high percentage of lurkers. I google and lurk various places to pick up code fragments to try, and I consider this to be the primary value of posting code on the web; I don't like to use unsupported code that I haven't rewritten myself. To be conservative, if no one else has posted here that this code worked for them, proceed with caution in modifying it for your needs. This is an AppleScript library file, Backups Library.scpt. Opening it opens the script in the Script Editor: Code:
property logfile : "/Volumes/User/Users/ad/Scripts/logs/log" Code:
set BackupsLib to (load script file "User:Users:ad:Scripts:Backups Library.scpt") Code:
unmountVol aBack |
|
Any particular reason for the graphical sig, Dave? Tracking?
|
Sure, most forums are 99% lurkers, and the code took a bit of work, just curious. I see how many people read my post, and they can study source to figure out who I am.
Here's a simple Perl script that can extract this kind of information from my apache server. No idea how portable the code is, but it works for me: Code:
#!/usr/bin/perl |
Just not entirely necessary -- the view count for the thread is right in the index. This thread, for example, has been viewed 147 times or so...
|
Yeah, but I can't remember that. I wrote the script for tracking my own web pages, but it tells me date information here. If accesses fall off to zero, I know no one is using search, and I can bump the thread or forget about the project.
|
Fair enough, Dave... just wanted to point out the existing feature.
|
Using Your Code
Thank you for your source code contribution, Dave.
I want you to know that I'm reading your code to improve a similar script I wrote to mount the target disk before and unmount it after creating a bootable copy. My previous script used another clone-making product, but I decided to try SD instead because of its slicker AppleScript interface. And this forum! What a trove! --Gil |
Working so far...
A few hiccups with aliases, etc. but I'm watching SuperDuper! running as I type. Hopefully this will become my primary solution, scheduled with Cronnix.
For the record, I really think this should be a standard part of SuperDuper!, or at least a Shirt-Pocket supplied and tested "advanced solution" hidden in there somewhere... I'm reasonably confident in my ability to make things like this work, but would prefer not to have to! Ben |
I'm confused, Ben. Scheduling in v2.0 is built right in -- there's no need to use CronniX.
|
Scheduling, yes, but mount/unmount...?
I know scheduling is a feature, but this entire thread is devoted to arranging a scheduled mount/unmount feature.
I bought SuperDuper! to provide an instant-recovery clone on the second internal drive on my G5 – sometimes I can't afford any downtime, and a recent hard drive failure caused me major problems, in spite of my effective data backups on external drives. But the doubled apps under Open With... and the possibility of mistakenly accessing data on the clone make a mount/unmount feature a practical neccessity for me. Like I said, I still run regular backups (been using Deja Vu happily for years), but I want SuperDuper! to provide me with a 3AM "mount the drive, do the backup and unmount the clone" routine. I want the clone to exist, but I don't want to see it until I need to... Ben |
Given one of the solutions on the Forum, you can certainly do that, without CronniX. Just modify the scheduling AppleScript to mount the volume before the backup, and unmount it after. Those run before SD itself runs, and should give you the solution you're looking for.
|
I appreciate that, and thanks for the replies.
I think you should seriously consider writing up a suggested method, perhaps even a sample script, even if you don't explicitly support it ("advanced users only - use at own risk" type of thing) to save people grubbing around for the best way. I, for one, would be extremely grateful. I'd like to change SD!s default behaviour as little as possible, and when it comes to adding elements into the AppleScripts, I'm never certain exactly where and what is best. Thanks again, Ben |
All times are GMT -4. The time now is 11:20 PM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.