Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About BryanHill

  • Rank
    Occasional Forum Poster
  1. Quote: You give absolutely _no_ details about your setup or exactly what you're seeing. Geez, sorry. Such strong words! I thought I explained it just fine, as Robin responded with the exact symtom I'm seeing. Quote: What exactly is a "random freeze?" A software freeze that occurs at various times during an attempted backup, hence the word random. There is no set pattern in the behavior. I guess you enjoy kicking people in the nuts around for lack of details. You seem to do it in numerous posts on here. Bryan
  2. Force quitting also has a bad side effect...the catalog gets corrupted. I've been rebuilding for the last 19 hours. ouch. Bryan
  3. Yes, it does. It's actually happening to me right now as I type this. Bryan
  4. I'm having an issue with random freezes while running a backup script. Sometimes the freeze happens when connecting to a client, other times while a client is being backed up. The only way to get out of the situation is to do a force quit of Retrospect on the backup server. The behavior does not seem to be client-specific. It occurrs on different clients at seemingly random occasions. Additionally, it has happened to me with all three platforms, Linux, OS X, and Windows. Is anyone else seeing this phenomenon? Thanks, Bryan
  5. I finally got the tape loading issue resolved. There were two versions of firmware for the Quantum SDLT drive, one from Quantum, and one from Overland Data. The Quantum version does not work, while the Overland version works. Thanks for the help, Bryan
  6. I'm backing up a dual Opteron machine with no problems...you just need to fix the symlink to init.d as mentioned in the thread below: http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Number=30893&page=0&view=collapsed&sb=5&o=&fpart=1 Bryan
  7. Thanks. I now have an incident number from customer service, but have been unable to get connected to a technician all day. Bryan
  8. Hello: I upgraded to 6.0 from 5.1 yesterday. I've run into a snag with my SDLT tape library that I have not seen with any previous version of Retrospect running on OS X. In the Configure -> Devices windows, the tape library and the SDLT drive show up just fine. I can load a tape into the empty drive from a slot, no problem. The problem comes when it's time to unload. When I either: 1. Request an unload by dragging the tape out of the drive back to the slot 2. Click the Unload All/Mag button 3. Click Eject The drive itself goes to the status of "Unloaded" and the Device window reports the same, "Unloaded"...but the loader never grabs the tape to stow it back into its library slot. I have to go to the tape library itself and manually unload the tape to get it to fetch the tape from the drive and stow it back into the slot. Additionally, if I ignore the above and try to load another tape using the Device window, I get a spinning balll, and sometime a kernel panic. This also occurs if an automatic script tries to unload a tape to fetch a new one...it fails. Interestingly, when the Device window reports the drive as being "Empty" and "Unloaded" the status of the slot in the library claims the tape is "In Drive"...so something is not happening when an unload is requested. I also tried setting the tape library's Unload option to both "Implicit" and "Explicit" with no change in behavior. I had to downgrade back to 5.1 to continue my backups...I really like the barcode support in 6.0 (which seems to work). Here is my hardware/OS setup: OS X 10.3.2, Retrospect 6.0 Xserve Dual 1 GHz, 512 MB RAM, 2 x 80 GB HD, Gb ethernet connection ATTO ExpressPCI Pro UL2D SCSI host adapter Overland Data LibraryExpress, model SDLT-LXML1115TB, firmware v.1.06 Quantum SuperDLT1 tape drive, Rev. 23 Any thoughts? Thanks, Bryan
  9. There is a knowledge base article that says future versions of Retrospect for Windows will support OS X clients. At this time, the Windows version does not. http://www.dantz.com/index.php3?SCREEN=knowledgebase_article&id=757
  10. Hi Irena: The operation is launched from a script. This is set to run unattended by default, correct? Bryan
  11. Hi, This is specific problem that I am having with the model of tape autoloader I'm using. Perhaps someone out there has the same one and has figured it out. I have an Overland Data MiniLibraryXpress 15 tape autoloader. When a tape becomes full, Retrospect recognizes the fact, but doesn't load the next blank tape. It wants me to choose the next tape, load it, then click "Proceed" to continue. I have Retrospect set to run unattended, and the autoloader's library mode is set to "Random" allowing the host machine software to control the robotics. I tried setting the tape loader to "Sequential" mode, in that the loader itself will control the loading of tapes, but Retrospect seems to get confused. It waits for some communication that the next tape is ready, but never gets the message. I have a feeling this is because of the model I am using. But if anyone has ideas, I'm all ears :-) Thanks, Bryan
  12. I tried the following I did a clean install (including deleting old prefs) of Retrospect 5.0 with the latest patches. I then logged in all 85 clients (!) again and I launched a full backup over the weekend. The error did not occur. Before doing this, the Windows clients that were causing the inconsistency errors were indeed running the latest version of Retro client (5.6). I'm wondering if the client database somehow gets corrupted by using the latest Windows client? The client database seems to live inside of the Retro.Config (5.0) preference file. This file is currently 142 MB in size on my machine. I'll keep an eye on things this week...I generally do one full backup at the beginning of the month, then incrementals there after. I'm running Retrospect 5.0 Build 205 on a G4 867/OS X 10.1.4/640 MB RAM backing up to an Overland Data MiniLibraryXpress 15 tape autoloader with a Quantum SDLT-1 drive.
  13. Hi Irena: Here's what I'm finding now. If I even connect to a client to modify the configuration, I can consistently get the elem 16.c-687 This seems to occur on Windows clients only at the moment. I went to the client computer and rebooted it, and I'm still getting the same error. I went to the client database and "forgot" one of the clients that was having the issue. I was able to log back into it and configure. When I tried to launch an immediate backup of the client, it bomed with the same error.
  14. Hi Jan: Yes, I'm running the software on a G4 867 with an ATTO SCSI card. I reverted back to the previous 5.0 version and I didn't get the error. But now I have to watch the RetroRun process so it doesn't get out of control! Bryan
  15. Ouch. I have this error too after updating with the patch. Most of the machines in last night's script backed up fine. It fialed right at the end on a Windows client running Retro Client 5.6 I'm running Retrospect 5.1.023 Server Edition on OS X Server 10.1.3