Jump to content

baxsie

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

0 Neutral

About baxsie

  • Rank
    Occasional Forum Poster
  1. baxsie

    Backup is too slow

    These numbers are using new fresh backup sets every time.
  2. baxsie

    Backup is too slow

    Without breaking a sweat -- 9GB from one client to the server in around 9 minutes, and from our linux file server, 8GB to the backup server in around 8 minutes.
  3. baxsie

    Backup is too slow

    We are backing up 8 clients simultaneously. The best example is the one that just completed -- 34 hours for ~378 GB. I don't know the average file size, but I will venture to guess that "many, many, very tiny files." is not what we're backing up.
  4. baxsie

    Backup is too slow

    Thank you -- a very useful answer. Then the definitive question would be . . . when will Retrospect be smart enough to know how many NICs are present, and then use them intelligently without reconfiguring every client you want to not use the default?
  5. baxsie

    Backup is too slow

    ... and once you have multiple NICs installed, how do you make Retrospect utilize them?
  6. baxsie

    Backup is too slow

    The theoretical I was referring to was based on actually measured bandwidth versus the theoretical per the specifications for gigabit ethernet. The 480 MB/min is what we're actually seeing, which works out to be 480 MB/min / 8 execution units = 60 MB/min per unit. That said, will retrospect take advantage of multiple NICs to get the backup done? If this is the case, we would have loved to have known sooner, as this would have made us change the backup server years ago. How much difference will multiple NICs make, in a real-world situation?
  7. baxsie

    Backup is too slow

    We're using Retrospect 7.6 on a quad core machine with 4GB of RAM, on a gigabit network, and to backup ~750GB of data takes around 24 hours. Here's the rub: 1Gbps = 10^9 bits per second / 8 bits/byte = 125,000,000 bytes per second or 122000 kibytes per second or 119.2 Mibytes per second ( source 1 and source 2 ) Theoretically then we're looking at a maximum of 4.5 GB / minute, so 166 minutes to pull that much data through the network, in a perfect world. Let's assume we actually get 25% of that speed. If this were the case, we would be looking at just over 11 hours to pull all that data through the network. This would be doing phenomenally well. Let's look at reality for our backup set now -- more along the lines of around 26 hours for our backup to complete, which would be equivalent to a little over 480 MB/min average. The problem is that 480 MB/min boils down to 60 MB/min per execution unit. What are we missing here?
  8. baxsie

    Retrosepct Server packed in!

    I found that the super-long "Checking Media" timeouts on my machine were caused by having a mapped drive. Apparently Retrospect tries to "Check Media" on the mapped network drive, and it takes forever. Can anyone else having the "Checking Media" Retrospect timeout problem try disconnecting all the network drives and see if Retrospect gets better?
  9. baxsie

    Retrosepct Server packed in!

    I have a similar situation. I use several removable 1TB eSATA drives. It has been fairly reliable. I "upgraded" to to: EN_7_5_508 with ru7514102 And now when I start up Retrospect, it seems to start OK, saying "Checking media". But if you do anything (change the scheduled date of a proactive backup, for instance) the Retrospect UI hangs. Basically unusable at this point. I have tried deleting: C:\Documents and Settings\All Users\Application Data\Retrospect\Config75.bak this makes no difference. Deleting: C:\Documents and Settings\All Users\Application Data\Retrospect\Config75.dat of course wipes all my proactive scripts. The really weird thing is if I leave it for a long time (more than 5 minutes), it seems to finally get out of its stupor and take off. What in the world is it doing when it goes to "Checking Media" and why in the world would it take so long to time out? So just now, it seemed OK, then I went to change the dates of some proactive scripts to force them to go now. I got a couple switched, then it is back to "Checking Media" with some super long timeout. I can do a directory of the external eSATA backup drive with a different command window, so that hardware is still responsive. Right now the Retrospect window says "Checking media", gives the hour glass cursor, but is otherwise totally unresponsive. I can tell that at least one of the execution threads is going, because the I/O bytes in the task manager are climbing for Retrospect. Just the UI seems frozen with that damn "Checking media" noise. Any suggestions? (Other than wiping 24 proactive scripts and the 120 backup sets that go with them--long story.)
  10. Here is a slightly modified rcl file we use that includes the LANG=C and a "restart" parameter: #!/bin/sh # Retrospect Client rcl script # # Contact Information # # EMC Dantz # 3003 Oak Road, 3rd Floor # Walnut Creek, CA 94597 # 800.225.4880 or 925.948.9000 # customer_service@dantz.com # # Copyright 2000-2004 EMC Dantz # # # Place this script along with retroclient, and # retrocpl in the directory specified by CLIENTDIR. ### BEGIN INIT INFO # Provides: retroclient # Required-Start: $local_fs $syslog # Should-Start: # Required-Stop: # Default-Start: 3 4 5 # Default-Stop: 0 1 2 6 # Short-Description: Retrospect Client # Description: Retrospect Client ### END INIT INFO export LANG=C CLIENTDIR=/usr/local/dantz/client case $1 in start) echo Starting... $CLIENTDIR/retroclient -daemon ;; stop) echo Stopping... $CLIENTDIR/retrocpl -stop ;; restart) echo Stopping... $CLIENTDIR/retrocpl -stop echo Starting... $CLIENTDIR/retroclient -daemon ;; status) $CLIENTDIR/retrocpl ;; *) echo "Usage: $0 {start|stop|status|restart}" ;; esac exit 0
  11. baxsie

    Error -540

    EXPOSED! And I was being so coy
  12. baxsie

    Error -540

    Thanks for the reply. > What is the exact version of Retrospect you are running? I'm running what I believe is the latest and greatest: Single Server 7.5.387 HotFix 7.5.13.100 The retropds_linux86.pdu that seems to work (posted above) has this clear text string in it near the start (it is a binary): ULnx7.5.111 The retropds_linux86.pdu that makes the -540 errors (included in some part of the 7.5.387 / 7.5.13.100 install) has this string in it: ULnx7.5.113 The ULnx7.5.113 version basically has less than 50% chance of making it through a backup of a given Linux client. Which makes it pretty much unusable. The ULnx7.5.111 posted above has not thrown a single -540 so far. However, I did get 12 of these errors on one of the four Linux clients: Generated MD5 digest for file "/var/spool/mqueue/dfm0FNcA7L026337" does not match stored MD5 digest. (repeated 11 more times, with various file names) To my understanding, using media verification, it would be impossible to have a MD5 mismatch unless there was a media error in the disk used as the backup destination. The client is not involved in generating or checking the MD5, correct? So there still may be some weirdness in ULnx7.5.111, since the drive I back up to seems to be otherwise stable, and none of the other files in the 669 GB (compressed size on the removable backup disk) of backup threw an error like this. > Where did you get this specific file from? Ummmm . . . let's just say I stumbled across it in a dark corner of the internet where proper gentlemen are not supposed to be seen.
  13. baxsie

    Error -540

    Interesting. After struggling with the Retrospect "-540 trouble creating service" error on my Linux clients, I came across a certain mysterious retropds_linux86.pdu that seems to fix the Retrosepct 540 trouble creating service errors. Since it was such a challenge to locate the file, I have stashed it here: retropds_linux86.pdu.zip Basically, make a backup of your original file, then copy this file over the one on your Retrospect server Windows box: C:\Program Files\Retrospect\Retrospect 7.5\retropds_linux86.pdu ***** DISCLAIMER ***** I truly do not know the origin of this file. It seems to fix the -540 errors, and generally work. Of course I make no warranty and although I hope it does work well, it might be messed up in some other facet. Hopefully (since it seems appears that this file originated at some point from Retrospect) the Retrospect folks will give us an official download, and an FAQ on fixing this error that is based on something other than forum lore and random downloads of questionable heritage.
  14. baxsie

    Linux client is "deferred" -- why?

    From: http://forums.dantz.com/ubbthreads/showf...vc=1#Post105495 Quote: While this topic is probably dead for those involved, I couldn't find the solution anywhere else, so thought I'd add it here for posterity. I had the exact same problem with the client being deferred. This was on a RedHat ES server running the latest Linux client. Finally, I made the connection -- I don't have a "DISPLAY", since we manage everything via command line. The installer automatically puts the "RETROSPECT_HOME" environment variable in the system login (profile) script. I guessed that when the server was trying to back up the system, it was trying to put up a dialog. With no GUI, it failed -- deferring the backup. My solution: comment out the "RETROSPECT_HOME" lines in /etc/profile. Other systems may need to do it in other places, but this is what worked for me -- finally! I had this problem too. A Retrospect Linux client 7.5.122 constantly deferred. This fix worked for us. FINALLY!
  15. Quote: While this topic is probably dead for those involved, I couldn't find the solution anywhere else, so thought I'd add it here for posterity. I had the exact same problem with the client being deferred. This was on a RedHat ES server running the latest Linux client. Finally, I made the connection -- I don't have a "DISPLAY", since we manage everything via command line. The installer automatically puts the "RETROSPECT_HOME" environment variable in the system login (profile) script. I guessed that when the server was trying to back up the system, it was trying to put up a dialog. With no GUI, it failed -- deferring the backup. My solution: comment out the "RETROSPECT_HOME" lines in /etc/profile. Other systems may need to do it in other places, but this is what worked for me -- finally! I had this problem too. A Retrospect Linux client 7.5.122 constantly deferred. This fix worked for us. I am posting to push this thread up. Because this thread showed the problem in '03, the fix by a user in '05 and still no FAQ by EMC in '08.
×