Faster cPanel Backup by Replacing gzip with pigz
Gzip doesn't make good use of multi-processor/multi-core machines, which results in long backup time.
Fortunately, there's an in-place replacement, pigz
"pigz, which stands for parallel implementation of gzip, is a fully functional replacement for gzip that exploits multiple processors and multiple cores to the hilt when compressing data."
Also, files compressed with pigz can be decompressed with gunzip, and unpigz can decompress gzip compressed files.
I've done a couple of tests on an 8 cores machine, and here are the results:
-
[root@ns3 tests]# time gzip test1.tar
real 1m 7.176s
user 0m55.119s
sys 0m1.069s
[root@ns3 tests]# time pigz test2.tar
real 0m 12.096s
user 1m15.924s
sys 0m1.109s
[root@ns3 tests]# time pigz -1 test3.tar
real 0m 7.141s
user 0m44.020s
sys 0m1.349s
-rw-r--r-- 1 root root 315M Nov 10 04:54 test1.tar.gz
-rw-r--r-- 1 root root 315M Nov 10 04:54 test2.tar.gz
-rw-r--r-- 1 root root 346M Nov 10 04:54 test3.tar.gz
-rw-r--r-- 1 root root 788M Nov 10 04:54 test.tar
In layman's terms "to get more votes :)" .. pigz compressed a 788 MB file, using fastest compression and all 8 cores, in 7 seconds, while it took gzip 1 minute and 7 seconds .. you do the math.
BTW, pigz was written by Mark Adler.
Adler is the author of the Adler-32 hash function, a co-author of the zlib compression library and gzip, has contributed to Info-ZIP, and has participated in developing the Portable Network Graphics (PNG) image format. Adler was also the Spirit Mission Manager for the Mars Exploration Rover mission.
In short .. he knows what he's doing :)
Original Thread: Faster cPanel Backup by replacing gzip with pigz
pigz integration with pkgacct and the backup system is complete. Barring incident it will be available with cPanel & WHM 11.38.
pigz integration with pkgacct and the backup system is complete. Barring incident it will be available with cPanel & WHM 11.38.
Any ETA yet when this will make it into production?
Any ETA yet when this will make it into production?
i think request together with remote incremental backup is number 1 priority in reducing overall load and io problems...but balance on number of cores used should be really really well calculated...
i think request together with remote incremental backup is number 1 priority in reducing overall load and io problems...but balance on number of cores used should be really really well calculated...
We've given up with making backups as they take too long... the best part of 6 hours. This then means the copying of the files to a different server happens during our busier hours and the load sky rockets despite all attempts to fine tune rsync to keep load low
We've given up with making backups as they take too long... the best part of 6 hours. This then means the copying of the files to a different server happens during our busier hours and the load sky rockets despite all attempts to fine tune rsync to keep load low
Hurry up with this please.
Hurry up with this please.
pigz integration with pkgacct and the backup system is complete. Barring incident it will be available with cPanel & WHM 11.38.
pigz integration with pkgacct and the backup system is complete. Barring incident it will be available with cPanel & WHM 11.38.
Well after one of our servers got hacked after cPanel support spilled our root password into the wild we had to nuke it and start from scratch. A 'simple' process of restoring the accounts from backup our hosts said once the server had been setup with Centos and cPanel. If only! The restore process failed to setup SSL properly and it took many attempts to get it working. The new DHTML/AJAX certificate page is a nightmare, pulling in outdated (bad browser cache management?) certificate files which didn't match the key being installed. Careful paste, spot the reload and then paste the certificate back in again got around that. This server is unbelievably simple - a couple of accounts, each with just 2 PHP pages, a css file and a couple of images, and self-signed SSL certificates (fine for what we need). Yet the restore process couldn't deal with it. Would I trust it to our big live sites... no chance.
Well after one of our servers got hacked after cPanel support spilled our root password into the wild we had to nuke it and start from scratch. A 'simple' process of restoring the accounts from backup our hosts said once the server had been setup with Centos and cPanel. If only! The restore process failed to setup SSL properly and it took many attempts to get it working. The new DHTML/AJAX certificate page is a nightmare, pulling in outdated (bad browser cache management?) certificate files which didn't match the key being installed. Careful paste, spot the reload and then paste the certificate back in again got around that. This server is unbelievably simple - a couple of accounts, each with just 2 PHP pages, a css file and a couple of images, and self-signed SSL certificates (fine for what we need). Yet the restore process couldn't deal with it. Would I trust it to our big live sites... no chance.
Any news?!
Any news?!
When cPanel & WHM 11.38 will be released?!
When cPanel & WHM 11.38 will be released?!
Looks like we might get this sooner than 11.38? Have just received this email from cPanel...We are excited to announce cPanel & WHM software version 11.37.0.5 has gone to the EDGE Tier.
If you are not yet ready to receive the 11.37 series, this is your last chance to change your update preferences.
In our newest version of cPanel & WHM software, you will find improvements in:
- SSL Management System
- Backup System
- Other Improvements:
- Able to configure hosts used for Email Autodiscovery and Autoconfiguration
- Support for pigz in Account Transfer and Backups
- New cPanel & WHM installs will feature MySQL5.5
- Improved jailshell functionality
- Added jailshell mount configuration to Tweak Settings
- Jail Apache Virtual Hosts Via mod_ruid2 and cPanel Jailshell
- TailWatch Updates
- Integration Focused Improvements
- Improvements to Apache Configuration
Looks like we might get this sooner than 11.38? Have just received this email from cPanel...We are excited to announce cPanel & WHM software version 11.37.0.5 has gone to the EDGE Tier.
If you are not yet ready to receive the 11.37 series, this is your last chance to change your update preferences.
In our newest version of cPanel & WHM software, you will find improvements in:
- SSL Management System
- Backup System
- Other Improvements:
- Able to configure hosts used for Email Autodiscovery and Autoconfiguration
- Support for pigz in Account Transfer and Backups
- New cPanel & WHM installs will feature MySQL5.5
- Improved jailshell functionality
- Added jailshell mount configuration to Tweak Settings
- Jail Apache Virtual Hosts Via mod_ruid2 and cPanel Jailshell
- TailWatch Updates
- Integration Focused Improvements
- Improvements to Apache Configuration
I updated, everything works just fine, I am waiting tomorrow to see backup results.
But I am really angry!
You didn't implemented pigz for "Backup Wizard" in cPanel, it still uses gzip, why?
I updated, everything works just fine, I am waiting tomorrow to see backup results.
But I am really angry!
You didn't implemented pigz for "Backup Wizard" in cPanel, it still uses gzip, why?
Any compressing activities that occur outside pkgacct need addressed as separate requests.
Any compressing activities that occur outside pkgacct need addressed as separate requests.
Activated on all our servers, nice improvments :)
Activated on all our servers, nice improvments :)
1. Change/rotate your root password every time you give it out for support.
2. Never have your server set for SSH password auth, ONLY use ssh keys.
3. Set your SSHD to listen on a random port! Don't use 22.
4. If you don't offer Jailed shells (we don't), further lock SSHD down via hosts.allow for ONLY IP's you know.
Those 4 steps alone help tighten up your servers. Nothing is hack proof but, it stops all the script kiddie crap that happens.
1. Change/rotate your root password every time you give it out for support.
2. Never have your server set for SSH password auth, ONLY use ssh keys.
3. Set your SSHD to listen on a random port! Don't use 22.
4. If you don't offer Jailed shells (we don't), further lock SSHD down via hosts.allow for ONLY IP's you know.
Those 4 steps alone help tighten up your servers. Nothing is hack proof but, it stops all the script kiddie crap that happens.
Any updates on this request? cPanel please update now!
Any updates on this request? cPanel please update now!
Replies have been locked on this page!