View Full Version : Script on fail?

11-27-2008, 08:34 PM

Just a bit of background: I'm not a user of SuperDuper personally, but I hear very good things about it.

I'm currently doing some freelance work for a client who runs a company which provides IT support for home users of Macs and PCs. Imagine a company's IT department, except that instead of looking after the machines of the employees of a company it looks after individuals' home machines.

The company provides several services for these home users, one of which is making sure that they have back-ups whether they realise it or not. For Mac users they install a NAS (or other external drive) for storage and install SuperDuper! to do the backing-up of the main drives.

At the moment my job for this company is to develop a web-based application for the head-office which will allow the company to monitor the status of each of their clients' back-up systems. i.e. at a glance the company can see if any of their clients automated back-up systems has failed or, for what ever reason, stopped the automated back-up routine.

I've decided to achieve this by getting the clients' back-up systems to email the server whenever backups occur (or fail to occur.)

On Windows systems this seems to work well - the client machines can send emails that report success or failure.

However.... With SuperDuper! there doesn't appear to be an option to script the failure scenario. I see that there are options to run scripts before back-up and on success - but upon failure there doesn't appear to be any way of getting information out.

I've searched this forum - and the general solution appears to be 'use the Mail Me plug-in from Growl.' Alas this isn't really an option for me. I love Growl - in fact I've been one of the developers on it (in a small way.) But this is not an option in this case. I cannot suggest to my client that he installs Growl on all his Mac-using clients' machines. For a start Growl assumes that you want Growl notifications shown by default, so any application that the client installs may start showing Growl notifications without warning (not good.)

I noticed that SuperDuper! is able to perform actions on failure (since the app Growls on failure) - so I had a look at the AppleScript code inside the SuperDuper! app bundle which is in charge of the scheduled backup system and thought about modifying that to send emails directly. Alas, this is not a suitable solution either - since I would have to provide a modified version of SuperDuper! to my client to distribute to his clients and every time the app was updated I would have to modify the app bundle again - and this modified app would have to be propagated to all the companies clients every update.

So - In rather a long winded way - I am asking - is there any hope that in a future version we might see an option in SuperDuper! where it can run a script on failure?

Or failing that has anyone got any clever ideas to solve my problem (getting SuperDuper! to send an email on failure without Growl.)



11-27-2008, 10:33 PM
It's not something that's likely to happen in the short term, Diggory... I can't think of anything clever to do, except to use Growl, which -- in your case -- you indicate is not acceptable. Sorry!

11-27-2008, 10:46 PM
OK. Thanks for replying.

I suppose I'll have to come up with some sort of crufty duct-tape hack :)

11-28-2008, 12:51 AM
has anyone got any clever ideas to solve my problem (getting SuperDuper! to send an email on failure without Growl.)

It seems to me that a really robust backup status notification system (more "enterprise-grade", since it seems your client might be leaning that way) would need to be independent of any facility provided by SuperDuper! (all this applies to any centrally monitored backup regime (i.e. also whatever is being used on the Windows machines)). Even if SuperDuper! could generate failure notifications, there are situations where it might be prevented from running on schedule (like something/someone doing something like crontab -r) or from running at all (installation is damaged or deleted). In that light, the most reliable way to detect failure really does seem to be to check for the absence of a success notification.

A second best approach would be some independently scheduled check that makes sure a recent successful backup was made. Since SuperDuper! uses crontab, independent scheduling might be achieved via launchd or the equivalent of a "on idle" handler with a 24 hour period in a "stay open" AppleScript app bundle (though this needs some kind of "guard" to make sure that it is restarted if it crashes). One idea is to use SuperDuper!'s script mechanism to touch a file in /tmp (or other appropriate location) on the backup volume after a successful backup. The checking process would be something like this: 1) Find the time stamp files for all the backup volumes, 2) Check that the youngest one is less than 24 hours old (or a week old, or whatever works for the backup schedule), 3) Send a notification based on the result (youngest is too old -> failure, youngest is not too old -> success).

Even with such an independently scheduled backup status check you still need to check for the absence of timely notifications on the upstream end. This is because a lack of failure notifications does not mean that backups have been successful (it could mean the notification system is not functioning properly). Likewise, a lack of success message does not imply failed backups. Even if the success notifications were generated more directly by SuperDuper! they could still go missing on the way to the central monitoring station. To my thinking, all this means that getting failure notifications does not really buy you anything over just checking for the lack of success notifications (since you still need to check for a lack of recent of notifications). If the scheduling of the backup status check was done via some mechanism that was completely isolated from the end user's machines (Apple Remote Desktop from a central server?), you might be able to get away without checking for timely notifications by just relying on the fact that you would notice if the central scheduler was not functioning.