Retrospect 8.2 is dangerous

[ernst_mulder]

Hello.

 

I have a couple of clients running Retrospect 8.2. We are experiencing quite a number of issues and I would like to have a solution. Retrospect 8.2 is supposed to keep customers safe, instead it's an almost guaranteed path towards data loss. Not all of my customers have an ASM by the way.

 

Scripts keep forgetting their settings. For instance:

• Today one of our customer's scripts forgot which Media Sets to backup to. Last Friday everything was fine, this morning they were not selected anymore. When checking the rest of the scripts various settings were gone as well, for instance "Use attribute modification date when matching" was selected again.
  
• After a power surge, where the machine running a Retrospect server was affected, we had to recover one of the disks used as a Media Set using DiskWarrior. This led Retrospect to suddenly select AN ENTIRELY DIFFERENT drive as its destination in the script that used to use the recovered drive. If I hadn't caught this that drive would have been overwritten when running the script.
  

 

Retrospect can't keep itself running. For instance:

• The Retrospect server part crashes and is not automatically rebooted. The server part is started using a launchd plist but KeepAlive is not used.
  
• Retrospect Clients do not time-out their connection. This happens for instance when backing up over the internet. If a connection is lost the Retrospect Client is still "in use" and does never recover. Manual intervention is necessary to restart the Retrospect Client.
  

 

The user interface is dangerous. For instance:

• On a system where the Retrospect console application is installed anyone can change scripts and settings. Script settings should be password protected or at least acknowledged and the console application should be password protected.
  
• When (This one really bugs me!) controlling multiple backup setups remotely using the Retrospect console application, the application loses track of what settings belongs to which server address. Scripts from one server are suddenly visible on another server. Media sets from one situation are suddenly visible at another server. This is really scary, and may even be the cause of other issues we're experiencing. I would like to monitor the backup status of my clients, so I have multiple servers configured in a Retrospect console application on my workstation.
  
• The user interface has scary warning messages, some of which are not even correct. For instance: when selecting "Overwrite entire volume" the warning "Warning: Destination will be erased before copying." is given, which is not true. Also when running that script the warning "Are you sure you want to erase the entire source before copying?" is given at which point most of my users bail out because they have no idea that the "Source" in this case is actually the "Destination", just as in the first warning.
  

[Lennart_T]

I have a couple of clients running Retrospect 8.2. We are experiencing quite a number of issues and I would like to have a solution. Retrospect 8.2 is supposed to keep customers safe, instead it's an almost guaranteed path towards data loss. Not all of my customers have an ASM by the way.

There will be no more releases of Retrospect 8. No bug fixes, nothing.

 

Retrospect 9 is a free upgrade for customers having an ASM. If not, there is an upgrade fee.

 

 

 

After a power surge, where the machine running a Retrospect server was affected, we had to recover one of the disks used as a Media Set using DiskWarrior. This led Retrospect to suddenly select AN ENTIRELY DIFFERENT drive as its destination in the script that used to use the recovered drive. If I hadn't caught this that drive would have been overwritten when running the script.

I doubt that is the whole story. Retrospect goes a long way to distinguish different volumes from each other. That's why it didn't use the volume that DiskWarrior reconstructed. So I have strong feeling that an operator (in error) pointed out the wrong volume in a "waiting for media" dialog.

 

 

 

The user interface has scary warning messages, some of which are not even correct. For instance: when selecting "Overwrite entire volume" the warning "Warning: Destination will be erased before copying." is given, which is not true. Also when running that script the warning "Are you sure you want to erase the entire source before copying?" is given at which point most of my users bail out because they have no idea that the "Source" in this case is actually the "Destination", just as in the first warning.

Right, the wording of some messages have been a long standing issue.

 

That said, I have never encounterred any of the other issues you have.

If you can reproduce them in Retrospect 9, and produce a step-by-step instruction on how to do that, I'm sure Retrospect would like to hear from you and fix the bugs.

[ernst_mulder]

Re: The user interface is dangerous

 

Here is an example where Retrospect mixing up scripts, showing the scripts of one backup server with another:

 

Wrong:

http://mulder-thuis.nl/retrospect/screenshot4.png

(the scripts mentioning "bobine" are actually from the backup server called "bondi")

 

Right (after stopping and starting the console app):

http://mulder-thuis.nl/retrospect/screenshot5.png

 

I am wondering if this phenomenon can be the reason why settings of scripts keep changing themselves.

[2927aa2c-bcad-4982-b785-6b9ccc007482]

I've experienced the same weird problems as Ernst. Scripts suddenly deciding to use another media set or source (this could only be resolved by deleting that script and creating a new one), a complete inability to set the start time for a script e.g. I change it to 9am, the control loses focus, it changes to 3pm etc. Automatic grooming never seems to happen for me - the media set fills up and then asks for more. Manual grooming doesn't reduce the number of backups and hence barely reduces the media set usage.

 

Ernst, I created a cron job which keeps the Retrospect server alive. I had to do this since every time I went on holiday, the server crashed and I had a nightmare awaiting me on return. If the backups fail, it's my responsibility. All of the bugs also make me look foolish; I can't just keep blaming the buggy software, as true as that may be.

[ernst_mulder]

Today it happened - again- right under my nose. I was editing a script on server A. Suddenly some of the scripts of server B were also visible between server A's scripts. After quitting the console app and starting it again one of the scripts of server B was modified, schedule gone, selector gone. I'm sorry but this is not a working product.

[darthtom]

Ernst -- I just wanted to confirm that I have personally experienced every single bug you mentioned with our own in-house backup server, which I administer. (However, I stopped having the problems with the engine crashing quite a while ago -- are you certain that an engine update isn't available?)

 

The "loss of script settings," particularly of Media Sets and schedules, is particularly egregious, and often goes a day or two without getting noticed.

 

However, I would like to share that I have been running the demo of Retrospect 9 for about 2 weeks with zero problems. The console seems a bit slower to me, actually, but it has been running with much greater consistency.

 

Company's been using Retrospect since long before I started here -- when I first started coming in part time as a high schooler, I took over running a Retrospect 6 server running on a Blue and White G3. That was the most rock solid, reliable backup solution I've ever administered. Retrospect 9 is getting back there...

[Don Lee]

Retrospect 9 is much improved. I recommend it.