TERRYRICKETTS

You can backup shares on a NAS device without needing to install a client. Go to 'Volumes' under 'Configure' and select 'My Network Places'. Then navigate to the share you want to backup. Once you have the share listed in the 'Volumes' list you can create a script selecting the share from the list as the source. If your shares are very large you might want to take advantage of Retrospect's ability to do multiple backups at once by creating multiple backup sets and scripts to access them. This might depend on how much data changes each day. In our case we had a NetAPP appliance with over 30TB and over 30 shares. I divided the shares into three groups and backed each group up to a separate backup set. That way I was able to run three scripts at once to backup the data quicker. One thing you need to be careful of is if your NAS makes its own snapshots on a regular schedule. With our NetApp I had to create a script that ran before the backup to turn off the snapshot viewing, and one to turn the snapshots back on when the backup finished. Otherwise the backup would contain multiple copies of the same files from the snapshots.

We have two Win 2008 servers; both running Retrospect 10.5.0.110 MultiServer. Recently I did a windows update on both servers. One of the servers, after rebooting and restarting Retrospect comes up with an error message asking for the original password for Privkey.dat to unencrypt the list of clients and backup sets. The Privkey and Pubkey were created over 10 years ago by a former admin. There is no record of what password he might have used. The other server came back up and is working normally. I do not know why the Windows Update affected one server and not the other, or what file was damaged that Retrospect can't see all the clients. I have tried restoring the ProgramData folder from a backup with no success, and even copied the privkey and pubkey files from the machine that is working. The number of clients and backup sets is rather large and will take days to recreate. Does anyone know how to fix this problem?

On our network we do not allow wireless clients a lan connection. They are only allowed to go to the internet. Wireless is not considered safe enough to allow access. So ... to answer your question any machine that wants to be backed up must plug into a wall port. Laptops normally do this with a docking station. So it is easy for them to just close the cover and pick the laptop up to leave.

We have much the same setup except that we have the multi-server version. We have the same problem with users closing their laptop to go to a meeting while a backup is happening. I usually need to wait until other backups are finished and the server is quiet before using Task Manager to force Retrospect to shut down. Then when I restart I need to repair the catalogs for the backups that hung.

It appears that the workstations that were updated connect ok after they have been rebooted. Since most users turn their machines off at night this has fixed most of them. There may still be a few that leave the machine on all the time that I will not find until they complain that they are not being backed up. I have directed our help desk folks to not install the new client on new machines until we have a better idea what is going on.

Having just updated our two Retrospect servers to 10.0.0.213 I asked one of the servers to push out the client update from the rcu file (10_0_0_212). Much to my horror all of our servers (and I am guessing at this point most of our clients) no longer responded. I discovered that in every server the Retrospect Client had been turned OFF! I just spent the entire morning connecting to each server where i had to manually turn the client service back on. I dread the thought of finding all the workstations that were affected. The log said 120 of them were updated. There is a major bug in the rcu file. Do not try to use it!

I have been having a lot of problems with the latest version of Retrospect (9.5.3.103) hanging up when a user abruptly disconnects from the network. This problem does not stop Retrospect from running other backups on other backup sets. But it will block all future connections to that backup set. We have a lot of users that now use laptops, and they usually do not pay attention to if their machine is being backed up when closing the machine to go to a meeting. About 3-4 times a week I will have this happen, and my only indication that something is wrong is by noticing that there seems to be no activity on a backup. If I try to stop the backup that execution will turn grey but it will never stop. I usually have to wait until all the other backups have stopped for a short time and then try to shutdown Retrospect. In each case the program will ask me if I really want to shut down and then if I want to stop all proactive backups. After responding to those requests the program simply hangs. I think it is waiting for the execution it thinks is running to stop. My only recourse at this point is to have Task Manager force-ably shutdown the Retrospect process. I usually have to repair the catalog file for the backup set that caused the problem when I restart. Lately I have been noticing on weekends when I do some grooming that Retrospect will not allow access to multiple backup sets because it thinks they are open for some other operation, even though nothing is showing in the 'Executing' window. It would appear that the program did notice the computer went away, but still kept the connection to the backup set open. When this happens Retrospect will refuse to shutdown and I again have to resort to the Task Manager to clear up the problem. I have no control over what users are doing with their laptops; so I need to have Retrospect be a little more forgiving when a machine disappears in the middle of a backup. It also needs an option to force-ably close processes it thinks are running when shutting down.

