Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to speed up my backup done with tar cfz, the common way to do it. But day by day my backed up files grow so it becomes slower.

I was thinking to take advantage of the several cores available in my server and I was wondering if there is any difference between doing the backup with tar cfz or piping tar to gzip: tar cf - | gzip

I guess that there isn't any difference, because the first spawns two processes (tar and gzip), in a similar way like piping it.

If there is not difference, do you know any good alternative to do this, without going incremental? I'm looking at pigz too and it looks fine.

share|improve this question
Can someone with enough points edit this question? Using tar -cfz causes errors but tar -czf doesn't. – Eugene M Aug 27 '10 at 11:32
up vote 4 down vote accepted

When you say you want to take advantage of multiple cores the implication is that your tar with gzip is CPU bound and not IO bound, are you sure this is the case? If you are not sure you need to run sar, iostat, top, or check monitoring graphs etc to find out. Never a good idea to try to solve a problem with out understanding it first. Not saying this is the case with you for sure, but my guess would be that even though there is compression with gzip you would be more likely to be IO bound.

If it is IO bound, and you have multiple arrays, a separate process for each array might make sense.

I also second David's advice to consider incremental.

share|improve this answer
For me it is CPU and IO bound. I tried parallel bzip2 in my local machine and it was a flash to zip a huge file so I wondered if it was possible to apply a similar approach to servers. Anyway, I'm a limited user in those servers, I admin the application that run in them, not the OS, so I am not able to do changes without going through "bureaucracy". Finally, the servers have a high load (it is a huge system). Thanks for your comment, I didn't realize that I have bzip2 available. Maybe I can take a test with it. – Dario Castañé Mar 13 '10 at 9:07

You're unlikely to improve on the raw performance of tar and gzip by fiddling like this; in order to take better advantage of the hardware you could separate out folders into different parts and do multiple archives simultaneously.

Why do you not want to go incremental? I would recommend using rsnapshot even if you're doing this locally as it has the capability to use hard links to let you save disk space whilst still keeping exact copies from multiple times

share|improve this answer
I am not able to go incremental because I am a limited user on those systems, I don't admin them except the application layer. Your comment and Kyle's one made me think about using bzip2 and to try to do "kind-of" incremental backup, backing up only the changed files every day, with a full backup at weekend. Thanks! I will answer the question when I try both options. – Dario Castañé Mar 13 '10 at 9:10

If you are cpu bound (and not io bound!), you can use pigz. It will spread gzip over multiple cores. I use it for my backups. Its a drop in replacement for gzip:

tar cf - | pigz
share|improve this answer
yup pigz is much faster, check out – p4guru Nov 18 '11 at 17:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.