Huge catalog file size

[kyeoh]

Hi, this is a suggestion for the development team for a situation I'm facing here.

 

I backup two computers which backup to two hard disks (each as a disk media set) which are rotated off-site. Each computer has 200-300GB of data on the hard drive. I therefore have 2 Retrospect catalog files (one for each backup set), each about 2.7 GB in size, and growing. In addition, I use Time Machine on each computer to keep local backups. And I also clone the hard drives periodically.

 

My problem is that I was looking around my Time Machine backup disk (using a hacked version of Grand Perspective, if anyone's interested) & noticed that TM has backed up multiple copies of the Retrospect catalog files.

 

That's good, because ever time a Retrospect backup is performed, the catalog file is changed. However, what's bad about this is that the whole 2.7GB catalog file is backed up after each Retrospect backup. The old copies are retained as per TM protocol, so at the moment a good chunk of my TM backup drive is taken up with multiple versions of these catalog files. See the attached screenshot where each large brown rectangle is a copy of a catalog file.

 

I don't imagine that 2.7GB worth of catalog file is modified each time Retrospect backs up, so why not store the catalog file as a container of smaller components instead? That way, after a backup, only the components containing the parts of the catalog file which have changed will need to be backed up by TM.

 

I was thinking this could maybe be done using a catalog package containing multiple smaller files. Or perhaps using a similar concept to a sparse disk image.

 

I'm no programmer, so maybe I'm talking rubbish here. Like I said earlier... just a suggestion

[fredturner]

I second your motion for tidying up the catalog files, if at all possible. I've noticed that the catalog files for Retro 8 are probably an order of magnitude greater than Retro 6 when backing up the same set of clients. But then again, EVERYTHING w/ Retro 8 seems larger than it needs to be: memory usage, CPU usage, catalogs, ...um, TIME usage.

 

For catalog examples, 2 of my redundant sets w/ Retro 6 were:

 

1.74 GB

1.90 GB

 

For Retro 8:

 

12.37 GB

15.95 GB

 

[Lennart_T]

But then again, EVERYTHING w/ Retro 8 seems larger than it needs to be: ... TIME usage.

I don't see any performance issues with 8.2 (compared to 6.1)

 

Back to the catalog files: Version 6.1 could not backup Windows clients (fully) and it could not backup ACLs. That adds to the metadata for each backed up file that is contained in the catalog file.