I run a clone of both my HDs to a FW drive every morning at 3am, using SuperDuper. I also have various QRecall schedules to archive critical folders, and one of these is set to run at 4am so as not to compete with the SD backup.

I can set one system wake using the Energy Saver prefpane, but to set two I would have to use something like Power Manager.

It would be neater if I could let QRecall off once SuperDuper had finished, but I am not sure how to achieve this. SD can be set up to fire a script on completion, but I can see no obvious way to make a script initiate a QR action, especially since QR itself is not scriptable. I was wondering whether I could script something to create a condition that QR would recognise and respond to. The only thing I can think of is to have SD's closing script unmount and remount the archive drive, but this seems a bit clumsy. A condition: hold if [xxx.app] running would do it too, but of course there is no such condition.

Does anyone have any better ideas?

Nicholas Sloan wrote:It would be neater if I could let QRecall off once SuperDuper had finished, but I am not sure how to achieve this. SD can be set up to fire a script on completion, but I can see no obvious way to make a script initiate a QR action, especially since QR itself is not scriptable. I was wondering whether I could script something to create a condition that QR would recognise and respond to. The only thing I can think of is to have SD's closing script unmount and remount the archive drive, but this seems a bit clumsy. A condition: hold if [xxx.app] running would do it too, but of course there is no such condition.

Nicholas,

Thanks for the feedback.

I'm planning a number of new QRecall features, one of which is more scriptability. I also have plans for a "Perform action when application X starts/stops" action schedule, but that's intended more for applications like Aperture and Parallels where their content can't/shouldn't be captured while the application s running.

I currently have plans to add AppleScript support to the QRecall application, create a QRecall Automator action, and include a command-line version of QRecall. I think either the Automator action or a command-line QRecall tool would solve your problem.

Right now these were all planned for version 1.3. Version 1.2 is going to concentrate on new capture features, performance, and a completely redesigned user interface. Version 1.3 is going to focus on automation, scripting, and filtering.

Thanks very much James.
I look forward to the "completely redesigned user interface" with mingled excitement and apprehension, only because I have got to know and like the current interface so much. But I guess that if you got it right once, you'll probably get it even righter the next time.

I'm trying to keep the good stuff and add more good stuff.

Specifically, a column view and better ways of navigating between volumes and users. I want to keep the timelines, but introduce a much richer interface for exploring the history of individual items.

If there's anything that you (or anyone) really like, or hate, about the current interface please chime in now.

Sorry not yet to have given you a considered reply to your last post James (working on it), but I had another question stemming from the problem that inspired this thread.

I was assuming that it would be a bad thing to run QRecall captures and SuperDuper clonings concurrently, but I see from my QRT logs that this is what has in fact been happening some of the time, with no apparent ill effects.

Would you consider it bad practice to do this? In some cases SD is cloning the same drive from which QR is capturing parts, in some cases a different drive; in all cases they are writing to different drives.

It would simplify things (and save a little energy) if I could throw all my backup tasks into the same time slot.

Thanks.

Nicholas Sloan wrote:I was assuming that it would be a bad thing to run QRecall captures and SuperDuper clonings concurrently, ...

Not at all, that sounds perfectly harmless. Any number of processes can read the same files/folders simultaniously. It doesn't affect anything. Problems can occur when something is writing to the files being copied/captured, but that's not the case here.

It would simplify things (and save a little energy) if I could throw all my backup tasks into the same time slot.

Having two programs copy the same source items simultaneously can cause a phenomenon called "thrashing" where the disk heads spend a lot of time jumping around the volume trying to satisfy the requests of both processes. The result is that trying to do two things at once actually ends up taking more time than if you did them one at a time. But that's speculation; you'd actually have to observe your system to determine if running both at the same time is faster or slower than running them sequentially.

Thanks very much again for your prompt and pertinent response James.

Time is not critical with dead-of-night backups, but data integrity is. Provided that I am in no way compromising the latter, I will continue to run them in tandem.

I'd love to see the Applescript support. I have a folder that I'd like to have captured whenever an item is added to it. Being able to script a folder action for this would be ideal!

Thanks,

Steve