One of the things I’ve loved about Retrospect for Windows over the years is the ability to groom a backup set. Grooming is essentially taking the old data that doesn’t need to be in the set and removing it, providing there’s still a copy if the file is still resident on the source. I’ve always felt that for clients with Retrospect for Mac the lack of grooming left them at a serious disadvantage. Well, in Retrospect 8 the Mac should end up with this same feature. When you go to Scripts you can add a Utility Script. In this case, we’ll select Groom. You then check the box for each set you’d like to groom using this script and set a schedule.
Retrospect 8 Grooming
Next, you’ll want to go into your sets and configure a grooming policy. To do so, click on Media Sets and then click on the set you’d like to setup a grooming policy for and then click on the Options set tab. Here, you’ll see a little option there for No grooming (the default) or the number of backups to keep.
Retrospect 8 Grooming per Set
Basically, by telling Retrospect to retention 6 or 7 backups for a given set you are eliminating the need to do an occasional recycle script unless you just want to still use the same script architecture you used in previous versions. You can also tell a given set to use the global grooming policy. Overall I see grooming as a requirement for modern backup software and I’m glad to see that once Retrospect for Mac comes out of Beta that it will be a feature available to Mac admins. This feature alone will cut down considerably on complexity and annoyance for many organizations that I’ve seen over the past few years.
But grooming isn’t always the greatest thing ever. Keep in mind that it has a history of causing corrupt catalog files in the Windows version of the software. So make sure to backup your catalog files. Potential FUD disclosure: I’ve been running it for a few weeks with no problems on the Beta, but it would stand to reason that this could manifest itself on Mac OS X as well in Retrospect 8. Be careful stopping grooming scripts. These can cause your catalogs to require a rebuild (stands to reason they might be jacked up if you stop a stream of data writing to them). Also, if you’ve been doing file based sets then you’ll have to get away from this. Retrospect grooms disk based sets, not file based sets. Finally, don’t groom across disks. Use grooming on sets that only take up one disk…
Archive
3 Comments
I normally get these types of things, but I just can’t seem to figure out an example where grooming is useful.
The _only_ thing I can think of is if you are holding data that you must completely delete. (ex. – Customer data that the EULA says you will delete if they delete their account.)
Could you share an scenario where you would want to do grooming?
Thanks for the mention, Charles! We’re still working out some kinks with grooming, but it’s almost there. In fact, I’m building a Media Set right now to test grooming of real-world data sets with more than 10 million files.
Watch for Beta 5 early next week.
Cheers,
Eric
–
Eric Ullman
Director, Product Management
EMC Retrospect
http://www.retrospect.com
Grooming comes into play for us after backing up a large number of pcs and servers to a few backup sets using the normal backup. The normal backup over time will cause the backup sets to grow pretty large and fill our 8 terabyte backup drive. Grooming greatly reduces the size of these large backup sets without having to to frequent recycles (starting the entire backup from scratch). We have run into problems with corrupt catalog files after grooming and are trying to control this a bit by splitting up our backup sets to handle a smaller number of pcs each. So if you do decide to groom be ready to rebuild your catalog files, which for us take the good part of a day.