Jump to content

Compression does not work as expected

Recommended Posts

Retro 10.2.0 (221) engine on Mac OS X 10.8.4 on a Mac Mini.


I have been having trouble with media set copies, and so have been very watchful of the operations that I do to ensure that the output is sound.


I had a small media set, about 7.8 GB, we'll call it orig. I copied it to arch, with compression enabled in the script. The resultant media set was 2.2 GB, but had the requisite 203 files.  I wanted to verify that the 2.2 GB was "enough" by running a script *without* compression enabled to "re-inflate" the data.


I copied the copy to "zjunk" without compression, and the result had 203 files, and 2.2 GB.


I then tried resetting zjunk, and copying orig to zjunk, which resulted in 7.8 GB and 203 files.


I then tried copying arch (compressed) on top of the files already in zjunk, with options un-checked so that no duplicate elimination was done.  The resulting zjunk was 406 files and 9.9 GB.


It appears that "compression" is a one-way operation on media sets.  un-checking the "compress" option in the script will NOT un-compress the resultant copy.  It also appears that compressed, and un-compressed data can be "mixed" in a given media set. The media sets, therefore, have no "compress attribute".


Is this as it should be?


It would be nice to get more information on the compression.  There are a few places where "amount saved" is put in the logs, but when estimating the amount of space/tape that will be required, that compression performance data can be really useful.

Link to comment
Share on other sites

  • 3 weeks later...

Correct, compression is a script option and not a backup set option. Aside from both Proactive and regular backup scripts, compression is also an option for Copy Media Set and Copy Backup scripts, so you could compress a previously uncompressed backup during transfer. As you have seen, it is a one way option.


True, it would be nice to have a better estimate on what the data will compress to but, unfortunately, this is very dependent on the type of data. Effectively, the more random the data, the less it compresses and many data types, such as JPEG, are already compressed and so do not compress further.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...