Jump to content

indigovic

Members
  • Content count

    13
  • Joined

  • Last visited

Community Reputation

0 Neutral

About indigovic

  • Rank
    Occasional Forum Poster
  1. I'm contemplating shifting my backups to one of the new Mac Minis connected to a Promise RAID via Thunderbolt. I recognize that there are potential Lion compatibility issues (which is another thread), but are there potentially any Thunderbolt compatibility issues with Retrospect?
  2. My situation is a little bit different in that I have some clients succeeding, but most failing. • Updated backup server (running on OS 10.3.8 Server) to Retrospect 6.1, then pushed client updates to all clients. Retrospect declared all updates successful. • Backing up Windows clients succeeded. • Backing up 2 Mac OS X 10.4.2 Server OS clients succeeded (have not rebooted machines) • All other Mac clients EXCEPT one - mostly 10.3.9, a few lower 10.3.x (including two 10.3.8 Server OS), and a couple of 10.4.x failed. Some of them were running 6.0.108, some 6.0.109, and some 6.0.110 previous to the update. • One 10.3.9 eMac, which, best as I can tell, is virtually identical to at least one of the other failed clients in both model and OS, succeeded. The only difference I can think of is that I *think* that one machine's initial install was 6.0.109, and was never updated to 6.0.110. The otherwise identical machine was also updated from 6.0.109, but it *probably* started with a version lower than that. In fact, this one machine that succeeded *may* be the only one I've got that only *ever* had 6.0.109 on it. -Vic. .
  3. I had a similar problem once, after Retrospect crashed. Restarting the computer blew away the lock. -Vic. .
  4. I have the same loader, SCSI card, OS, and software, though I'm running on a 1st-gen XServe. I can tell you that after upgrading ATTO's driver from 3.1 to 3.2. Retrospect no longer automatically recognizes that the tape caddy is reinserted after being unloaded. The problem appeared immediately after updating the driver; no other significant config changes were made at the same time, so I have high confidence that the driver version is indeed the issue here. However, I don't have to restart - I just choose "reinitialize elements" from the app's menu, and it figures it out in about half a second. It hasn't bothered me enough to back down to the 3.1 driver, but I'd suggest you give that a shot. -Vic. .
  5. Well, the problem is back. (I'm currently using 6.0.204 and RDU 5.9.104). Trying the Initialize Elements, and the Option-Unload... -Vic. .
  6. I use Backup Scripts so that I can create new, sequentially numbered backup sets automatically every week. I don't see how to do that with the Backup Server... -Vic. .
  7. The update seems to have corrected the problem for me, too. -Vic. .
  8. This has been frustrating me for a while now. If an OS X client drops off the network while being backed up, and no global threshold is set, Retrospect obviously fails to reconnect to the client - but it also keeps retrying forever, so it doesn't proceed with the script. If I set the global threshold to some minimum value, it at least gives up on the client - but then it also stops the script. In either case, my script fails, so some of the clients hanging out at the end of the script haven't been backed up in weeks. This sucks. Why can't there be an option to continuously check the speed, and just move on to the next client if one client falls below the threshold? I *need* this. I can't image why ending the script would be desirable behavior in most circumstances. -Vic. .
  9. My drive doesn't support bar codes. Backing down to the previous RDU appears to have solved the issue. -Vic. .
  10. I finally got some time to explore the issue again today... I placed a sled in the libary with tapes in the following order: 1: 7b7 2: 6a8 3: 4a8 4: 5a8 And asked Retrospect to scan the drive. It reports: 1: 5a8 2: 6a8 3: 4a8 4: 7b7 I'm just about to back down to the previous RDU. -Vic. .
  11. Since loading the latest Driver Update (5.7), Retrospect has been regularly confused about which tapes are in which slot of my Autoloader. I'm running OS X Server 10.3.4 on an original xServe with a Sony TSL-SA500c AIT Autoloader connected to an ATTO ExpressPCI UL3S/66 with the latest ATTO driver and firmware. The first backup after the update was a new media backup, which I left running overnight, loading the unit with four blanks. In the morning, It had used only three tapes, and was asking for a new tape; it indicated that the slot with the erased tape was holding one of the three used tapes, and was also misidentifying the two other tapes it had used. I forget what it was showing on the fourth tape. All of the tape icons were solid - not outlines. I assumed it was just one of those things that would fix itself, and manually dragged the tape in the slot that I knew held a blank; it scanned it, confirmed that it was really blank, and used it. The second backup was a normal backup to an existing storage set; when I came in this morning, it was asking me to load the tape that I knew was in slot 4, which it showed was one of the tapes created the previous night. Agian, I dragged tape 4 to the current slot, and it continued just fine. Several of the other tapes were misidentified as well. I din't take notes on what it was saying versus what it really was, but I will next time it happens. When I get a chance, I'll drop back to the previous Driver Update, but I just thought I'd see if anybody else has run into such a problem.... -Vic. .
  12. >I saw the .exe and thought PC-executable=never going to work on a mac.< That's certainly what I thought. In fact, I've been ignoring Windows updates for ages - unless I happen to think about downloading it while I'm visiting a Windows client - because of that. Thanks for the clarification. -Vic. .
  13. I only see .exe downloads available. Is there an .rcu updater file available in .sit, .bin, .dmg or any other non-executable form, for those of us who wish to update our Windows clients from our Mac servers? -Vic. .
×