johnnymacgo Posted April 6, 2011 Report Share Posted April 6, 2011 Hi, I'm running Retrospect Multi Server V7.7.325 64-bit in a fairly complex enviroment doing disk to disk to tape backups. My config77.dat gets corrupt every few months or so. The symptom is that backing up a remote client (usally a random one) hangs while scanning it. I worked with Retrospect support a while ago on this and they found that the configuation file was hosed. If I create a new one and reconfigure everything from scratch (takes about 3-4 hours) then the remote client backs up fine. I have ended up shutting down Retrospect every week or so to make a backup of the config77.dat but what I find is when I use that backed up config77.dat and then put back all the the changes made since the last backup the file ends up getting corrupt again in a matter of weeks. I have traced down the problem to adding new remote clients. If I add a new client and then add that client to a backup script, one random client in that script will hang during scanning later on, sometimes the same day, sometimes days later. This problem is not specific to hardware since it happened on two totally different servers and clients. I don't really want to update to V7.7.5XX since I've read about alot of new different bugs with that version. My question is, Is Retrospect Engineering working on a fix for this issue? Is it even on their bug lists? I know lots of other people have reported problems with configuration file corruption as well. Thanks, Johnny Mac Quote Link to comment Share on other sites More sharing options...
008e3f8f-ac2d-4494-8f82-24d5c4ae8d5b Posted April 7, 2011 Report Share Posted April 7, 2011 While I don't want to deny your claims of config file corruption (it obviously is an issue for you) I don't have this problem at all (knock on wood). We use the same version and also do d2d2t. Do you use any Retrospect optional modules? You are aware there is always a backup copy of the config file available? It resides in the same directory as the config file, has the same filename with the extension "bak". To use it, you have to rename the extension to "dat", thus replacing the corrupt config file. Btw, it makes a lot of sense to make backups of Retrospect's own files as well. In case of a major malfunction setting up an installation can be quite time consuming. Quote Link to comment Share on other sites More sharing options...
johnnymacgo Posted April 11, 2011 Author Report Share Posted April 11, 2011 We do not have any optional Retrospect modules installed. I don't think this is really an issue with d2d2t but more likley how many remote clients we are backing up and the fact the those clients change fairly often so we keep on having to delete old clients and add new ones. Thats what seems to cause the corruption. I am aware of the backup copy of the config file and like I said I do use backup copies of the config file already but even the backup copies seem to get corrupt over time. I just rebuilt the Retrospect config today and it ended up taking up a good part of the day :-( If this was a once in a blue moon type of thing it wouldn't be too bad but the file seems to get corrupt after about 3 months or so. Quote Link to comment Share on other sites More sharing options...
008e3f8f-ac2d-4494-8f82-24d5c4ae8d5b Posted April 12, 2011 Report Share Posted April 12, 2011 In any case, it's not normal for the config to get corrupted. We rarely see that happen here on our installations of Retrospect... How many is 'many remote clients'? B.t.w. after configuration changes we usually quit Retrospect and restart the application again to make sure it writes the changes to the config file. This is something we have been doing for years so it became kind of a ritual, but so far it worked for us. Quote Link to comment Share on other sites More sharing options...
johnnymacgo Posted April 13, 2011 Author Report Share Posted April 13, 2011 We have about 40 remote clients including some Mac's and servers. I also quit Retrospect after configuration changes and make backup copies of the config file and do sometimes go back to those backup configuration files. The issue with that is even that backed up configuration file starts to go bad after running on it and it gets to a point where I can't make any more configuration changes unless I wipe it out and start over again. I'm just hoping that engineering is working on a fix to this. There is more stored in the config77.dat file besides configuration information. I believe script history is also stored in it. Thats why the file gets bigger over time even when no configuration changes have been made to it. Maybe if they took all the non configuration information out of the file it wouldn't get corrupt so often? Thats just an idea... Quote Link to comment Share on other sites More sharing options...
44290d03-aceb-46b8-b75a-a98a8728ccb9 Posted September 11, 2011 Report Share Posted September 11, 2011 I just experienced this, and when I went into the folder containing config77.dat/bak, the two had the same dates, the day the problem occurred. Symptomatically, when I restarted Retrospect to check previous night's backups, it was blank, asking me for a license code. What a mess. I had made NO changes to any configurations, had neither installed nor removed software; I'd simply rebooted the server because RichCopy had gotten stuck on a process copying to Amazon S3. The alst time I'd made any changes to the Retrospect config was weeks bofore, simply creating a new backup script. Quote Link to comment Share on other sites More sharing options...
fulcostiva Posted September 13, 2011 Report Share Posted September 13, 2011 A damagedconfig file is an long-standing Retrospect problem. For manyyears Retrospect users are requesting a better, more stable configurationsystem. In the‘old’ forum this was discussed many times. PersonallyI don’t understand why they still use this ‘monolith’ config.dat file. Quote Link to comment Share on other sites More sharing options...
fulcostiva Posted September 21, 2011 Report Share Posted September 21, 2011 (edited) Please Roxio, change the way Retrospect save's is Preferences to a 'portable' system. For example use XML file!!! Fulco Edited September 21, 2011 by Fulco Quote Link to comment Share on other sites More sharing options...
Richy_Boy Posted September 27, 2011 Report Share Posted September 27, 2011 (edited) I agree, we used to get this A LOT. However, since moving to a new backup server, running soley on SSD disks I haven't seen it once. I do religiously backup the RS config files every night, as having been through the pain of starting from scratch a few times now, I'd rather not do it again! There's lots of stuff that RS does which is 'old school', years of under resourcing has lead to that.. Rich Edited September 27, 2011 by Richy_Boy Quote Link to comment Share on other sites More sharing options...
blm14 Posted November 11, 2011 Report Share Posted November 11, 2011 retrospect staff is aware of this problem. I called them yesterday to gripe about it AGAIN. My solution to this is to have a proactive backup job that backs up the C:\ProgramData\retrospect folder ITSELF once a day. So I can always just restore the settings from a clean "empty" retrospect application, quit out, and recover. Although I have to admit it's been a VERY VERY long time since I've had any corruption in that config file Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.