You will probably find that
zip is spending most of its time waiting for I/O (reading files and writing the compressed versions) which is why it is not using as much CPU as you expect. Giving the process extra priority via
nice has no effect on this as the task can't use any more CPU time if it isn't being fed data at a rate that would require it to.
Under Linux you can see this situation as a high %age as "IO Wait" time in the output from
top and similar utilities, the same may be true for OSX.
Reasons for the IO wait time could include:
- processing many small files (lots of head movement reading the files and related directory structures)
- file fragmentation
- competing with other activity on the relevant drives (users copying/moving/accessing files, scheduled AV scans, ...) while the backup takes place
- reading the files over a network (a modern CPU can zip data far faster than a 100Mbit/s link can ever feed it, and network latency will exacerbate the effect of many-small-files) or pushing the compressed data over the network (unless your data is unusually compressible, the same "zip is faster then your network on modern CPUs" condition applies as it'll read from your local drives and process the daat faster than it can then send the result over the network)
- network contention (if the server your are talking to has a 100Mbit link and others are using it this may be an issue, less so if it has a faster link of course)
- slow drives or slow interfaces (if any of the drives concerned are USB2 connected they'll tend to transfer no more than 25Mbyte/sec, sometimes slower depending on the USB adaptor used and USB bus contention with other fast devices, where a modern internal drive will push double that if not more for bulk transfers)
If you want to make use of the "spare" CPU cycles, and can't do so by reducing the IO delays, you could try using 7zip instead - this uses much more CPU time per block of data but achieves better compression than zip by quite some margin too in many cases, reducing the size of your backups. Whether this will be faster (because 7zip results in sending less data over the network) or slower (because the extra computational complexity means you CPU may become the bottleneck not the disks/filesystems/network) depends on your machines exact spec.
One other thing, some tools report process use per-core and some per-CPU (and some either way depending on settings), and zip is usually an threaded process. So if you have a quad-core CPU that 5% is not unlikely to be "5% of the CPU", or approx 20% of one core (though it may be bouncing between cores, if it is single threaded it won't be running on more than one at any given instant).