VirusTotal - Results.pdf We checked the file 'cntdown.exe' with 50 different antivirus programs. of them only Symantec flagged the file as a virus. See the attached file

Here are the appropriate errors from the logs for 5 of the grooms that ran last weekend: Grooming Backup Set Workstations H failed, error -2241 ( Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. Can't compress Catalog File for Backup Set Workstations H, error -1 ( unknown) 11/15/2014 3:52:41 PM: 2 execution errors Duration: 02:20:58 (00:25:52 idle/loading/preparing) 11/15/2014 3:52:41 PM: Script "Groom Workstations H" completed with 2 errors Grooming Backup Set Workstations E-F failed, error -2241 ( Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. 11/14/2014 7:07:21 PM: Execution incomplete Duration: 02:37:29 (00:46:28 idle/loading/preparing) Grooming Backup Set Workstations W-Z failed, error -2241 ( Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. 11/15/2014 3:13:48 PM: Execution incomplete Grooming Backup Set Workstations T-V failed, error -2241 ( Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. 11/15/2014 3:48:20 PM: Execution incomplete Duration: 02:01:13 (00:37:52 idle/loading/preparing) Grooming Backup Set Workstations S2 failed, error -2241 ( Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. 11/15/2014 2:28:12 PM: Execution incomplete Duration: 00:46:38 (00:22:04 idle/loading/preparing) The catalog files were fine prior to the grooming, and there were no complaints while the data was being groomed. Somehow at the end when the catalog file itself needed to be cleaned up it had a problem.

An update on our situation. The file name is 'cntdown.exe'. When an exception was added to the Symantec list for that file name the problem went away. We were seeing the flag from Symantec close to 40 times an hour. Now there are none. Also within an hour of the exception being added we had 32 machines respond to Proactive and backup.

We are running Retrospect 9.5.2.103 on two servers. For our workstations we presently have 21 backup sets. Each backup set is slightly over 1TB in size. They are all stored on a Dell PowerVault that is attached to the servers via scsi. Several times a month we need to groom the backup sets to gain enough room for the next weeks backups. Generally about half of the grooming jobs will fail; all at the same spot. That spot is just after the data has been removed and the catalog file is about to be adjusted. A check of the backup set always shows the data to be fine, and the error message tells us we need to rebuild the catalog file. In each case I will have the server rebuild the catalog file. Then to be sure everything is ok I will copy that backup set to a temporary store on a local NAS, and then copy it back. We never have a problem with rebuilding the catalog file, or the double copy. But the next time we groom about half of the jobs will fail again!

it would be very nice if when trying to groom out snapshots for machines that no longer exist if we could select more than one at a time. This is a task I need to do every month as people get new workstations. Sometimes there will be 20-30 snapshots that need to be groomed and I presently have to do them one at a time.

We are running Retrospect multi-Server 9.5.2.103 on two WIndows Server 2008 R2 64 bit servers. Most of our clients have been recently updated to version 9.5.0.134.4. In the last week our Symantec AntiVirus server started flagging a Retrospect file named 'cntdwn.exe' (or something close to that) on almost every workstation as a virus and started quarantining the files. About the same time the Proactive backups stopped finding any machine to backup. We can still manually backup machines, and I have had to resort to writing scripts to manually do all the machines in each backup set. Symantec claims they are not flagging anything. Are we going to have to reinstall the client on every machine to clean this up? That will be over 500 machines. Recently a couple of the machines had the client removed and reinstalled. We then had to tell the server to forget the machine and then re-add it before it would recognize the client. This is becoming a major time sink and a hassle. Has anyone else run into this problem?

Thanks for the quick fix. That seems to have solved the problem for me!

I am running into the same problem updating clients. Here is the information on our system: Retrospect server running on Windows Server 2008 R2 Standard Server software: Multi Server Version 9.5.1.107 Client software: 9.0.0 (187) Update file: Win_Client_Update_9_5_0_139.rcu Some machines update just fine, while others just respond with "error -1 (unknown)". Workstations are almost all Win 7, while servers are either Win Server 2008 or Win Server 2012.