Is grooming working in 10.1?

[amkassir]

I usually groom two media sets each week. Each time I groom them with the Retrospect-defined policy, Retrospect frees up about 2-3 GB.

 

Today I groomed my two media sets using Retrospect 10.1, and both times the log shows 0 bytes groomed:

 

+ Executing Groom OWC Backup at 3/21/13

Grooming Media Set OWC Backup...

Groomed 0 B from Media Set OWC Backup.

3/21/13 3:31:35 PM: Execution completed successfully

Duration: 02:36:29

 

+ Executing Groom iMac HD Backup at 3/21/13

Grooming Media Set iMac HD Backup...

Groomed 0 B from Media Set iMac HD Backup.

3/21/13 7:22:16 PM: Execution completed successfully

Duration: 01:38:07

 

Is grooming working for you? Any idea why nothing was groomed from my media sets this time? This is the first time I used 10.1 to groom.

 

Thanks for any responses.

[Maser]

I have not used the 10.1 GM for grooming yet (I will do so this weekend), but I was able to use the 10.1 beta with minor issues (sometimes I had to rebuild my catalogs before they could be groomed correctly -- but the log throws up an error when this happens.)

 

I am not using the defined policy, though -- I keep a specific number of backups for each client in the media set.

[BDMSTUDIOS]

I have not used the 10.1 GM for grooming yet (I will do so this weekend), but I was able to use the 10.1 beta with minor issues (sometimes I had to rebuild my catalogs before they could be groomed correctly -- but the log throws up an error when this happens.)

 

I am not using the defined policy, though -- I keep a specific number of backups for each client in the media set.

 

Good idea, thanks for posting.

[kswisher]

I had a positive experience with grooming with Version 10.1.0 (221) and grooming. I have been fighting with a media set that keeps hanging retrospect when groomed (defined policy), After the latest of many attempts to groom/hang/stop engine/delete catalog/re-build catalog episode using 10.0, I upgraded to 10.1.0 (221), re-built the catalog then performed groom. For the first time in months, the groom completed succesfully.

[David W Lee]

I usually groom two media sets each week...

Any idea why nothing was groomed from my media sets this time? This is the first time I used 10.1 to groom.

 

Is it possible that since prior groom no additional files in the media sets have fallen out of the grooming policy:

Retrospect’s default policy retains two backups for each source, saving the last backup of the day for each source from the two most recent days on which each source was backed up. Given enough space in the Media Set, Retrospect keeps a backup of each source for every day in the last week, a backup for each week in the last month, and a backup for each previous month.

[amkassir]

Thanks David.

[Maser]

So, my report: I groomed 3 media sets with the 10.1 GM over the weekend. Two worked as expected. One of them (which I groom every week), reported I had to rebuild the catalog file.

 

I rebuilt the catalog file and the subsequent groom worked. (I'm currently logging things to see if I can reproduce this one...)

[amkassir]

Thanks for the report, Maser. Subsequent grooms for me have worked, in that a certain number of GB were groomed from the Media Sets. One set I rebuilt the catalog file (without being asked to do so), and the other I didn't. Anyway, seems to be working smoothly now.

[twickland]

Here is another data point with no happy conclusion as yet.

 

I have a disk media set that spans two volumes/members. (Admittedly, probably not the best idea, since I suspect that any space that is freed on the first volume will effectively be wasted.) I attempted to groom the media set, which worked fine on the first member but then choked on the second with the dreaded error message "The Backup Set member "2-XXX is corrupt or has data from another set." I rebuilt the catalog, ran a second groom operation, and again got the error and a failed groom when the grooming reached the second member.

 

I suspect this failure may be occurring because Retrospect has flagged four data files on this member as being damaged. It did this by creating a folder "DamagedFiles" at the root level of the volume where the "Retrospect" data folder resides and placing aliases to the presumably-damaged files. This DamagedFiles folder existed before the catalog rebuild, and during the rebuild Retrospect noted that four files (presumably the four previously flagged) had bad media set headers. One would think (hope?) that Retrospect would take note of and use the information in the DamagedFiles folder for all of its operations, so it would be disappointing if this was indeed the reason for the failed grooming.