Assertion failure at elem.cpp-1096

[sowen222]

Sigh... it's that time of year again - time to clean up and archive backups - when I face major hassles with Retrospect. What should be relatively straight-forward, always turns into a multi-week drama where I question the reliability of Retrospect backups. Every year it's the same story, just different 'assertions' 😬

I have a backup set which contains weekly backups from the last two years - 2017 and 2018 - and I want to create new set (as a document archive) with only monthly snapshots and a selection of the directories/files from the original backup.

I'm using the latest version of Retrospect Desktop for Windows, version 15.6.1.104. My Windows 10 workstation is completely up to date.

Transferring the selected snapshots goes fine* for most of the snapshots from 2018, then I start getting assertion failures for various snapshots from 2017:

       Assertion failure at elem.cpp-1096
       LmGet: ndex = 2 > nsp->count = 1

I recreated the catalogue (which completed without error) but I still get the assertions during the snapshot transfer.

If I try to transfer just the problem snapshots to a completely new backup set, I get the same assertions. I've tried different copies of the source backup set (I have one on-site and two off-site), but they result in the same assertions.

I completely un-installed (including deleting the ProgramData\Retrospect directory), and re-installed, but I get the same error.

Any suggestions?

 

*Note: I write that transferring the selected snapshots goes fine, but even some of the transfers which are successful report missing files - odd, because the files (e.g. a cache file) weren't even in the backup in the first place, and I'm not trying to transfer them anyway. For example:

        [!] Exsp::exspBuildPartialFileSessionList: (OnSite) can not find node path "C:\...\GoogleEarth\dbCache1.dat" in session 2017.09.06 12:47:02.789 PM

 

 

 

 

 

[DavidHertzberg]

A search of the Forums doesn't show a report of an assertion with this particular number.  Here's why and how to file a Support Request.  If you just upgraded to Retrospect Windows 15 you may be entitled to personalized phone support, but I understand the European Retrospect Tech Support representative doesn't know very much.

[sowen222]

@DavidHertzberg Thanks for your reply, I was intending to update this post.

I had contacted Customer Support, and they suggested a 'thorough rebuild' of the catalogue... I think that option used to be available in previous versions of Retrospect, but now it appears you have to go into the Backup Set folder and delete all the ".session" files, then do a rebuild, at which point Retrospect does the thorough rebuild (instead of the usual quick rebuild). The Retrospect for Windows documentation has not been updated recently, because there the 'fast rebuild' as a check-box (Retrospect v12) is still documented, and there's nothing about deleting the '.session' files to force a thorough rebuild.

In any case, the rebuild detected broken chains in a number of files which had been backed-up in 2017 using block-level incremental, and it corrected the corresponding snapshot entries in the catalogue. After that, the transfer completed successfully.

A bit drastic that Retrospect just dies with 'assertions' and meaningless messages, rather than giving a meaningful description and recovering gracefully, but oh well :-/. Just glad I have my backup set corrected, and for safety's sake, I've turned block-level incremental off (in my case, it wasn't resulting in a huge space saving anyway).

[DavidHertzberg]

sowen222,

According to the head of Retrospect Tech Support, "Fast Catalog Rebuild is turned on by default with all Disk Backup Sets.  We don't have an option to turn it off/on because it is always enabled."  Again according to the same person, "The .session files help Retrospect perform faster catalog rebuilds. We made the changes to help cloud backup users with catalog rebuilds. [new paragraph] Retrospect will read these files during a rebuild process. If you want to perform a through rebuild, you can delete all .session files before catalog rebuild and Retrospect will create new .session files from the original backup set data."

I suggest that you file a Support Request,  specifying a Feature Request that a Thorough Catalog Rebuild option be added to the "Recreating a Disk Catalog" dialog that is now shown and discussed on pages 453-456 of the Retrospect Windows 15 User's Guide.  That option would delete all existing .session files and create new ones.  The code for doing that used to be the default for the operation up until Retrospect Windows 11.

 

 

[sowen222]

@DavidHertzberg Good idea - I've submitted the feature request.

...That said, I don't hold much hope out they'll implement it, as I've also repeatedly submitted bug reports over the years - FOR THE SAME BUGS - and although they are confirmed and escalated to engineering, they keep appearing, year after year.

 

 

[DavidHertzberg]

10 hours ago, sowen222 said:

@DavidHertzberg Good idea - I've submitted the feature request.

...That said, I don't hold much hope out they'll implement it, as I've also repeatedly submitted bug reports over the years - FOR THE SAME BUGS - and although they are confirmed and escalated to engineering, they keep appearing, year after year.

 

 

Add an Additional Note to your Support Case, containing links to this post and this post and this post.  You could also start a new thread in the Product Suggestions—Windows forum.

Fixing reported bugs is a different matter; the Retrospect Inc. engineers have historically been quite slow on that.  I think they need a course in modern debugging techniques, since IME their approach is to ask the administrator who reported the bug to run a test version with increased logging.