April 30th, 2004 • 5:10 am
I’ve discussed the problems that I have been experiencing with Apple’s Backup 2.0.x application before.
Version 2.0 was simply unable to perform scheduled backups reliably. At the scheduled time, the application would launch and then quit immediately. That was not exactly what I would call a reliable backup application.
Things improved somewhat with the release of Backup 2.0.1. But I soon noticed that the problems were not completely solved. Instead of a complete failure, scheduled backups sometimes result in Mac OS X launching two copies of the Backup application at the same time.
At the time, I sent Apple a bug report on this. To their credit, they got back to me asking for more information, and especially asking whether the destination of the scheduled backup was a volume other than the startup volume. They asked to test the procedure when the destination for the scheduled backup is the startup volume. I did, and it seemed to work better.
Now, correct me if I am wrong, but I don’t think that a backup application that is only able to save its backups reliable on the startup volume is a very useful backup application. After all, one of the main reasons why people have backups is in case they experience a hardware failure, namely of their internal hard drive. If the backup itself is on the hard drive too, then it’s not much good when the hard drive breaks down. The whole purpose of a backup application is to create backups on external volumes (FireWire hard drives or removable media).
Anyway… More recently, after I installed Mac OS X 10.3.3, I noticed that my scheduled backups (whose destination is on an external FireWire hard drive) were working fine for a couple of days. So I thought that the problem was fixed.
Unfortunately, once again I was disappointed to see that it wasn’t true. Soon enough, I was experiencing the same old problem again, with Backup launching two copies of the Backup application at the same time and, of course, the second copy complaining that it cannot complete the scheduled backup because the application is “already running“. Doh, as they say.
Yesterday, however, this particular problem reached new heights. At the time of my scheduled backup, with no apparent reason, I got this:
Yikes! Four different copies of the same application launched at the same time! Needless to say, I had to work my way through a number of dialog boxes complaining that Backup was “already running“…
Interestingly, this happened without any apparent reason. By this, I mean that things worked fine (or maybe with two copies of the application, but not four) the day before, and I didn’t make any changes that would explain the sudden flurry of applications.
To add insult to injury, Backup also required my attention a second time (after I had quit the additional copies) in the middle of the process, because it complained that it wasn’t able to copy a certain message in one of my “In” mailboxes in Mail. This particular error is clearly related to a particular kind of attachment that Mail doesn’t like. Not only does it cause the Backup application to fail, but also, when I have a message with this type of attachment in my “In” mailbox and I try to use the “Remove Attachments” command to remove the attachment from the message in question, it doesn’t work. Mail does its little thing with the message disappearing and then reappearing, but when it reappears it still has the attachment included. I get this problem with messages coming from one particular person, who uses Groupwise for her e-mail. I wouldn’t be surprised if the source of the problem was the way that Groupwise encodes attachments. (I have reported this to Apple as a separate bug report, but have yet to hear back from them about it.)
In other words, the whole process of scheduled backups with Backup in Mac OS X is clearly still too flaky. It works (sort of), but not without some kind of human intervention — which defeats the purpose of automated backups in the first place.
Here’s hoping that one day, things will work truly reliably.