Jump to content

5.0 Won't autoload media during verify


Recommended Posts

Hello;

 

 

 

I'm a long time happy user of Retrospect (starting with 3.0), and three days ago I upgraded from 4.2 to 5.0 in order to be able to backup a new OSX client (most of our company is running 7.6-8.6). I imported all my scripts and catalogs from 4.2 to 5.0 using the method in the manual, and I let it loose with my backup server over the weekend.

 

 

 

What has happened is that although the autoloader (reported as "Python 28849-XXX, v 5.AC, Archive Python DDS-DC (4.08)", a 4/8GB 4mm dat drive) loads a new tape fine when it needs it, it won't go back and load an old tape during verify (I use the verify in the backup server script). Much to my suprise did I check in on it on the weekend and find it stopped a couple of hours after I started it wanting the tape that started the backup. (i.e. - backup server backs up clients, one client spanned the end tape 1 -> tape 2, when the backup part finished and the verify stage began it couldn't go get the tape 1 from the autoloader, it instead popped up the dialog box wanting it). I was able to do that manually and get through that one. To fix the rest I set the "media timeout" to only 10 minutes, and when the media would time out it would just give up on the verify and go back to backing up. With this it managed to go until the four tapes in the magazine were filled (which I expected). This is retrospect 5.0.205, I'm using an adaptec Powerdomain 2930 scsi card on a Sawtooth G4 with 352MB ram, I started the backup with "recycle backup" (so I wasn't trying to add to an old set, I re-used an old tape set) and I backup lots of different macs and PC's (see rant below). This same setup works just fine with Retrospect 4.2 under OS9 (which is what I've been using), and I'm able to use "Scan Media" on the loader bar without a problem in 5.0. Am I missing something here?

 

 

 

The other thing I'm pretty annoyed about, is the dropping of Appletalk support, which I didn't even realize until I had it installed and noticed all my Appletalk clients were removed from the clients list. I still have a half dozen 68040 macs under 7.6.1 that now I can't back up. The TCP client requires PPC, and the Appletalk is unsupported. I still haven't quite figured out how I'm going to get around this, but I must say that for the money I paid this doesn't feel like an upgrade. Are there any plans to return this support, or am I now officially stuck?

 

 

 

 

 

Steven Cogswell

Link to comment
Share on other sites

Are you still on OS 9? If so, do you have the ADK for this drive? 5.0 does not require the ADK any longer, so delete the file from the Retrospect folder.

 

 

 

If you are in OS X, many users have found that OS X's more finicky SCSI support has required some changes in their configurations. For example, 68 pin drives must be connected to 68 pin cards. Some users have also found that changing SCSI IDs helped (try putting the drive at 0, 1 or 2 and the library at 3 above that).

Link to comment
Share on other sites

Hi and thanks for the reply.

 

 

 

I should have mentioned that, sorry. I used to use 4.2 under 9.1, but I've been using 5.0 under OSX 10.1.4. I have OSX (and it's 9.2.2 OS9) on a separate drive from my OS9.1 (which I still boot into to use for some day-to-day operations). I don't have the ADK, as I think it was the upgrade from 4.1->4.2 which added support for my Python autoloader. I did the 'import' by copying my old retrospect preferences folder to /Library/Preferences on the OSX drive (I threw away my old retrospect event handler script, since I noted it was making classic boot up when retrospect 5.0 started). My powerdomain 2930 (which has the 4.3 bios from adaptec) card has a 50-pin mini scsi connector and so does the external case the python is in. Also I don't think I can change the autoloader ID separate from the tape mechanism (there's only one set of pins for scsi id, and only one device (scsi ID 5) shows up on the device list in retrospect), but I will check that.

 

 

 

Having said that, I can't help but think this is a retrospect issue and not a scsi issue, as the unit changes tapes fine when it wants to get a new tape to write to, it's just when it verifies, and then it pops up the dialog box (which as far as I know, it shouldn't do when doing a backup server operation unless the tape isn't in the magazine). It knows the tape is in the magazine, because when I drop down the menu it's listed.

 

 

 

What I have in /Library/Preferences/Retrospect now is: LaunchRetroHlper, Operations Log, Retro.Config (4.2), Retro.config (5.0), Retro.Icons (4), Retro.Icons (5.0), and retrorunfile

 

 

 

 

Link to comment
Share on other sites

  • 2 weeks later...

Hello again;

 

 

 

Here's some further experience with this situation. I had the good fortune last night to be at work while this backup crossed tapes in the autoloader again, so I was able to observe a little more about what's going on during the Backup Server operation.

 

 

 

- Retrospect was happily backing up to Tape 6 of this backup set (5,6, and one blank which will become #7 are in the autoloader. Tapes 1-4 are sitting on the shelf since it's only the four magazine unit). During the backup (of about 250MB, coming from an OSX client) #6 filled, it wrote the index and "searched" for tape 7, settling on the blank tape (now #7) and continued on.

 

 

 

- When the backup finished and it began the compare, the dialog box for "please insert tape #6" appeared (since this backup had crossed from 6->7). I had the loader button accessible in retrospect, but when I dropped it down the only tape it "knew" about was #7 (the other slots in the loader were marked as "???", except for the one empty slot which said "empty" ), despite the fact it had just ejected #6 from the loader. I selected the slot where I knew #6 was. Retrospect nabbed it and happily started verifying.

 

 

 

- That part of the compare progressed as it should, and when it had finished comparing on #6 it again popped up the dialog box asking for tape #7 (to continue verifying). Dropping down the "loader" menu showed that this time it even had #7 still identified (ie - it knew the locations of #6 and #7 in the list, it wouldn't know #5 since it hadn't touched it during this whole operation). I selected the known location of #7, and again it progressed as it should. It finished comparing that machine, then moved on to the next machine in the client list without asking for tapes.

 

 

 

It never asks for tapes when it wants to write, it knows to search the autoloader if it hasn't found it. It's been happily backing up to this set since I started this thread, it just whines on the verify stage. I will note I did the upgrade to OSX 10.1.5 (on this backup server, and that OSX client) when it came out, it hasn't made any difference in this (it seems).

 

 

 

I hope this is of use to someone.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...