7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 26, 2011 Report Share Posted October 26, 2011 (edited) I'm encountering a number of backup set grooming failures, in the form of: Grooming Backup Set blerg... Groomed zero KB from Backup Set blerg. Grooming Backup Set blerg failed, error -1101 ( file/directory not found) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. Can't compress Catalog File for Backup Set blerg, error -1 ( unknown) In the past, to correct these issues, I've done the following: * create a backup set called blerg_copy * change the nightly script to use blerg_copy, not blerg * after a period of retention, remove blerg. However, these issues keep appearing. I believe they may be hardware related (issues with incomplete backups, forced hardware restarts), but I'm unsure how best to address these grooming failures. Is my above approach accurate? I have attempted a backup set transfer, but on a 500GB backup set, I encounter in excess of 11,000 errors in 6 hours of processing, so I cancelled the execution. Edited October 26, 2011 by glasnt Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted October 26, 2011 Report Share Posted October 26, 2011 You must recreate the Backup Set's Catalog File. Why don't you do just that? I have attempted a backup set transfer, but on a 500GB backup set, I encounter in excess of 11,000 errors in 6 hours of processing, so I cancelled the execution. Is that before or after the grooming fails? Which errors? Quote Link to comment Share on other sites More sharing options...
7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 26, 2011 Author Report Share Posted October 26, 2011 Why don't you do just that? I have recreated the catalogs multiple times, and the error still returns on the next groom. Is that before or after the grooming fails? Which errors? The errors I'm getting are along the lines of: Bad Backup Set header found (0xa600b000 at 875,243,022) Bad Backup Set header found (0x1b14fee0 at 875,265,796) Backup Set format inconsistency (7 at 1032409029) Bad Backup Set header found (0x5f6ef45b at 875,288,570) Bad Backup Set header found (0x40404040 at 875,290,194) Bad Backup Set header found (0x33577a4e at 875,291,814) Bad Backup Set header found (0xffffffff at 875,293,510) Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted October 27, 2011 Report Share Posted October 27, 2011 On what kind of media is the backup set stored? Internal drive, external drive, raid system, NAS, what? On what kind of media is the catalog file stored? Internal drive, external drive, raid system, NAS, what? How is a possible external drive connected? USB, Firewire, SCSI, optical, what? Quote Link to comment Share on other sites More sharing options...
7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 27, 2011 Author Report Share Posted October 27, 2011 On what kind of media is the backup set stored? Internal drive, external drive, raid system, NAS, what? On what kind of media is the catalog file stored? Internal drive, external drive, raid system, NAS, what? How is a possible external drive connected? USB, Firewire, SCSI, optical, what? Hardware RAID10 SATA drives, the newer machine has seperate RAID10 SAS for the OS drive; both machines are experiencing these issues, the older one more commonly (more backups on it, older, etc). First errors shown on machines around 2-3 months after they went into production. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted October 28, 2011 Report Share Posted October 28, 2011 The hardware seems OK. (Some users have just an external USB drive and USB isn't the most reliable connection.) Do you have a groom script scheduled? (We run grooming every weekend, for instance.) Otherwise grooming starts when the volume is full. And if you have the catalog file on the same volume, you are almost asking for trouble. The grooming process needs space to work with the catalog file. Quote Link to comment Share on other sites More sharing options...
7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 28, 2011 Author Report Share Posted October 28, 2011 (edited) The hardware seems OK. (Some users have just an external USB drive and USB isn't the most reliable connection.) Do you have a groom script scheduled? (We run grooming every weekend, for instance.) Otherwise grooming starts when the volume is full. And if you have the catalog file on the same volume, you are almost asking for trouble. The grooming process needs space to work with the catalog file. Grooming is weekly, Saturday morning, after the midnight -> 6am backups. Both OS drives have over 200GB of free space, so the catalogs have a fair bit of space to grow. There is a great number of backups being done though, might that cause an issue? Not sure of the exact data volumes, but these machines are backing up about ~70 servers, ~60 on one, ~10 on the other. Would it be prudent to load balance these backups, so that each server handles ~35 each? edit: to give a picture of how much these servers are processing, the backups from Monday morning (over the weekend) generated 523GB of new backups on one server, and 105GB on the other (going by the Completed: XX files, YY GB on the "Normal backup using <script>" part of the backup report.log file), grooming out about ~3TB of data between both machines. Also, I have rebuilt all the broken files (5) on one server; will see in the morning if any of the grooms fail. Edited October 28, 2011 by glasnt Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted October 28, 2011 Report Share Posted October 28, 2011 both machines are experiencing these issues Would it be prudent to load balance these backups, so that each server handles ~35 each? I don't think that would help. How many backup sets do you have? How many backups/transfers/grooming run at the same time? (I'm beginning to run out of ideas here. Maybe you should open a "support incident" with Roxio support? At the very bottom here: http://www.roxio.com/enu/products/retrospect/store/win-family.html ) Quote Link to comment Share on other sites More sharing options...
7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 30, 2011 Author Report Share Posted October 30, 2011 (edited) I don't think that would help. How many backup sets do you have? How many backups/transfers/grooming run at the same time? (I'm beginning to run out of ideas here. Maybe you should open a "support incident" with Roxio support? At the very bottom here: http://www.roxio.com/enu/products/retrospect/store/win-family.html ) Backup sets = ~70 (same number as clients) 8 execution threads, backups run from midnight to ~5am. The repair-catalog process did work, no grooms failed over the weekend; but I fear it will be a few weeks before they fail again. Is it usual in your experience to have to repair broken catalogs on a monthly basis? Also, do you know of any Performance Tuning documentation for Retrospect? Edited October 30, 2011 by glasnt Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted October 31, 2011 Report Share Posted October 31, 2011 Backup sets = ~70 (same number as clients) 8 execution threads, backups run from midnight to ~5am. The repair-catalog process did work, no grooms failed over the weekend; but I fear it will be a few weeks before they fail again. Is it usual in your experience to have to repair broken catalogs on a monthly basis? Also, do you know of any Performance Tuning documentation for Retrospect? Why do you have so many backup sets? I suggest you have at most 8, the same number as execution threads. Try to group the servers with similar contents, or at least group them that has the same OS version. One of Retrospect's strengths is that identical files are stored only once per backup set. So you will save disk space by reducing the number of backup sets. It happens here a few times per year that catalogs have to be reparied. We have 5 or 6 disk backup sets here. No, I don't know of any performance tuning documentation. Quote Link to comment Share on other sites More sharing options...
7e7ded5c-1194-4c60-bde8-107d31a92b2b Posted October 31, 2011 Author Report Share Posted October 31, 2011 Why do you have so many backup sets? I suggest you have at most 8, the same number as execution threads. Try to group the servers with similar contents, or at least group them that has the same OS version. One of Retrospect's strengths is that identical files are stored only once per backup set. So you will save disk space by reducing the number of backup sets. It happens here a few times per year that catalogs have to be reparied. We have 5 or 6 disk backup sets here. No, I don't know of any performance tuning documentation. Thanks for all your answers. I'll see if I can't put a few like-machines together to get retrospect to show me it's superpowers. Quote Link to comment Share on other sites More sharing options...
bvaandr Posted December 13, 2011 Report Share Posted December 13, 2011 Well - it appears I am not the only one and this is not just a Mac issue (Google grooming misery). My Retrospect for Windows Pro also has the -1101 error (file directory not found) after the backup set filled up and it tried to use the Retrospect defined policy for grooming. This particular backup set is for a single machine (Dell Win 7 64 with 8 GB Ram), single user with a local Firewire drive (MyBook). Catalog file is on the backup disk with the backup set, but there is plenty of room there - I have set the backup set size to leave at least 200 GB free on the drive. Rebuilding (recreating) catalog file took 4 hours for a 300 GB backup set , but was successful, according to log. However, subsequent groom ran all 931 segments - almost to completion, but then logged as failed (error -2242 (catalog file duplicated or ambiguous). So Retrospect cannot back up to it and asks me to rebuild it again. I have not had this issue with smaller backup sets when they fill up - perhaps it is a memory issue. 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.