Jump to content

baxsie

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by baxsie

  1. Update: It all went well as far as booting Windows PE from the USB drive and starting the Retrospect utility on the client PC. Restore of the ~230GB data backed up from the old Samsung 850 Pro 1TB would not restore to a brand new Samsung - 870 EVO 1TB. Retrospect claimed not enough space, even though it said there would be ~700GB free. Spent ~2hours on phone support and in a remote control zoom session proving that this is what happened. Strangely enough the restore kind of worked to another brand new Samsung - 870 QVO 2TB (yes, this exercise is getting expensive). Logging in with the user account gave Windows error message: "We can't sign in to your account". I was able to patch it up using the "Fix a corrupted user profile" procedure, but that is not a successful restore in my book. The phone tech "escalated" the problem -- as far as I can tell that just meant opening a support ticket on my behalf, which remains totally silent from the Retrospect side. This has not been a good experience.
  2. I went through creating the bootable Windows PE USB stick. The biggest problem is that the USB stick must be MBR, while it appears that GPT is now the default (at least for my machines and my USB stick). Once I got through using diskpart to make the USB drive an MBR drive, it all went well.
  3. Bump . . . is there a guide to create a Microsoft WinPE recovery flash drive that includes the necessary retrospect files to recover a client?
  4. OK, so Retrospect only deduplicates within a given backup set, and only one execution unit can access a given backup set. So if you want to deduplicate across machines, you are limited backing all the machines up to one backup set, using only one execution unit, which will be very slow. To me, that is crippled 😞 I do not care that everything has to go to one backup set, but limiting to one execution unit would make the job impossibly slow. Hopefully one day they can deduplicate across clients without the impossible performance penalty.
  5. Do you remember when Retrospect did not have multiple execution units? Basically it was single threaded? For sure deduplication was added some time after multiple execution units were introduced. I think it only deduplicates within a given backup set. There is a clue in the check box: Since I am using a disk storage group, there is a unique backup set for each drive (automatically generated, thank you). So I do not think it deduplicates across machines in this case. When I looked at it after deduplication was first introduced, the only way to make deduplication work across machines was to have all the machines back up to one (huge) backup set, and since multiple execution units cannot backup to a single backup set you are limited to one execution unit. I sincerely hope I am wrong . . . deduplication would save a ton of time and space if it could be enabled across machines while keeping multiple execution units enabled. Drat: https://www.retrospect.com/en/support/kb/storage_groups#_data_deduplication
  6. Thank you for your reply. This is good news. Is there documentation on how to create one of these Microsoft WinPE boot USB drives? Can the PE drive include the needed retrospect client? Also -- how to do the restore from Retrospect after it has booted on the PE drive? Is there anything special that I need to do during the backup phase to make sure the restore is successful?
  7. Thank you for your replies. I am using a disk storage group. Many of my clients are nearly identical Windows 10 desktops. I would gain a lot by being able to deduplicate across machines. Is it possible to configure Retrospect 18.2 to deduplicate across clients? For instance, if 9 clients all have an identical "command.com" file, can Retrospect be set to back that file up only once?
  8. If I want to be able to restore a windows client from the ground up, can I do that from a USB drive? Is there a tutorial on how to do that? Can the same USB drive be used on different machines, or would I need a separate USB drive for each machine? Minus 10 points for anyone who replies with "burn a disk" 😞 - unless you can back-date your post to 1999 :when that was a valid option :-)
  9. Finally side-graded from 16.6 to 18.2 I remember being super excited when Retrospect announced it had enabled deduplication -- only to be dismayed when I found out that it could only use one execution unit going to one backup set to make deduplication work. Some of our backups take multiple days (using multiple execution units), and backing up all our clients simply would not complete within the 1-week window if we had to use a single execution unit. Is this still the case in 18.2 or am I missing something? (Backup server is a dual Xeon with 12/24 cores, 144GB ram, backing up to one of two 6x4TB removable RAID 5 arrays - recycled and swapped weekly. Clients are a mix of windows PCs.) When it first starts up, it is pretty CPU heavy: Once it settles down, it is disk write (and possibly ethernet) bound:
  10. These numbers are using new fresh backup sets every time.
  11. 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.
  12. 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.
  13. 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?
  14. ... and once you have multiple NICs installed, how do you make Retrospect utilize them?
  15. 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?
  16. 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?
  17. 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?
  18. 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.)
  19. 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
  20. 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.
  21. 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.
  22. 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!
  23. 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.
  24. > I believe the Media Verification failure is only an issue with a file backup set. OK, it looks like I am supposed to be using DISK backup sets instead of FILE backup sets. Trying it out with DISK backup sets . . . so far no error.
×
×
  • Create New...