While setting up Retrospect, I ran into a number of problems, most of which I think I solved. I’m just noting some of them here, so I can find them again. Or so you can find them, perhaps. I’ll add to this post as I encounter more oddities.
Media set unlock
If you set passwords on media sets, which I think you really should, then if you set the media set password policy to “Remember password for scripted access”, then quite unintuitively the media set will be locked after rebooting the server. You’ll need to enter all those passwords again. Better to set the policy to “Remember password for any access” and that problem is solved.
“Waiting for media”
There’s this thing happening where Retrospect halts a script with the message “Waiting for media”, even though it’s a disk-to-disk backup and the media isn’t full. The solution is to go into Preferences -> Media, and activate “Media request timeout”. I set it to 5 minutes.
Oversized archives
One of the most brilliant features of Retrospect is “archiving”. This is a script that makes a complete backup of a folder, then deletes it from the source, effectively moving the whole thing to backup storage. Then, if you need it in the future, you “restore” it back. But if you interrupt the process by, for instance, rebooting, it starts over, which results in much larger backups (archives) than necessary. There must be a way around this, but I don’t see how. The same problem would, I figure, cause problems if you restore an archive, work with it, then archive it back again. You could argue, of course, that having two complete sets of the archive would be correct in that case. I don’t know, however, if you’d be able to select which archive you restore if they’re stored “over” each other in that fasion.
Dual-homed client IP confusion
If you have a client that is dual-homed, i.e. has two network interfaces, one each to another network, the Retrospect client will tend to get an IP from one or the other, waffling back and forth. And of course, the Retrospect server can’t find it if it’s on the wrong network. I did find a KB document that shows a fix, namely to tell the client to use a particular IP number using the command “ipsave”. See the document for particulars.
There’s one problem with that solution, however. If the client gets a new IP through DHCP, it will lose connectivity until you go run ipsave again. At least I assume so.
Connectivity
I had the Mac Pro that the Retrospect server runs on completely lose network connectivity at one point. None of the two interfaces would get an IP through DHCP, while showing as “connected”. I’ve never had that happen before, and the machine is nine years old, so I have a feeling it has something to do with Retrospect. After two reboots, the problem cleared. Before that, I’d changed the ethernet cable, changed from one interface to the other, and even changed the upstream switch, all to no avail. We’ll see if it happens again.