Search the Community
Showing results for tags 'assertion failure'.
Found 2 results
infinitesunrise posted a topic in Server, SBS and Multi ServerSome background: I've got about a hundred HFS+ formatted external hard drives full of data that I'm transferring to LTO6 one at a time by attaching them to our OS X Yosemite server and sharing them all out under the same SMB share name ('Archive'). On the Retrospect side in Windows (Desktop v 10.0.2.119), I have an incremental backup script that pulls everything from the 'Archive' share. So I plug in a drive on OS X, share it out via SMB as 'Archive', back it up over the LAN with the script in Retrospect, unshare it, unplug it, and repeat with a new drive so that everything backed up all shows up under 'Archive' in the catalog. But I've been running into this error that crashes Retrospect completely, over and over again. The first drive I backed up was an 8TB and the backup got through about 7.5TB just fine. But on the last 300GB or so it kept seemingly running into files that would trip it up. It would throw up the error message 'Retrospect has encountered a serious error: Assertion failure at "elem.cpp-1145"; A log of this error has been written to the file "assert_log.utx".' I noticed that it always seemed to trip up on a large sequence of images that was on the drive, a different image file every time. I eventually zipped the entire folder of images on the drive, Retrospect had no problem chugging through the zip file, and the backup finished. I'm now on the second drive and it's happening again, but this time it looks like Retrospect's window disappears completely behind the error message, so I can't tell what file it hangs up on. Doesn't look like I have any choice but to just run the backup again, which means Retrospect has to spend hours figuring out which of the 2TB of files it's already backed up (I guess because the catalog file doesn't save correctly when it crashes?), and then it crashes the same way once it's a decent way through the new attempt at the backup. Obviously I cannot continue this way. I have literally hundreds of drives to work through and I was already expecting this to take a year or so. I absolutley have to find out why Retrospect is crashing, or I'm not going to be able to move all these archives off their hard drives. I don't know where the "assert_log.utx" that the error message mentions is located, otherwise I'd take a look at that for clues. I see that in the release notes of v 9.0.1.011 last year a mention that it fixes the "elem.cpp-1145" assertion failure I'm getting, but here I am running the latest version still getting it. Does anyone know what this means? Can anyone suggest any way to fix it? Thanks in advance for any guidance.
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