Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Currently I'm running tar czf to combine backup files. The files are in a specific directory.
But the number of files is growing. Using tzr czf takes too much time (more than 20 minutes and counting).
I need to combine the files more quickly and in a scalable fashion.
I've found genisoimage, readom and mkisofs. But I don't know which is fastest and what the limitations are for each of them.
You should check if most of your time are being spent on CPU or in I/O. Either way, there are ways to improve it:
A: don't compress
You didn't mention "compression" in your list of requirements so try dropping the "z" from your arguments list: tar cf. This might be speed up things a bit.
There are other techniques to speed-up the process, like using "-N " to skip files you already backed up before.
B: backup the whole partition with dd
Alternatively, if you're backing up an entire partition, take a copy of the whole disk image instead. This would save processing and a lot of disk head seek time. tar and any other program working at a higher level have a overhead of having to read and process directory entries and inodes to find where the file content is and to do more head disk seeks, reading each file from a different place from the disk.
To backup the underlying data much faster, use:
dd bs=16M if=/dev/sda1 of=/another/filesystem
(This assumes you're not using RAID, which may change things a bit)
pigz if exist in the system more than one processor.
Aug 21, 2011 at 20:39
Using tar with lz4 crompression like in
tar cvf - myFolder | lz4 > myFolder.tar.lz4
gives you the best of both worlds (rather good compression AND speed). Expect a compression ratio of about 3 even if your data contains binary files.
Further reading: comparison of compression algorithms How to tar with lz4
To repeat what others have said: we need to know more about the files that are being backed up. I'll go with some assumptions here.
If files are only being added to the directories (that is, no file is being deleted), make sure you are appending to the existing tar file rather than re-creating it every time. You can do this by specifying the existing archive filename in your tar command instead of a new one (or deleting the old one).
Reading from the same disk you are writing to may be killing performance. Try writing to a different disk to spread the I/O load. If the archive file needs to be on the same disk as the original files, move it afterwards.
Just repeating what @Yves said. If your backup files are already compressed, there's not much need to compress again. You'll just be wasting CPU cycles.
I'm surprised that no one mention dump and restore. It will be a lot faster than dd if you have free space in the filesystem.
Note that depending on the filesystem in question you may need different tools:
Note that some program does not have built-in compression (all except dump) - pipe to stdout and use pigz as needed. ;-)
tarintroduces any significant overhead, reading the files is the expensive operation here. You should either modify the way your files are stored, or use a radically different approach (copy the filesystem as a whole). We can't help you much without knowing how your files are organized.