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.