To compress or not to compress?

[Carillon]

That is my question. I have a Media Set that is a little over 2 TB and the Catalog is 21GB. Currently I don't have the checkbox selected for Keep the Catalog Compressed. I'd like to hear from others who have used compression if it worked okay before I do it. Thanks

[rhwalker]

It works fine, but it can take a GREAT lot of time at the end of each backup session.

 

You might consider, as an alternative, the approach that we have always used: Keep the catalog uncompressed while the media set is active, then compress it after the media set is closed (no longer being updated).

 

Of course, we never recycle our tape media sets, and just use them until they fill (multiple members, though).

 

If you are reusing your media sets, and/or grooming them, your issues are different from ours.

 

The issue is not so much the size of the media set, but the number of snapshots in the catalog. Your media set size (2 TB) is not all that big.

 

Russ

[Maser]

All my media sets have compression on them. Yes, it can take a good deal of time to recompress the catalogs after you do something like rebuild a really large one (I have a 50G uncompressed catalog that usually takes about 60-90 minutes to fully compress down to 12G after a recatalog).

 

But I usually have no problems working with compressed catalog files for backup/restore/grooming, etc. As long as there aren't any "bad headers" in the *members*, working with compressed catalog files is fine.

 

 

[Carillon]

Thanks Russ, it sounds like I'll leave it alone. This Media Set will continue to grow upwards of 4 TB. I am grooming it at 10 backups to keep.

 

Related to Grooming, is there any documentation that I can read that explains how Grooming works exactly. I'm a little concerned that it may delete files that are still needed... i.e. still on the client machine but just not accessed in a while.

 

Thanks

[rhwalker]

Related to Grooming, is there any documentation that I can read that explains how Grooming works exactly. I'm a little concerned that it may delete files that are still needed... i.e. still on the client machine but just not accessed in a while.

Here is what there is in the absence of a manual:

 

What is grooming and how does it work?

What are the best practices for using grooming?

How do I rebuild the catalog after grooming fails?

Grooming keeps failing with a Catalog Damaged error. How do I fix it?

 

There are also these two definitions from the Knowledge Base glossary:

 

Defined Grooming Policy

 

Used for Disk Backup Sets. When the backup drive fills up, Retrospect uses its own grooming policy to delete old backups. At a minimum, Retrospect’s policy retains two backups for each source. Retrospect keeps the last backup of the day for each source from the two most recent days on which each source was backed up. If the disk has enough space available, 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.

Grooming

 

An option for disk Backup Sets. If you set a grooming policy for a disk Backup Set, Retrospect automatically deletes older and folders from the disk when it runs out of disk space, in order to save newer files and folders. See http://kb.dantz.com/article.asp?article=9629&p=2

And, of course, there's my post in another thread, explaining how it is supposed to work, which you can take with a grain of salt:

Snapshots and grooming with the Retrospect paradigm

 

Russ

[Carillon]

Thanks Russ, I appreciate you putting this together. I was able to read everything except the first group of links didn't work. The other info was very helpful!

[rhwalker]

I was able to read everything except the first group of links didn't work.

Odd. Let's try it a different way for those links. Interestingly, two of the articles were the same, so there are only 3 links:

 

http://kb.dantz.com/article.asp?article=8146&p=2

 

http://kb.dantz.com/article.asp?article=9629&p=2

 

http://kb.dantz.com/article.asp?article=8350&p=2

 

Note that these are Retrospect 7 for Windows articles, which has documentation. However, the concept is the same, and Retrospect 8 is based largely on the Windows code base, not on the Retrospect 6 for Mac code base.

 

Russ

[Maser]

But, to answer your question: If a file is in a recent "snapshot" -- even if you groom everything but the last backup -- you still will retain that file for backing up.

 

I tested this before I did any grooming. You'd have to delete *all* past backups to get rid of files.

 

So "untouched" files should always be restorable when you groom things.

 

What (in your case as an example) would not be restorable would be the 11th version of a file that changes every time you backup if you are only keeping 10 past backups per client.

 

But if you have one file that has never been changed since the first backup, you'll still be able to restore it even if you groomed out the 11th (and older) past backups -- as long as it is still on the hard disk.

 

However, if you removed that file from your source *today*, did 11 more backups and then ran a groom -- then the file will be gone from the media set.