I just tarballed a dump of some websites (configs, image directory, css directory, and site content (html files etc)) using tar czf sitedump.tgz backup_folder/. The original "backup_folder" was about 600MB and so was the tarball, only a little smaller.

What scenario presents a challenge for these compression formats, and what is likely the cause of the minimal reduction in size in this case? Tar version 1.23

  • I guess in case of images or media files.
    – beginer
    Commented Sep 2, 2014 at 14:01

2 Answers 2


This is a question of lossless data compression, namely the one of its limitations. Usually the more random the data is the harder it is to compress, because compression basically is finding patterns and representing them with less information (you may think of it as of being able to predict following words from the beginning of a sentence). Thus a noise would be (almost) entirely incompressible while long repeating sequences can be compressed rather well. If you want more than this hand-waving, the links provided above might be a good starting point.

As for the tarballs - apart from the data in the files, tape archives (that is what "tar" originally stood for here) contain file metadata (usually one or more 512B blocks per file, depending on the exact tar flavour) which is compressed as well. Thus if you really wanted to make it as incompressible as possible, you'd need to use random file names, random user/group IDs/names, file modes, make sure the noise-containing files and file metadata have sizes of whole multiples of 512B blocks (to prevent any padding with zeros).

Another reason for the archive being surprisingly large might be low compression level by gzip - for standalone gzip this is given by -0 (no compression) through -9 (maximum compression), with the default of -6.

If you really want to compress it as well as is possible, you probably want to use a different algorithm (and hence compression program). xz is usually considered the best performer.

  • This is a very good, and understandably simplified answer, thank you. I suppose non-sequential file names, and "noisy" HTML and JavaScript results in a difficult to compress archive. Commented Sep 2, 2014 at 15:32
  • depends on what you call noisy - both HTML and JavaScript are text-based, when you are using English (basically sticking to ASCII), it is compressible pretty well. The same goes for non-sequential file names. For other possible reasons see updated answer.
    – peterph
    Commented Sep 2, 2014 at 15:37
  • 1
    @GreggLeventhal Non-sequential file names, noisy HTML, minified JS, etc. likely have negligible influence on your archive size. Commented Sep 2, 2014 at 23:24
  • Gilles is right, this is order of magnitude of randomness less than really random, encrypted or already compressed (JPEG/MPEG/MP3/...) data.
    – peterph
    Commented Sep 3, 2014 at 0:14

If you have a moderately large website, unless it has a lot of user-contributed content, it has probably has a couple of megabytes of HTML, CSS, JavaScript, PHP, etc. This stuff can typically be compressed pretty well.

Which means that the images are something like 99% of the tarball. Images are already compressed, so compressing them again won't reduce the size (or only a little if they're different compression algorithms — gzipping a JPEG image with a very high quality factor can reduce the size a little).

Let's say you have 5MB of text and code with a 1:3 compression ratio and 600MB of images with a 1:1.01 compression ratio. The result is a 595MB archive.

On a Linux system, you can run du --exclude='*.jpg' --exclude='*.png' --exclude='*.gif' to add up the size of files in a directory, excluding common image formats.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .