Jump to content

SW compression is flaky


Recommended Posts

I'm using Retrospect Desktop 4.3 under MacOS 9.2.2, storing into an OnStream SC30e tape drive. I'm having trouble getting software compression to function reliably. It seems that in some situations, an entire drive will get backed up with 0% compression, even though I know there are plenty of compressible files.

 

 

 

I've attached the log for a backup I did last night. Hardware compression is disabled (doesn't exist anyway), and software compression is enabled. I'm doing an initial backup up from three subvolumes. The first (700MB) compressed 22%. The second (5.7GB) compressed 0% (!!). The third (460MB) compressed 34%. And the total compression is listed as 0%.

 

 

 

This is weird. That middle volume has lots of compressible items (I checked with the "~Compression filter" selector, and over 90% of the files would have been compressed). Plus, even if the individual volume compressions were as listed, the total should have been around 4-5%.

 

 

 

Any idea what's up? There's at least a bug in the display of the total compression value: is that middle volume actually getting compressed and its "0%" is the result of another display bug? Or is there some configuration issue that I'm missing?

 

 

 

(I'd really rather not pay the $70 to get assistance for this one issue...)

 

 

 

 

 

Thanks,

 

Dan

 

 

 

 

 

P.S. Here's the log:

 

 

 

? Retrospect version 4.3

 

launch at 3/11/2002 9:48 PM

 

 

 

+ Normal Backup using G4 Backup at 3/11/2002 9:53 PM

 

To backup set G4 Weekly 1…

 

 

 

- 3/11/2002 9:53:06 PM: Copying Apps on Macintosh HD

 

 

 

! 3/11/2002 9:55 PM: Manual erase of tape named “”

 

3/11/2002 10:03:17 PM: Comparing Apps on Macintosh HD

 

3/11/2002 10:09:25 PM: Execution completed successfully

 

Completed: 12074 files, 700.9 MB, with 22% compression

 

Performance: 112.2 MB/minute (98.4 copy, 130.5 compare)

 

Duration: 00:16:19 (00:03:50 idle/loading/preparing)

 

 

 

- 3/11/2002 10:09:26 PM: Copying Documents on Macintosh HD

 

3/11/2002 11:32:04 PM: Comparing Documents on Macintosh HD

 

3/12/2002 12:37:57 AM: Execution completed successfully

 

Completed: 15333 files, 5.7 GB, with 0% compression

 

Performance: 87.5 MB/minute (83.1 copy, 92.5 compare)

 

Duration: 02:28:31 (00:15:41 idle/loading/preparing)

 

 

 

- 3/12/2002 12:37:57 AM: Copying System Folder on Macintosh HD

 

3/12/2002 12:44:48 AM: Comparing System Folder on Macintosh HD

 

Different modify date/time (set: 3/12/2002 12:38:09 AM, vol: 3/12/2002 12:44:49 AM) for file “System Folder:Preferences:Power On Preferences:Recent Items Database:Local Applications Database”.

 

Different modify date/time (set: 3/12/2002 12:38:09 AM, vol: 3/12/2002 12:44:49 AM) for file “System Folder:Preferences:Power On Preferences:Recent Items Database:Recent Applications Database”.

 

3/12/2002 12:50:41 AM: 2 execution errors

 

Completed: 5802 files, 465.8 MB, with 34% compression

 

Performance: 125.3 MB/minute (112.6 copy, 141.1 compare)

 

Duration: 00:12:44 (00:05:18 idle/loading/preparing)

 

 

 

3/12/2002 12:50:41 AM: 2 execution errors

 

Total performance: 91.4 MB/minute with 0% compression

 

Total duration: 02:57:35 (00:24:49 idle/loading/preparing)

 

Shutdown at 3/12/2002 12:50 AM

 

 

Link to comment
Share on other sites

Actually the compression filter is used to show you which files Retrospect will NOT compress during a backup. The compression filter is used by Retrospect to exclude pre-compressed files from backup.

 

 

 

The percentage displayed in the log is an average for the entire disk, and may be misleading. During the backup you will see the current compression ratio as files get copied.

 

 

 

The best test:

 

 

 

Fill a tape with compression turned off

 

Fill a tape with compression turned on (copy the same data as above)

 

 

 

What is the capacity comparision?

Link to comment
Share on other sites

My "~Compression Filter" selector is clearly designed to select files TO be compressed. Its logic is of the form "Include files matching (alias flag is set) or matching (file kind is not type SIT! and file kind is not Compact Pro and file kind is not type DDAP and file name does not end with ".ZIP" and file name does not end with ".ARC" and...)". Also, if you edit a script, click "More Choices", and then show the "Compression" panel, the panel says "Compress only those files selected by the chosen Selector." Again, over 90% of the files in my main subvolume is chosen by this selector, so these all should be candidates for compression.

 

 

 

I tried doing my backup with software compression on and off (recycling the media in each case). With software compression on, the backup set ended up with 7.2 GB for 33,211 files. With software compression off, the backup set ended up with 6.9 GB for 33,211 files. I was hoping for around 25% compression, and would be happy with 15% compression, but -4% compression doesn't seem very useful to me.

 

 

 

Any more ideas?

 

 

Link to comment
Share on other sites

You should never use the "Compression selector" as an item in the "selecting" catagory of your script or immediate backup. That is not what this selector is used for. You should use "all files" as file selection criteria.

 

 

 

The selector uses a double negative "include" and "not" as part of every line in the selector, this turned it into "exclude".

 

 

 

If pre-compressed files (like MP3's) are compressed and copied, they may actually get larger when stored on the media.

 

 

 

From the user's guide:

 

Retrospect uses its built-in Compression filter selector to identify files that are already compressed (such as those compressed with a utility such as StuffIt) so it will not attempt to re-compress them with software data compression.

 

 

 

Compression filter under "options': This option, which is available only when the Data Compression option is on, lets you determine the selector used to filter files when compressing. Retrospect normally uses the built-in Compression filter selector to identify

 

and avoid compressing files that are already compressed. You are not likely to need to change this option. If you want to use a different selector to tell Retrospect which files to compress,

 

you can modify the Compression filter selector or create your own. (See “Using Selectors” in Chapter 9.) By default, this option is set

 

to use the Compression filter selector when Data Compression is on. See “Data Compression (in software)” on page 139 for further

 

information.

Link to comment
Share on other sites

Thanks for your response. I'm not using "~Compression filter" anywhere except in the "Compression" pane of the script editor, which is where it was put by Retrospect. Nor have I modified the compression filter in any way.

 

 

 

The "~Compression filter" selector selects files which should be compressed. For example, if I choose that selector, and use the "Check Selector..." menu item on my "Documents" subvolume, files such as AppleWorks documents, PICT files, FreeHand files and Toast disk images are selected, while StuffIt archives and .zip archives are not selected. Again, this is using the selector as it was built by Dantz; I've never modified it. I did some further tests: my "Documents" subvolume has 16504 files, using the "~Compression filter" selector on the volume selects 16184 files, while the corresponding snapshot in the backup set has 15333 files (the rest are excluded by my own custom selector, based on a "Do Not Backup" label).

 

 

 

Being a thorough person, I just tried compacting my "Documents" subvolume (minus files excluded by my custom selector) using StuffIt 6.5 (splitting it as necessary to avoid the 2GB archive size limit). The results: 18% compression, where Retrospect had reported 0%. I also tried compressing my System Folder: 58% compression, where Retrospect had reported 34%.

 

 

 

It's clear that Retrospect's reported compression numbers don't add up, since the three volumes' reported compression values (22%, 0%, and 34%), weighted by size, should add up to about 5%, while Retrospect reported a total compression of 0%. I believe the reason is that Retrospect can actually expand file sizes, and when it does so does not report negative compression percentages. That second volume (which even StuffIt had trouble compressing) must have ballooned in size, negating the savings from the other volumes.

 

 

 

Suggestion: when Retrospect's software compression efforts make the resulting backup set larger than the original files, have it tell the truth and report a negative percentage of compression (e.g. "-20% compression"). That way, system administrators can either try to adjust the "~Compression filter" selector, or turn off software compression altogether. Pretending compression never makes things worse is less than useless.

 

 

 

 

 

Thanks for the help,

 

Dan

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...