Mayoff Posted November 18, 2008 Report Share Posted November 18, 2008 As I have said in the forum before, for some users grooming never fails for others it seems to fail often. I use grooming at home and I have never had a problem. The bigger the backup set (lots of sessions, lots of .rdb files) the greater chance you may have trouble. I would highly recommend reviewing the best practices document section by section. This document suggestions will fix the problem for many users. If the problem continues, then you may need to try a strategy of snapshot transfers to new sets and recycle backups. http://kb.dantz.com/article.asp?article=9629&p=2 We are looking at grooming on the engineering side to make it more stable with large backup sets. Quote Link to comment Share on other sites More sharing options...
robvil Posted November 18, 2008 Report Share Posted November 18, 2008 hi, "We are looking at grooming on the engineering side to make it more stable with large backup sets" So you are saying there could be issues with grooming and not nessesary a hardware issue. And this is probobly what we are seeing here. But then again - what is big backup-sets. We have approx. 10 backup-sets with 1.2TB data and that is rearly not that many data in todays world. Is it! I have tried all suggestions in your link and nothing helps. From time to time we are getting corrupted catalog files and need to recreate those. "I use grooming at home and I have never had a problem" No, but do you backup 1Tb of data? Probobly not. EMC is marketing Retrospect as a small/medium size backup solution and I would expect Retrospect could handle my kind of setup. Actually I cannot see how the size of the backup-data has anything to do with small/medium size solution to do. Rather I would expect the product to have some limitations in functions compared to other interprise products, but not how many data it can "handle". The price for Retrospect Multiserver is actually much higher as a Veritas BackupExec single server and I have never had problems with D2D backups with BackupExec with the same amount of data or more. I know the 2 products does work different, but is it to much to ask for a product that actually works as promised? Retrospect is a great product with great features there is just some minor issues that need to be solved. Regards Robert Quote Link to comment Share on other sites More sharing options...
edbolson Posted November 19, 2008 Report Share Posted November 19, 2008 I did a Verify of the single "file" volume that had the grooming failure. It got over a million errors! I thought, oh no, the disk is bad! So I did a complete chkdsk and there were no errors (full chkdsk with scan for bad sectors). I looked at the log (took forever to come up because over 100 MB), and it appeared that all errors were "failure to communicate", but with files that do not exist in the folder for the volume. This, by the way, is a USB disk. Just to be clear, the sequence of steps was: 1) Recatalog - succeeded after several failures and a reboot. 2) Manually remove some snapshots, accepted the "Groom Now" option. 3) Grooming failed with Error -2241, catalog corrupt. 4) Verify showed over 1000000 errors, all apparently due to trying to access missing .rdb files (perhaps removed by grooming?) 5) Chkdsk shows no problems scanning entire disk. Anybody have further ideas? The backup set is currently about 500 GB, with about 200 GB free on a 750 GB disk. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted November 19, 2008 Author Report Share Posted November 19, 2008 The bigger the backup set (lots of sessions, lots of .rdb files) the greater chance you may have trouble. We are looking at grooming on the engineering side to make it more stable with large backup sets. The backup set I have problems with is 583GB and has 3.8 million files. One backup set that grooms fine has 4.99 million files. Another backup set that grooms fine ha 677GB of data. So I will not consider the problematic backup set as "large". And certainly not as "too large". In fact, it fails to groom even when it's quiet a bit smaller, after a recycle, before all clients are backed up the first time. My theory is that it's something with the contents (file name or whatever) that Retrospect isn't handling. Fine, when can we expect the results of this engineering effort? And will it be a free update? Send me a 750GB hard drive and I will send it back with my failing backup set for engineering to examine. Quote Link to comment Share on other sites More sharing options...
robvil Posted November 19, 2008 Report Share Posted November 19, 2008 they may have my data too... Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted December 8, 2008 Author Report Share Posted December 8, 2008 A week ago, the grooming suddenly worked. This last weekend it was back to error -2241. Sigh. And we haven't changed a thing, just let Retrospect do it's chores... Quote Link to comment Share on other sites More sharing options...
robvil Posted December 13, 2008 Report Share Posted December 13, 2008 Each and every time I groom the local backup servers backup I get: Script: Groom-Backup02-Server-backupset Date: 13-12-2008 Can't compress Catalog File for Backup Set BACKUP02, error -1 (unknown) Script: Groom-Backup02-Server-backupset Date: 13-12-2008 Grooming Backup Set BACKUP02 failed, error -2241 (Catalog File invalid/damaged) I am starting to spent more time on recreating catalog files and maintaining actual backup jobs. Robert Quote Link to comment Share on other sites More sharing options...
robvil Posted December 13, 2008 Report Share Posted December 13, 2008 Hi, I enabled debug logging and this is what I see: FEncEnd: not started ddskUpdateVol: catalog file size = 521.620.880 ddskUpdateVol: use disk space = 499.289.948.160, used in catalog = 221.396.189.184, free on volume = 3.435.688.985.200 grxLogFlush: segOffset: 25.270.509.568, segSize: 58.753.024 grxRequest: addr = 25.270.511.770, processing file 42, segment offset: 25.270.509.568, segment size 58.753.024 FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started ddskUpdateVol: catalog file size = 521.620.880 ddskUpdateVol: use disk space = 499.289.948.160, used in catalog = 221.396.189.184, free on volume = 3.435.688.985.200 grxLogFlush: deleting segment at offset 25.270.509.568 grxLogFlush: deleting segment 28 grxLogFlush: deleteAllSeg: 0, startLast: 24.012.220.570, physLast: 1.317.040.433, updateStart: 18.446.744.073.709.550.027 grxRequest: addr = 28.416.239.770, processing file 47, segment offset: 28.416.237.568, segment size 62.169.088 FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started FEncEnd: not started ddskUpdateVol: catalog file size = 521.620.880 ddskUpdateVol: use disk space = 499.289.948.160, used in catalog = 221.337.436.160, free on volume = 3.435.688.985.200 grxLogFlush: deleting segment at offset 28.416.237.568 grxLogFlush: found segment that was not groomed, error -1 (unknown), stop flush grxLogFlush: processed transactions 2, total transactions 253 grxReleaseSession: releasing session 13-11-2008 14:53:15,038 grxLogFlush: done flushing, result = 0 grxLogFlush: saving catalog, result = 0 grxLogFlush: done flushing grxLogFlush: saving snapshot: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) grxLogFlush: loading snapshot: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) grxLogFlush: updating snapshots: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) grxTask: flush log: 1,061 of 69,3 secs (1,53%) for 1 ops (1.061.000,0 uSec/op) grxTask: groom: 42,744 of 69,3 secs (61,67%) for 1 ops (42.744.000,0 uSec/op) grxTask: create log: 3,057 of 69,3 secs (4,41%) for 1 ops (3.057.000,0 uSec/op) grxTask: prepare: 22,199 of 69,3 secs (32,03%) for 1 ops (22.199.000,0 uSec/op) grxLogFlush: loading log file, incomplete = 1 grxLogFlush: open log file failed, error -1101 (file/directory not found) grxLogFlush: saving snapshot: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) grxLogFlush: loading snapshot: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) grxLogFlush: updating snapshots: 0,000 of 0,0 secs (0,00%) for 0 ops (0,0 uSec/op) enotProgEvent: 'MaiS'= 0, msg = Grooming Backup Set BACKUP02 failed, error -2241 (Catalog File invalid/damaged) Grooming Backup Set BACKUP02 failed, error -2241 (Catalog File invalid/damaged) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. enotProgEvent: 'MaiS'= 0, msg = Grooming Backup Set BACKUP02 failed, error -2241 (Catalog File invalid/damaged) enotProgEvent: 'MaiS'= 0, msg = Can't compress Catalog File for Backup Set BACKUP02, error -1 (unknown) Can't compress Catalog File for Backup Set BACKUP02, error -1 (unknown) 13-12-2008 14:49:11: 2 execution errors Duration: 00:01:08 (00:00:04 idle/loading/preparing) execEnd: triggered EndScript (successful), intervention text: "", command line: enotProgEvent: 'MaiS'= 0, msg = Script "Groom-Backup02-Server-backupset" completed with 2 errors Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted December 29, 2008 Author Report Share Posted December 29, 2008 It's getting tiresome getting the -2241 error every weekend (since we groom every weekend). What is error -2241? What causes it? Quote Link to comment Share on other sites More sharing options...
robvil Posted December 29, 2008 Report Share Posted December 29, 2008 Hi, I send support a email a couple of days ago and got the usual answer it´s was my hardware causing this. I replyed back that I was 100% sure it was not my hardware and I demand a better answer. Here is what I got: Please find the comment from our senior technical manager. "Grooming is not perfect. For some customers it works 100% of the time. For others it works 50% or less. For me, I will sometimes need to do 2 catalog rebuilds before I can finish a really big grooming operation. The larger the backup set, the greater the chance grooming will fail and require a catalog rebuild. For now, all we can do is suggest they try catalog rebuilds between grooming attempts until all needed data is groomed or switch to a strategy of recycle backups along with Snapshot Transfers to new sets. We will be looking at the grooming feature, but I don't expect bug fixes to happen until the next major release at the earliest. " Regards Robert Quote Link to comment Share on other sites More sharing options...
robertdana Posted May 18, 2009 Report Share Posted May 18, 2009 We're seeing this exact problem as well (I've confirmed it is not a disk corruption issue). Any update on a fix? -Robert 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.