Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by bobbodavis

  1. That is correct - priority has not been in use on the clients since version 8 of Windows and I'm not sure of the corresponding Mac client version: http://forums.retrospect.com/index.php?/topic/150758-where-did-the-client-priority-slider-go-in-820-177/
  2. Ditto to Scillonian's post. Often times, you will save time (and patience) in the long run, by creating a brand new backup set and starting from scratch. Then just hold onto the old one for length of time for your retention policy. Unfortunately, this is not ideal in many cases, especially when you have large backup sets that take days to rebuild from scratch. However, I've tried to groom/repair on several occassions, only to have to turn around and recreate the backup set anyway. The real downside is the cost of drive space to maintain 2 backup sets of the data, but if you have the room, it shouldn't be much of an issue. This has probably been my biggest complaint of Retrospect over the 5 years we've been using it. Unfortunately, it isn't just Retrospect that suffers from this problem.. I've also used CrashPlan and Acronis True Image Home and find that they also suffer from this behavior (given enough time, the automated backups eventually have a problem of some kind). It's not a matter of "if", but "when" your backup data, or the associated catalog file, will become corrupted. The constant reading, writing, grooming, unplanned reboots (patching while a backup is running), etc, will eventually cause an issue somewhere. As a result, starting fresh every now and then with a backup set is a good idea if you have the space to hold onto the old one for awhile, while you create the new one and let it build up some history. Probably not what you wanted to hear, but that has been my experience anyway.
  3. Yes, thank you, I'm aware. That was the one I was using as of yesterday that I thought had resolved the issue. I was running It Looked good at first and was working fine when I left for the day, but crashed sometime overnight and then basically repeated the same behavior I experienced with the previous build after upgrading from 9.5 before. I've reverted back to 9.5 for now and it is working again so I'm not dead in the water. However, I have reached out to technical support to see what they suggest and/or if they still would like me to run procdump.exe against retrospect now or the previous beta version ( Behavior seems similar so I imagine it will be against the latest, but want to check with them to be sure.
  4. I guess I spoke to soon. Came into work and found the system had crashed again. Same behavior as before... upon attempting to check nearly any backup set (double click on it or via right click >>> properties), the Retrospect Application immediately force closes and the behavior is very repeatable. I removed 10, rolled back to 9.5 and replaced the Retrospect directory with the Config77.dat files and once again it is working fine with 9.5. Unfortunately, the way Retrospect is instantly crashing, it is not able to write anything to the assert.log file so I can't pinpoint what the cause is. I had this happen back on 7.1.4 on a different server and ultimately gave up and started with a fresh config file. At least I'm working with 9.5 so don't have to go that route (yet), but it's a real shame to pay for the the latest version and support and not be able to utilize it. I will attempt to contact support again and see if they can provide a bit more assistance this time.
  5. That was a paragraph, but I'll appease you in the future by adding more spaces to help you with your reading. Feel free to add any troubleshooting or assistance in the future instead of critiquing the formatting of my writing. I was under the impression that this was a user-based forum for assisting others? I did contact support - the very same day. Of course, they are several hours ahead (somewhere in Europe?) and did not respond until the next day. Despite my request to be contacted in person, I only received emails for follow-up, but at least I did hear back. Their suggestion was for me to download and install a beta version of the software that had had not been publicly released at the time. Since I was able to revert back to 9.5 and have a working version already, I opted not to try the unreleased Beta version. Regardless, in the end, I am now up and running with which seems to be working correctly. I'm not sure if it is just a more stable version, or perhaps it helped to first upgrade from then to before finally upgrading to the latest version of I was not initially aware that was available, as my application already said it was up-to-date and only stumbled across in the archived versions. Either way, I'm glad to be running the latest version without the software crashing every few minutes. If there are others out there that may run into similar issues with upgrading, I hope this provides some assistance. And remember, always, always, always, backup up your "C:\programdata\retrospect" folder prior to making any major changes. Probably a good idea to use VSS or some other backup application to back up this particular directory on a regular basis (just in case). I've had similar issues with earlier versions of Retrospect and have been able to save my configurations/settings by reverting back to a previous day (sometimes a few days back) backup copy when random Retrospect crashing would occur.
  6. FYI for anyone who is considering upgrading from a previous version of Retrospect Server/Multiserver to the latest version. I don't know if this is just me, but I've opened a support case and am hoping for some feedback and assistance. Long story short- retrospect crashes when I do ANYTHING in after upgrading from Well, not anything, but most things. I can't even check the properties of 90% of my existing backup sets without a force crash occurring. I even tried creating a new backup set (which creates a new catalog file for it too) and then telling it to recreate the catalog file from existing backup files.....CRASH!!!!!!!!!!!!!!!!!!!!!!! I've been able to successfully do a manual backup of the handful of systems where the backup sets don't automatically crash the entire application just by double clicking on them. Only the manual backups seem to work though - proactive backups start, scan the system and as soon as they go to write the first change.... CRASH!!!!!!!!!!!!!!!! Luckily for me, I've learned from similar experiences with this software to frequently backup the entire "C:\programdata\retrospect folder" so I had a fresh copy of it just before the upgrade took place. I was then lucky enough to be able to remove Retrospect Multiserver 10 from my Windows 2008 R2 system, reboot, clean install 9.5 again and copy back by config files. After that, everything is working as it was before ..... PHEW!!!! I'm really miffed about the whole process though!!! After a lot of troubleshooting, attempting several over the top install/repairs, etc, I believe there may be a bug with this version and recommend staying away for now if you plan to UPGRADE from an earlier version. I did install a fresh version of for workstation as a separate test and it works fine as a clean install. I think the new version is having a hard time reading the existing catalog files and that is what is causing the issue. Then again, why couldn't I create a new backup set and recreate the catalog file from the existing backup data in this version either??? I really can't afford to rebuild from scratch in my environment as we have multiple backup sets that are several hundred GB each (a few are a couple TB each) - this probably goes the same for many others using this in a business environment. It is way too time consuming to recreate 30+ backup scripts, 30+ backup sets and then have every system backup all of that data from scratch... plus, there's no way I'm going to wipe my storage space clean to free up the necessary space again, while losing all of my backup history and retention in the process. Interestingly enough, there are 0 posts about version 10 in the forums so far, anyone else using it yet and/or able to upgrade without issues?
  7. I'd run the backup and see if it gets it or not. It sounds like you set it up correctly though. I've noticed that when doing data restores, directories I have excluded will show up, but then when you look inside of them, they are empty like they should be. So it kind of appears it backups of the excluded directory at the root (basically just the folder name), but then it excludes everything like it's supposed to. You could also create a filter that excludes any folder containing just "Recycle.Bin" or "*Recycle.Bin" as that should also accomplish the same thing and set it to only set for directories with exact spelling since the folder is C:\$Recycle.Bin.
  8. Might also want to try resetting the Windows firewall option from the client as well. Retrospect has a built in application for this already. On a Win 7 x64 system, it resides on: C:\Program Files (x86)\Retrospect\Retrospect Client\retfwset.exe for Win 7 x86: C:\Program Files\Retrospect\Retrospect Client\retfwset.exe I'm not sure about XP. Might be in the same location as Win 7 or perhaps under the default user profile such as "C:\documents and settings\all users\app data\retrospect\retfwset.exe"
  9. Ah, I was not aware that the slider bar had no effect in version 7. Good to know that the 20% status is only a cosmetic bug in version 8 since the priority is dynamically adjusted now.
  10. I am also curious. I have not tried the on demand restore or backup yet, by my 8.2.0 clients show nothing in the history either (just a spinning circle in the right hand corner). From the client, I can see the "last backup" status, but nothing for the "next backup" and nothing in the "history". Of course, when I log onto the server and open the backup script, the history is all there, so not sure why the client is not seeing that, or at least what it knows has previously taken place locally on the machine. I should note that I'm still running server 7.114 though and client 8.2.0 so that may have something to do with it (have not heard from my other posts yet about this though to determine if that could be the issue). Steve, what version of the server software are you using?
  11. OK I'm still running server 7.7.114 at this time, but have upgraded by client version to 8.2.0 (177) so maybe that's the problem. I did this though, because I like the new client much better as it actually places an icon in the Windows notification bar that lets me know when a backup ran, or if it didn't run for a few days. In the older version, Windows would blow up your screen with a UAC notification that you had to allow to see the message and that was ANNOYING to have to go through the UAC process which was like a mini display change to view the message and revert back. So, as my setup is (server 7.7.114 and client 8.2.0) I currently don't see a "Priority" slider option anymore on the client side. Also, the clients I did upgrade to 8.2.0 clients show up on the server with only 20% priority by default. When they we're running 7.7.114 we had set them to 80% priority so I'm not sure why it chose to default to 20%. If anything, it should have set to the default, which used to be 100%, if I'm not mistaken? Has the priority slider been removed in version 8.2.0, is it a bug in the 8.2.0 client for the priority and/or is this just an inconsistency in my case because the server version is older than the client version?
  12. Have the same issue with a few of my clients. Have not found a fix. However, once you enter by IP, it seems to work as long as you don't try to search for it by name or double click it in the client list again. I hoped that removing the client from the server setup, closing down the server side applicaiton, restarting the server side application and re-adding the client (since it sees it as an available client still) would do the trick, but no dice. Like you, for these "problem" clients, I just manually connect by IP and once it says that it's successful, I don't touch that client again and it will then continue to work.
  13. I don't understand it either. We ask, and ask, and ask and ask, but are not heard. This seems like a simple fix (maybe not in the actual code) but the implementation should be a standard feature - especially at the latest server license price points. It wasn't there in version 6, not in 7, and now not in 8 (or any of the implementations inbetween) I sure hope it makes the next release - there are a lot of other backup solutions out there these days... I'm just saying.
  14. Probably not a good idea to post the actual license keys on a public forum. You're screen shots show the keys in plain text ... Back to your original question though, I get those errors on occasion too - usually in Windows 7 under a user profile in a hidden "appdata" folder that has constantly open files (like GASMO for Gmail). Don't really know why, but I can only assume that Windows VSS may have them locked already because they are constantly changing (i.e. a mail client that is open all day and receiving new messages). Rebooting the client system "usually" helps resolve the issue.., at least for a while anyway. Update: Also looks like your errors are for files in Internet Explorer temp directories. You could filter your backups to ignore those. Otherwise, you may continue to see them if the backup is running while files are changing. For instance, the files exist during the retrospect scan, however, the user clears cookies/cache/temp IE settings after the were scanned but before they could be backed up (I have my browser set to clear everything upon close so it's a very possible scenario). The files then fail to backup because they don't exist or have been changed.
  15. If the computer is already asleep, then retrospect will not run. There are 2 places to enable "Wake on Lan" in retrospect, but I have found that it does not actually work (and yes, WOL works on my machine from other apps and is enabled in the bios). Retrospect has these options: 01) when you click on "configure / clients" and double click your client. Then on the general tab, enable the box "enable wake-on-lan". 02) in your backup script click on options (make sure you already have advanced options enabled). Under Execution / Client, there is another box for "enable Wake-On-Lan" Make sure that box is checked. Again, I have these settings on all of my clients, but it does not seem to work from Retrospect, even though WOL works from other applications just fine. I think this is a broken feature. If a backup is already in progress, I do not think your client should go to sleep, but can't confirm. You might want to make sure that your NIC is set to not allow itself to turn off to save power. This is done from computer management (right click "my computer" and select "manage". -Click on Device Manager -Find Network Adapters and expand -Find your NIC -Right click and select "properties" -Click on the "power management" tab If there is an option to allow ' wake on magic packet or something like that, make sure it is enabled - check other tabs to see if there are any options to allow the computer to put the NIC to sleep to save power and disable them if there are. Also check "power options" from control panel. Click the "cahnge advanced power settings" under your power profile See if there are any options for Network adapters and make sure that they are all set to a configuration that will not allow the computer to put the NIC to sleep to save power. -
  16. Not sure by your post if your system is acting as the server, or if you have a server and are trying to backup the client? Is this on a domain/enteriprise environment where a firewall rule may be blocking the connection? Regardless, I'd try this first... this is the only way to do a a real "clean" uninstall / reinstall which will also prompt to allow the software through the local Windows Firewall port. Keep in mind that if you use another firewall application, you may need to specifcially allow the Retrospect application through. In that case, allow TCP and UDP port 497 in both directions to the computer system - which is what Retrospect uses to allow the server and clients to communicate on a LAN. To cleanly uninstall and reinstall the retrospect client, this requires removing the application from control panel / add/remove programs and then checking for any left over "retrospect data" in these locations and deleting them: C:\ProgramData\Retrospect Client C:\Program Files (x86)\Retrospect C:\Program Files\Retrospect C:\Documents and Settings\All Users\Application Data\Retrospect Client Once everything has been cleaned, REBOOT, then reinstall the lastest client version again. One other thing to note. Retrospect does not automatially remove the "old" client that you just remvoed from the computer. You have to manually remove it from Configure / Clients in the left side panel options. If you don't and you accidentally point your backup script and/or backup set to the old client instead of the new one (once you've rejoined it to the server), you'll still get the error -530 backup client not found, because of course, it won't actually exist as it was removed.
  17. Probably not, I see this message sporadically, but it's not that frequent. By default, Win 7 uses Volume Shadow Service (VSS) to provide the Win 7 option "restore previous versions" for users so that they can easily restore older versions of files on the Operating system partition or drive. Retrospect also relies on VSS to be able to backup "open files" which would otherwise be locked out. So, if VSS is already in use by Win 7 and Retrospect is trying to backup the same "open" files at that particular moment, there will be a conflict. Maybe try backing up the system with Retrospect at a different time, especially if you know that Windows 7 backup is already running during that time frame. If you want to check your disk for errors, run "chkdsk /F" to scan and disk for bad sectors / tables and force a repair. Or, from the OS GUI, right click the drive, select properties and use the Error-checking "check now" feature. These options may take some time though, so be prepared to give it a few hours depending on the size of your disk.
  18. Have had this problem several times. Uninstalling and reinstalling the client does NOT work. This requires removing the application from control panel / add/remove programs and then checking for any left over "retrospect data" in these locations and deleting them: C:\ProgramData\Retrospect Client C:\Program Files (x86)\Retrospect C:\Program Files\Retrospect C:\Documents and Settings\All Users\Application Data\Retrospect Client Once everything has been cleaned and the "left-over" directories have been manually deleted, REBOOT, then reinstall the lastest client version again. One other thing to note. Retrospect (from the server) does not automatially remove the "old" client that you just removed from the computer. You have to manually remove it from Configure / Clients in the left side panel options. So once you've cleaned the client side and reinstalled and re-add it to the server, you'll actually have 2 instances of the same client - the old "bad" one, and the new "good" one. Should that happen, make sure you don't accidentally point your backup script and/or backup set to the old client instead of the new one (once you've rejoined it to the server), or you'll still get the error -530 backup client not found, because of course, it won't actually exist as it was removed.
  19. I personally think there is a memory leak with the application (just my opinion). We have several server instances of Retrospect and even the one that has 48GB of memory and 16CPU's will still have slow response times with Retrospect at times. Usually, after the applicatoin has been running for several days (which is absolutely amazing since it seems to crash all the time when grooming due to "corrupted catalog files" which also seem to happen all the time - sigh.....). I'm made it a habbit to shutdown and restart the application at least twice per week to keep it running more "cleanly" and that seems to have helped a bit. Now if only it would stop crashing during the automated grooming cycles and creating it's own vicious crash, catalog file corruption cycle....
  20. I see this problem repeatedly in my environment (also upgraded from 7.6 and currently using the latest version of 7.7) I even go through the process of repairing the catalog and am met with the "successfully completed message." In most case though, as soon as I try to view the backup set with the "repaired" catalog file, I am met, once again, by another message that the catalog file is still corrupt. How can it be corrupt if the new catalog file is created with only the data that it just built itself with after scanning the data sets? This happens propably 2-4 times a month in my environment. It's a vicious cycle because the catalog files get corrupt when retrospect crashes, but retrospect crashes trying to groom a backup set that has a corrupted catalog file and there always seems to be a corrupt catalog file somewhere down the line. I've given up. Basically, I end up just having to build a whole new backup set and hope that I don't have to recover from the old one. I keep the old one as per our retention policy (just in case, but it's really pointless) and as soon as possible, delete the old backup set to free up space on the SAN. Because catalog files are not reliable anymore, I've stopped grouping multiple systems into a single catalog file. It's not ideal to have a separate catalog file and backup set for each system, but at least when I run into this problem (which is frequent) I only lose the backup data for that one system, and not a bunch at one time. We're seriously considering a new backup solution such as CrashPlan, Acronis, or Backup Exec for clients. They are much more expensive, but sometimes, you get what you pay for.
  21. If you "forget" a drive, essentially, you remove the catalog file and it is no longer remembered. Technically, you should be able to still recreate the catalog file from your backup sets though. If you recycle the drive and then forget it, you lose the retrospect backup and the catalog file so there's no going back. My recommendation, would be to forget the system from your list of clients. Then readd it again. Nothing will change as far as your old data backups go. After you've readded the client, it should scan the drives and then you just point your backups to where they we're originally.
  22. What have you limited your backupset size to? If you've reached your backup set limit, it will ask you to create a new backup set If this happens while a backup is in progress, the backup set will be locked, so you won't be able to modify the current backup set. Your options are: 1) Create a new/second backup set which will be used in conjunction with the first one - this requires a new location/folder as you mentioned above. 2) Stop the current backup operation. Then expand your initial backup set to a larger size ((To check the size, double click your backup set, move to the members tab and then you can expand or shrink the amount of space dedicated to the backup set as needed). If you are using automated grooming, then it should be grooming up new space as needed and theoretically, you won't need a new backup set. However, if the Catalog file is corrupt, grooming won't work correctly. You may want to rebuild your backup set from disk to make sure it's a functional catalog file again and then look at expanding the backup set size if you have more space that you can dedicate to it.
  23. Yeah, if the catalog file is on the drive that died, then you're out of luck. Are you backing up the drive to itself? I'm assuming not! Wherever you primary data is being stored, make sure that you're backing it with Retrospect somewhere else. Also do the same with the catalog file so you have a safe copy of it too. You can create a new backup set on you external drive and have retrospect copy the catalog file from the internal drive there on a periodic basis to prevent this from happening in the future. Or, you can also use a a free tool that's incorporated with Windows called "robocopy"l. Basically create a short batch script that uses robocoy to make a duplicate of the catalog file from one location to another (that is not on the original disk). You can even "automate" the robocopy task it by setting it as a scheduled task in Windows.
  24. There should always be a catalog file. If both backups point to the same backup set, they will also use the same catalog file. Try searching your entire system for ".rbc" files and make sure you search in hidden and system folders as well - perhaps it got created elsehwere, although I don't know why that would be. Retrospect depends on the catalog files to determine what has been backed up and what has changed between the next backups
  • Create New...