Jump to content

pweil

Members
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

0 Neutral

About pweil

  • Rank
    Occasional Forum Poster
  1. Has everyone gone on vacation? Nobody else has problems getting Retro to display the new tape set correctly? Is there a friendly EMC/Dantz 'MVP' out there who can offer a suggestion? Please?
  2. How can I get Retrospect 6 to rescan my autoloader after replacing the tape set? Configure device and rescan always result in Retrospect's displaying the previous set. Even after quitting and relaaunching Retrospect. All of the buttons in the storage devices window do nothing. I want Retrospect to rescan so I can erase all eight tapes. We used to be able to do this, but now Retrospect is being really stupid about it. What can I do? Do I have to rebooot the machine just for this? Frustrated yet again with Retrospect's dumb behavior, Peter
  3. Like others, retroclient has occasionally crapped out on my Linux boxes. I have an init.d script for restarting it, but once the client hangs, often I can't seem to restart it. What do other people use to restart the client? Here's my init.d script (running on Gentoo, btw): depend() { need net } export RETROSPECT_HOME="/usr/local/dantz/client" start() { start-stop-daemon --start -b --quiet -mp /var/run/retrospect.pid \ --exec /usr/local/dantz/client/retroclient -- --daemon eend ${?} } stop() { ebegin "Stopping retroclient" start-stop-daemon --stop --quiet --pidfile /var/run/retrospect.pid eend ${?} }
  4. pweil

    Help with Gentoo client?

    Thanks Claus. Actually someone created a retroclient ebuild for us, and it's mostly been working fine on three gentoo boxes (well, actually one has been a little flaky - retrospect says it's responding, but yet can't connect to the client for configuring). Peter Quote: hello peter, i have the client running on several debian and gentoo boxes. the problem is during installation retrospect expects RedHat RC-files and tries to copy the start-stop script to an unavailable location. just "mkdir /etc/rc.d" and the installer will make a file called "init.d" below that directory. move that file "mv /etc/rc.d/init.d /etc/init.d/rcl" and adjust the symlink "/usr/local/dantz/client/rcl" to point to the correct script. works great. regards claus
  5. The URL given here returns 'page not found'. I think the correct URL is www.dantz.com/en/support/updates.dtml Quote: Today we released some major updates for Retrospect 6.0 for Mac 6.0.204 of Retrospect 5.9.104 of the Driver Update 6.0.109 of the Retrospect Client for Mac For download info and change info visit www.dantz.com/updates. This update is recommended for all 6.0 customers.
  6. Well, after not being able to resolve this, I finally decided to bite the bullet, follow your suggestion, and call Dantz as soon as the tech support line opened this morning. After receiving a service request number, I've been on hold waiting for a tech support person for more than _two_ hours. With no indication of how long it might take, although the recording keeps reminding me that my "call is important". Lord, this company stinks.
  7. pweil

    Help with Gentoo client?

    I've been handed a Linux box that was recently 'moved' from Red Hat to Gentoo by someone else who is no longer here. The retrospect Linux client was installed and previously worked under Red Hat. It is still there, but is not running and can't be found by the Retrospect backup machine. I know this isn't officially supported (note to Dantz: not everyone uses Red Hat), but can anyone suggest to me how I might get this client back up and running? Has anyone had luck running the client under Gentoo? Thanks, Peter Current location is mnt/sda6/local/dantz/ The files I see are: -rwxr-xr-x 1 root root 3171 Jun 2 2003 RetroClient.sh -rwxr-xr-x 1 root root 152438 Jun 2 2003 libRetrospectIO.so lrwxrwxrwx 1 root root 20 Dec 5 2003 rcl -> /etc/rc.d/init.d/rcl -rwxr-xr-x 1 root root 507222 Jun 2 2003 retroclient -rwxr-xr-x 1 root root 200467 Jun 2 2003 retrocpl -rwxr-xr-x 1 root root 1996 Jun 2 2003 retroeventhandler -rwxr-xr-x 1 root root 357539 Jan 8 2004 retropds.23 -rwxr-xr-x 1 root root 55310 Jun 2 2003 retrospect.jar -rwxr-xr-x 1 root root 6090 Jun 2 2003 rpm-post-install.sh
  8. Quote: Hi So far we have two reports on the forum from two users having trouble with 5.7. I've asked them for some additional information. If we do find a problem we will most certainly address it. At this point very few users are having trouble. Otherwise tech support would be swamped with inquiries. This isn't happening at the moment. If you are concerned, make an extra copy of your 5.2 driver update before you install the 5.7 update. If you run into trouble you can go back to the old RDU. Please let us know if you have problems. All of our problems (mentioned on a different thread relating to 515 piton errors) have been occurring under 5.2. If we want or need to use RDU 5.6 after trying the 5.7 update, is 5.6 available somewhere on Datz's web site? TIA, pw
  9. What sorts of issues? Is this documented and/or acknowledged somewhere by Dantz? My copy of Retrospect says Driver Update 5.2.101, and we just upgraded to Retrospect 6 (Mac) in July. The only Driver Update on the Dantz site that I can see is 5.7. If I need something other than 5.2.101, where can I find RDU 5.6 and not 5.7?
  10. Using Retrospect 6.0 193. If we change add one or two tapes to our Quantum L200 AutoLoader, and tell Retrospect to rescan the selected slots, the results don't reflect the changed tapes. It appears that Retrospect doesn't even scan the slots; the 'scan' is so fast (a second or two at most) that it must be checking some cache it has instead of the slots themselves. This is no good. How can we tell Retrospect to _really_ scan the selected slots and provide updated results without quitting and relaunching it? We never had this problem with previous versions. Do we have a bug here? -pw
  11. Quote: Given the raw capacity of your autoloader, if you're getting about 25% compression, that 50GB wall you're running into could be due to your autoloader changing tapes, which would make your problem identical to mine. Does your autoloader have the ability to log media changes, or else can someone supervise the autoloader when your backup is about to hit your 50GB limit, and see whether the piton error happens right after a tape swap? We were thinking the same thing, and are going to test this tomorrow.
  12. Just to add some more info about our situation: after reviewing the logs, we discovered that what has been happening to us during and after our new media backup this past week is nearly identical to what occurred during our previous new media backup one month ago. The pattern is this: each night, the Mac OS X Server client backs up approx. 50 of 200 Gb to our Quantum AutoLoader using 40/80 DLT tapes, then the backup dies because of a 515 piton error. Our two other Linux clients back up with no problem. When fewer than 50 Gb remains to be backed up, there is no failure or piton error. I have no idea why the number 50 Gb would have significance, but this is the pattern. We had only one exception to this pattern last month when one night the cient backed up 90Gb with no piton error. We're going to try a test of doing a special >50Gb backup with at least two tapes and see what happens. -pw
  13. The backup completed tonight without any failures, so I couldn't check on how retropds.23 behaves during a failure. We'll probably have to wait until the next time we have 50+ gigs to backup on this client -- most likelythe next New Media backup a month from now.....unless we have time or a chance to do a test.
  14. 1. No - initially it seemed to coincide with a new media backup (not quite the same as 'media change' as described above. But it has occurred since in the ways I've already explained. 2. We don't get media requests becasue we use an autoloader. It (normally) already has access to all fo the DLT tapes it needs. 3. It occurred during our last two New Media backups - late-July and late-August. But also during normal backups since the last New Media backup. 4. I see a retropds.23 running during the backup right now. I'll have to wait for it to fail before I can answer your question. But it just might make it all the way through tonight since it only has 10GB left to backup, as opposed to 200GB. I'll update this thread when the backup either gets completed or dies - shouldn't be long. Quote: pw, This thread was started with the title "Backup fails during media change..." but your reports do not include that. - Can you confirm that you're not seeing the connection fail during a Media Request? - You earlier noted that it was coinciding with a new media backup; is the current failure to connect happening on a New Media execution? There are two unix processes running during client backups; pitond (which runs all the time) and retropds.22 (which launches when the client begins to provide files to the application machine and quits when it's finished). - If you watch the client's processes during a backup, does retropds.22 die at the time of failure?
  15. I'd rather not discuss the paid tech support issue here. You're entitled to your opinion. As for our problem, this client is on the same segment as our other clients as well as the backup machine, all connected to the same 10/100 switch. There are no 'network complexities' here. The other clients exhibit no problems at all. Everything points to soem kind of client issue. What is happening is that this OS X Server client gets 50-55GB of data backed up each night before Retrospect bails with the 515 piton error. There is a total of approx. 200GB to back up to a DLT autoloader. It doesn't appear to stop on any particular file; it's the consistent amount of around 50Gb that seems notable and puzzling. An email from my assistant also adds the following notes: "...current ruleset- (format is chain position, allow/deny ipd/udp, from ip/mask to ip/mask). 65535 allow ip from any to any. So... the firewall isn't in the way at all.... What is happening is that the connection -is refused- by the client. I've already verified that by ssh'ing into .16 and telneting into retrospect's ports, and failing. ..." -pw
×