8.0 (199) - Assertion failure during grooming

[qunet]

I manage some Retrospect backup sets with a size of about 14 TB. These are in use since Version 7.7. With December 2012 I changed to V8.0 - now the disaster:

 

The monthly grooming ended with Assertion failure at "grx.cpp-1089". Then Retrospect (running unattended) started again and retried finishing grooming and failed again. - So there was no script started for about some weeks - no error was reported (mailed). When I recognized this problem I tried to rebuild the catalog - seemed to work fine until the next backup-script started - when trying to update the catalog it complained: Error -1100 (invalid Handle) and ended with a corrupted catalog - this behavior is reproducible.

 

I tried to reproduce it with some ne (small) backup sets - created with V8.0 - it shows the same effect.

 

Up to now I trusted Retrospect and recommend it to my customers.

 

 

OS: Windows 7 version 6.1 (build 7601), Service Pack 1, (64 bit)

Application: C:\Program Files\Retrospect\Retrospect 8.0\Retrospect.exe, version 8.0.0 (199)

Exception occurred on 01.02.2013 at 18:03:54

Error info: Assertion failure at "grx.cpp-1089"

Exception code: E0000000 ASSERTION

Fault address: FD539E5D 0001:00008E5D KERNELBASE.dll

[Daniels]

^{An assertion error usually indicates a corrupt file. The best course of action would probably to do an un-install and re-install. I have not used Retrospect 8 however based on previous situations you should not lose your backup and/or scripts.}

[davekkk]

We had the same problem on several of our servers after upgrading to 8. Only way we could fix it was to make a new backup set. Recreating them still produced errors.

[Scillonian]

There is a known issue with Retrospect 8.0 when grooming Backup sets created with Retrospect 7.7. This will be fixed in Retrospect 8.1. See the following knowledge base article for more information:

 

http://kb.retrospect.com/articles/en_US/Retrospect_Article/grx-assert/?q=assert&l=en_US&fs=Search&pn=1

 

You will need to decide whether you want to run the per-release version or wait for the release version.