Copy aborted because volume cannot be found

[gryphonent]

Today was one of the rare occasions when I actually had my Powerbook switched on BEFORE the scheduled backup. And indeed, SuperDuper did start up... however, not much else was happening. So I went into the log and saw that the schedule was marked red. Here’s the log entry:

| 11:00:53 AM | Error | The automatic copy aborted because SuperDuper! could not locate the Destination volume named System Backup.

I then realized that the dropdown menu for the destination was blank. Odd, because I have not changed the name for the destination nor done anything with it since saving the schedule. Also, when starting SuperDuper manually the drive is shown. Needless to say that it was present on my desktop throughout. Is it possible that, for customized backups, the saved schedule is not smart enough to realize that a bootable new copy exists? I.e. each time I was syncing manually (for reasons explained in previous posts due to the unreliability of SD to postpone scheduled backups) the drive I had selected in my schedule was “erased” even though the name is still the same? I cannot see any other reason for SD not to find the drive.

[dnanian]

If you erase the drive "outside" SuperDuper, you change its UUID, and we can't find it any more (we don't go by the name, we go by its low-level identifier -- that way you *can*rename it and it'll still work).

To fix it, you can either open the settings (they're in ~/Library/Application Support/Scheduled Copies) and set the proper drive, then save or delete and recreate the scheduled item.

[gryphonent]

I did not erase the drive! However, I used TechTool Pro on it, maybe Disk Utility to repair permissions. Also, I defrag the drive using iDefrag every quarter or so. Having said that, the drive’s sole purpose is to store the backup and be a source for temporary files. Which is, why I don’t understand the fact that the customized SD schedule did not find it. You’re not asking to re-edit the schedule each time one of the above applications is run?

[dnanian]

No, I'm saying something changed the UUID. I don't know what did that, but it's pretty bad form. I honestly don't know what it was, Jurgen, because we're trying to figure it out after the fact... but if it can't find the drive and it's attached, it's got to be because the low-level ID is different than it was when you created the schedule.

How it got changed, only you can know! :)

[gryphonent]

Let me phrase this differently: if it is possible that any of the above apps changed something on the drive that makes it impossible for SD to locate it, would it be an option to implement a schedule feature that only checks by a drive’s name? As I said, I’ve not erased the drive... only used the above mentioned apps on it. And SD. That’s it. I now remember that I did have to redo the schedule shortly after purchase, so this wasn’t the first time. I guess the culprit might be iDefrag or TechTool Pro if this is of any help to you.

[dnanian]

It's definitely possible, Jurgen, but if it did change the low-level ID, I'd consider it a bug in that app.

I definitely wouldn't want to locate the drive just by name. It could cause a lot of problems with multiple drives with the same one: the last thing I'd want to see is the wrong drive getting smart updated or erased due to a naming conflict. The whole point of using a GUID/UUID is that it's unique. A name just isn't safe to use.

[gryphonent]

Dave,

I understand. However, as I only have ONE backup drive it would truly help if SD could locate it. Not sure, but I believe the majority of people has no two drives with the same name. Especially private users.

The function to backup by name could be an option in the preferences with a warning that the change occurs at the user’s risk. TechTool brings this warning each time when the program is run... though it doesn’t need to have that nagging effect in SD. Maybe a combination of name and ID would be great, ie. “Hey, the drive has the same name but something tells me it is not the one I should back up.” Gosh, I don’t know... all I can say from my end: it happened at least twice I’m aware of and it shouldn’t have happened once.

The whole schedule feature is simply aggravating, which I’d like to stress again: no sign/advice when customized schedules were exercised successful the last time, no postponing of scheduled events if the computer is not switched on “one minute before” the backup starts, no reliable schedule despite the fact that the drive is present and has the same name.

Just my two cents from the peanuts gallery. I will keep an eye out for what might be causing the problem in SD. Having said that, when I was on SynchronizePro I did use the same apps and never had any of the problems mentioned above.

[dnanian]

There's no way for us to know, given a "snapshot" of a system, that you only have one drive attached with a given name, Jurgen. And while I understand what you're asking for, it's not something I'd want to do: even when something is "at your own risk", people still get burned and erase their own data... I'd like to minimize that kind of thing as much as possible.

[gryphonent]

Dave,

There is an incompatibility issue between SD and TechTool Pro! They were they only two apps used on my backup since writing in last time.

Today SD was set to run at 11AM but did not find the drive... which, needless to say, was attached and has not changed its name for years. It is a LaCie 160gig drive. As you are not inclined to offer the option to backup by name I would appreciate if you could get in touch with Micromat and let them know about the problem. I think it is better to establish a report from developer to developer and hope the issue can be resolved as I sure would like to - eventually - use the schedule feature of SD (which unfortunately has not worked for me since registering the program for a variety of reasons explained in previous posts).

[dnanian]

What exactly did you do with TechTool Pro, Jurgen? If SD can't find its drive, it means that TTP changed the drive's UUID, which is a huge no-no. It'll cause problems with SD and with OSX, which also tracks drives by this value.

Since you're their customer, you have far more leverage than I do. Please report what you did to Micromat, and feel free to pass along my name and email. I'll be happy to discuss it with them.

[gryphonent]

I run the intermediate suite (checking volume, hardware, files) followed by the maintenance operation (similar to DiskWarrior) once a month or so. I will write to Micromat as well.