Jump to content

scottjwoodford

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

0 Neutral

About scottjwoodford

  • Rank
    Occasional forum poster
  1. There is plenty of disk space - 25GB.
  2. Yes, I am backing up to a RAID 5 volume. I have not tried backing the data up to another volume, because the backup portion of the process works fine. It is the grooming process that generates these errors. I am positive it is not a RAID issue. I have run multiple chkdsk's on the volume and have not gotten a single error. Also, this is happening on multiple backup sets. Yesterday I was told by EMC to remove the Windows pagefile (set it to "None"), restart, and re-add the pagefile. That did not solve the problem.
  3. Well, the technicians I've spoken to have not seen this error. The last one I spoke to the other day suggested that it could be a problem with Retrospect trying to create it's own page file in the "C:\Documents and Settings\All Users\Application Data\Retrospect\RtrExec.dir" folder (which I also mention in my post above). It was suggested that I rename that directory, and re-create a new "RtrExec.dir" folder to take up a different physical portion on the hard drive (aka those particular sectors may be bad). I tried that and it didn't work. I also ran a full chkdsk on the entire volume, and it found no problems. It was also suggested to me to rename the entire "C:\Documents and Settings\All Users\Application Data\Retrospect" folder, and re-install Retrospect (again, to have it reside on different sectors), which I also tried. That did not help either. I can pretty much guarantee that it's not a problem with the volume, and there is nothing wrong with that RtrExec.dir folder. Any other ideas on this would be greatly appreciated.
  4. scottjwoodford

    Deploy clients through group policy?

    Ian, From what I understand, Retrospect 7.5 absolutely requires using ISScript version 9 to install properly. Even if a client machine has a later version such as 10.5, it will still need version 9 to install. If you assign version 9 (or any other version as far as I know) through GP, it will cause the problem you are experiencing. That's why you have to re-package the ISScript9.msi file, as in the instructions above. Good luck! Scott
  5. Hello, During a disk backup set grooming operation, I occasionally receive the following error (multiple times in a row) in the log: "TMemory::createMapFile: Could not create the paging file, error 80" The grooming operation still appears to complete successfully, even though that error shows up. However, once I start seeing that error on a particular backup set, that backup set eventually starts getting corrupt (it starts failing during backups, can't find the catalog file, invalid catalog file, etc...). I have spoken with EMC about this several times, and they have not been able to figure out the problem. They suggested that it was because my backup set had over 3 million files, and said that I should break it up into smaller backup sets. Well, i did that, and I am still getting these errors even on a backup set with less than 900,000 files. It is also difficult to replicate this problem. It just happened to me about 30 minutes ago during a grooming operation (one that groomed 0 files by the way), and I tried to re-run grooming on the same backup set and got not errors. It happens very intermittently. Sometimes a groom will show these errors on a backup set, sometimes grooming on that same backup set won't show any errors. I read another post on this forum that mentioned the fact that this error shows up because Retrospect cannot create its own temporary paging file. It also mentioned checking the "C:\Documents and Settings\All Users\Application Data\Retrospect\RtrExec.dir" (where the page file is stored apparently) to make sure it is empty when Retrospect is not running. I didn’t see any problems with that directory though. I'm not sure what else to do. This is driving me crazy. I cannot tell you how many times I've had to recreate the catalog files because of this. Here is my system's info by the way: Windows Server 2003 R2 (latest patches as of this post) Retrospect Multi-Server 7.5.324, Driver Update and Hotfix Version 7.5.7.103 4 GB RAM (3.5 seen by Windows) 3.0 GHZ Intel Xeon Processor RAID 5 Configuration, one volume Thanks in advance for any help you can give me. Scott
  6. It would be nice to be able to change Retrospect client options such as throttling, or event notification, without having to go around to each machine to set custom settings.
  7. Just as the title says. It would be nice to have an incorporated software push feature in Retrospect that can be run from the server to install the software on the clients. Some of us don't have SMS, and Group Policy can be tricky when trying to install ISScript9.msi (a required package for installing the Retrospect client).
  8. scottjwoodford

    Change Retrospect Client Options Remotely?

    Thanks waltr. Posting in the feature request forum now... Anyone else have any ideas?
  9. scottjwoodford

    Proactive Backups Not Acting as Expected

    Sorry, it was a mistype. It is 7.5.285. Yes, I am backing up to RAID, and it is a disk backup set on a single volume. Yes, it is happening on multiple/random computers. I will check on the session contents tonight, but I believe one of the techs already ran through this with me. I will let you know. I am currently using thorough verification. Should I switch to media verification? I didn't see an option for that. I'm positive it is not changing files. These are all test clients that only I operate, so none of the files are changing (except maybe a few random windows files). Definitely not 30GB worth of files though. I will investigate more and see what I can find. Thanks again for all your help.
  10. scottjwoodford

    Proactive Backups Not Acting as Expected

    AmyJ, Thanks so much for the reply. As for issue 1, I will play with the wrap-up time and see if I can get it where I want it. As for issue 2, I should have given a much better example. You are correct that files are changing all of the time, and that I should not expect the # of files to be backed up to stay the same, even within a 5 minute time period. However, this is happening with several GB of data. For example, one of my test machines had a 60GB C volume that backed up halfway the first night (30GB), and then the script reached the stop time. The next night when the backup started again, it started completely over, and backed up the full 60GB of data. Something is certainly wrong there. If it were a few hundered, or even a few thousand files, I could understand. But we are talking about 30GB worth of data. Any idea why this might be happening?
  11. I have spoken to several EMC techs on this and there has been no solution. We have tried recreating everything (backup sets, scripts, etc...), reinstalling Retrospect, and several other troubleshooting steps. I have a backup server with a RAID 5 array, with Retrospect 7.5.281 installed (7.5.116 on the clients) on Window 2003 Server (R2 with latest updates). I have a proactive backup script set to backup clients from 7pm to 7am every day. The RAID 5 array is one volume (Z:), which is where the backup set, and catalog file are both stored. Obviously, when the script reaches the specified stop time, the backup that is currently running on a client (we'll call it "Client A" for this example) stops running. This is to be expected. There are 2 seperate problems that are happening here: 1 - When the script runs the next night at 7pm, Client A does not get backed up first. Client A is skipped over, even if only 2 files were copied from it the night before when the script stopped. I am not sure why it is moved to the back of the queue, and considered to be "backed up", even if it only copied 2 files. This is not what I expected. 2 - When the script reaches the specified stop time or the client computer is shut down mid-backup, it does not appear to resume where it left off the next night when the backup script is run again. After the 1st backup, Client A shows the following in the history log (the script reached it's specified stop time in this example): Remaining (files): 54094 Completed (files): 1531 After the next night when the backup is run again, Client A actually completes this time, and shows the following in the 2nd history log entry: Remaining (files): 0 Completed (files): 55628 Shouldn't that show, "Completed: 54094"??? As you can see, it appears to be completely restarting, even though it already completed 1531 files the night before. This is obviously a big issue. During testing I had a computer that would come on and off the network at random. It always restarted a full backup from the beginning everytime it jumped on the network. Thus, it never got fully backed up, even after 5 attempts. Any help you can give me is greatly appreciated. Sorry for the long post. Scott
  12. I have spoken with EMC support, and they have said that there is no way to change the client options remotely (aka - checkboxes like "Notify if no backups within X days", "Notify after backup", etc...). I was wondering if anyone found a way to do this remotely. In hopes of using a logon script to accomplish this, I have tried registry/file monitors to see which registry entries/files get changed on the client when those checkboxes are unchecked, and it all points to the following binary key: HKLM\Software\Dantz\Retrospect\Client\6.5\Config However I have tried exporting they key when the boxes are checked, and when they are unchecked. But importing in either of those scenarios has no effect on whether or not those boxes are checked in the client. It has to be making a change elsewhere. Any help would be appreciated. Scott
  13. scottjwoodford

    Deploy clients through group policy?

    No problem waltr. I will also try to make sure I have exhausted all posibilities before asking for help on the forums. I certainly don't want to waste anyone's time. I will definitely post the software installation push feature request in that forum. I think that would be an excellent addition. Thanks for all of your help. Scott
  14. scottjwoodford

    Deploy clients through group policy?

    Man, you’re rough! I was not all worked up about your comment. It just seemed like an attack, and after the many problems I have had with Retrospect thus far (and it’s not even in production), I was a little frustrated. (if you want to hear about my other problems, and offer suggestions, I would be happy to talk offline since it doesn’t pertain to this topic) Yes, I realize that checking an event viewer is a basic troubleshooting step, however there is certainly no need to throw that in my face. I will admit that it was a stupid thing to overlook before posting in the forum, but nonetheless it was overlooked. No need to bash me for it. The point I was trying to make in my last post was that finding it still didn’t help me, and was the least of my problems. You have to understand that all of us are not Retrospect experts like you are. That’s why there are forums. That’s why nice people like you answer our dumb questions. Insulting us does no good. Technically, the Retrospect documentation just says that ISScript9.msi also needs to be installed along with the client (if it's not already present), so you are right on that. I was not mislead by the documentation. In my opinion, it was just incomplete. So I will retract that statement. However, in response to your comment about who told me to push it through GPO, yes, it was in fact a Retrospect technician. I think many customers will agree that if Retrospect does not include a software installation push (like Symantec BackupExec for example), then they should support the install of the client through other means (aka Group Policy or SMS). At the very least, the documentation should mention that ISScript9.msi does not install correctly through a direct GPO push.
  15. scottjwoodford

    Deploy clients through group policy?

    <BIG RANT> I'm not sure if you are criticizing me or not, but if you are I don't appreciate it, and I don't think it's warranted. Either way, this was not an easy problem to figure out, considering the documentation in Retrospect is misleading. I thought I had figured it out by pushing ISScript9.msi, but I couldn't have been farther from the truth. I was told to push ISScript9.msi and Retrospect Client 7.5 Client.msi through GPO. However, doing so caused ISScript to be installed incorrectly, and thus the Retrospect Client install failed. Not only that, but after the push, I was unable to install any other software packages on these client computers that required ISScript. The push appears to install successfully, but I assure you it does not. There are countless articles on the subject. Check here for one of them: http://www.appdeploy.com/packages/detail.asp?id=725 The problem is, and I quote: "This installer never actually registers itself properly with Windows Installer and is not really designed for use with Group Policy...If you install it with GP directly, standalone installers that use ISScript will fail...Also, all of the versions of ISScript (7,8,9,10,11) use the same Product Code which means that more than one version won't install properly in GP." Just to inform those of you who attempt to push the ISScript9.msi package through Group Policy...DON'T. That is of course you follow the instructions in the above article. Otherwise it will screw up your systems. You must first create a wrapper package (as described in the above article). Once I did this, all went well, and I have had no problems since. So you can see that this was not just an easy fix, that I could have avoided with "basic troubleshooting", and thus avoiding a "big rant" on this forum. To all those who attempt to push the client through GPO, you have been warned. In addition, if you have problems, don't bother calling EMC, because they "don't support Microsoft products." </BIG RANT>
×