Backup on Connect?

[gobo]

Hi,

Not sure if it's useful to talk about a feature that I haven't even seen yet, but I am very curious to learn how you handle it.

How does the Automatic Backup on Connect feature work?
More precisely: how do you prevent it starting a backup when you're actually connecting your drive to restore something?

[dnanian]

Just cancel the automatic run when presented.

[gobo]

Just cancel the automatic run when presented.

If it auto-starts, isn't there some chance that the data you want gets overwritten while you're trying to cancel? Or even worse, screw up your backup image?

I can understand why it is convenient to have automatic run. But you do have to realise the risk you're taking at that point.

[dnanian]

There's only so much I can do about that kind of thing, though. There's a delay, you can turn if off before you attach, etc...

[GM80]

One could also shutdown and boot from the backup, recovering whatever they need in that way. I presume it won't attempt to backup onto itself in that scenario?

I just wanted to say a personal thank you for the Backup On Connect and Eject When Finished features, Dave. I'm big on automation and have been running a preference pane (DoSomethingWhen) alongside SuperDuper! for this sole purpose. Who knows whether it will work with Snow Leopard, so I'm glad to leave it behind in favor of your built-in solution. Thanks!

[dnanian]

Let me know what you think of it when you get it.

[maine]

This feature seeems awfully "dangerous" to me. I understand the convenience aspect, but the cost seems awfully high. It just makes it way too easy to accidentally wipe out your backup just when you most need it. Get briefly distracted or any number of things and poof.

User errors have a high likelihood of comming in bunches, perhaps because the user is tired, or perhaps because he is stressed from the first error, or whatever. It just happens a lot; I've seen it (and done it :-()) myself for other backup recovery scenarios with other software. The fingers got so trained to the usual backup command that they did it pretty much on their own when the backup tape was mounted to do a restore. Ouch. The unix tar command is horrible in that regard when used for backups (as has been done); one letter diference between the commands to restore from a backup versus make a backup (destroying the existing one).

I'm not sure what to suggest, particularly now after it is released (I wasn't watching here and didn't notice beforehand). I'd just like to add the caution that, for whatever reason, user error frequency is quite high when recovering from backups (any kind - not specific to SuperDuper), and I think one should be very sensitive to the possibility and to minimizing its likely damage.

I hope that at least there is an option to turn off this feature. Haven't downloaded 2.6 yet to look. I'm guessing that there is. If there isn't such an option, could you pretty-please add one (and maybe it ought to warn about the dangers that come with the convenience).

[dnanian]

So, don't turn it on! It's not on by default, nor is any scheduling. It's an option. Use as required. :)

[maine]

Ah, good. Thank you.

[matts]

I haven't had the possibility to use this feature yet, but it sounds very promising.

Since I wasn't able to find anything about it in the user guide (am I blind?), I have to ask around: are we exclusivly talking about physical connection, or can mounting a network volume also trigger a backup? (I hope so.)

-matts

[dnanian]

It's in the FAQ, actually (see Help > Frequently Asked Questions). It happens on mount, but not network mount, because you can't back up directly to a network drive.

[matts]

Ok.

But... I might very well be wrong (and can't check right now), but I recall that a schedule can (?) trigger a backup to a sparse image (or the smart update of the content of a specific sparse image) residing on a network volume (that is currently mounted), can it?

If so, couldn't it then also maybe be possible to make the actual mounting of that volume trigger the backup in the first place (or the smart update of the image - which for me would be super!)?

Just hoping.

-matts

[dnanian]

Yes, and... it doesn't do that. I considered it, and might do it in the future, but it's not supported now.

[matts]

Ok & thanks for your replies again!
Looking forward to checking out the new version anyway!

-matts

[sjs]

Ok.
...couldn't it then also maybe be possible to make the actual mounting of that volume trigger the backup in the first place (or the smart update of the image - which for me would be super!)?


THANK YOU for the great new Backup on Connect feature. EXCELLENT.

I strongly second matts features request. Please consider:

I was just considering the reasons why I don't use Time Machine and why I am always drawn to use it. I use it for many clients yet not for myself.
It comes down to the fact that I really appreciate the set it and forget it nature of TM. I can tell clients to just plug in the drive as often as they can, and TM will automagically back up. Even better, a remote mac can be natively backed up to with TM. A sparsebundle gets deposited there. I can tell clients... Do NOTHING. It will backup. Or at most, click on this MenuItem to force a backup. TM will then mount the remote volume if it isn't already. Then it will mount the sparsebundle. Then it will do the copy. Then it will unmount everyhing. Very very convenient.

Why don't I like it for myself? I prefer bootable clone copies. I don't want/need the version control TM provides and consider it more a security risk for myself and certain clients.

So some clients I have use SuperDuper instead, which forces them onto SD's schedule and not their own. I made an iCal reminder as to when to switch the proper one of many rotating drives (offsite storage). It worked, but it was clunky. It was too easy to plug the wrong drive in at the wrong time and make SD unhappy.

Now you've totally solved that problem for clients backing up to external media with the new Backup on Connect. THANK YOU.

This makes life easier for me, I can now use this for myself and a few clients. THANK YOU.

But what I'd really like to do, is eliminate TM from most if not all of my clients. I just don't see most of the value of TM, but I do see many TM negatives including: 1) ever growing target drives 2) sparse bundles that can get confused and start deleting almost everything in them (if you ever have a bundle's internal size set larger than the host drive's size it resides on. possible if you relocate a bundle) 3) security implications of having documents on the drive you thought were deleted 4) non bootable media 5) restore process requires Leopard DVD and much downtime.

The one remaining value of TM is its ease at backing up to remote mac volumes (or Time Capsule/Airport Extreme), both due to its automount/autoeject of network volumes, and its easy menubar item.

So I'd like to second this request to include automount/eject and autocopy to network volumes--- so I can be rid of Time Machine forever.

If it had an easy to use Menubar item, like Time Machine, so much the better, clients would then easily see and understand what is going on.

Submitted for your consideration.... Thank you for your great work and continuing to improve SD.
Kind Regards.

[GM80]

Let me know what you think of it when you get it.

Well, Dave, finally got around to trying it. I like it :)

SD always seems to sit on "will eject when SuperDuper! quits" though, for quite some time after the process has completed. I just quit manually, which does unmount the disk but seems unnecessary. Does it eventually quit on its own?

[dnanian]

If it wasn't running when you plugged the drive in, yes, it'll quit after about 30 seconds.

[GM80]

Great! Thanks again.

[GM80]

Dave, I've also got a handful of these in my Console, about 10 hours since I last mounted the backup drive ... expected? Temporary?

9/18/09 12:26:06 AM com.shirtpocket.backuponmount[21053] osascript: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers.

9/18/09 12:26:06 AM osascript[21053] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find:
/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper

[dnanian]

Expected, diagnostics because the listed OSAX isn't fully Snow Leopard compatible. Hopefully Adobe will fix it.