Small WordPress backup script

Simple backup script written in bash, for WordPress on Linux, that will dump MySQL database used by WordPress site and create tar.gz file consisting of WordPress site files and database dump



DBUSER=$(grep DB_USER $WEBROOT/wp-config.php | awk -F\' '{print$4}')
DBNAME=$(grep DB_NAME $WEBROOT/wp-config.php | awk -F\' '{print$4}')
DBPASSWORD=$(grep DB_PASSWORD $WEBROOT/wp-config.php | awk -F\' '{print$4}')
DBDUMP="$BKPDIR""$DBNAME"_$(date +"%Y-%m-%d-%H-%M").sql

#In case you want to rsync backups to remote server


tar -czvf "$BKPDIR"wpbackup_$(date +"%Y-%m-%d_%H-%M").tar.gz $WEBROOT $DBDUMP

rsync -az $BKPDIR -e "ssh -p $RSSHPORT" [email protected]$RHOST:$RDIR

It will create two backup files, one for database dump in format that looks like “joomla_2018-01-04-06-00.sql” and one tar.gz file that will look like “wpbackup_2018-01-04_06-00.tar.gz”.

Script can be saved as and put in crontab to run at a certain time like 6:00AM.

0 6 * * * /path/to/script/ 2>/dev/null

It can also be run manually with bash

How to clear disk space on cPanel server

By default drives will come with 5% of all filesystems allocated as reserved disk space allocated for privileged users, and not shown as available space.

Since drives in use today tend to be large, reserved block percentage can be lowered to 1%, or specified to specific number of block.

To set the reserved space to 2500 blocks “tune2fs -r 2500” can be used.

tune2fs -r 2500 /dev/sda5

To set reserved space to 1% of disk size “tune2fs -m 1” can be used.

tune2fs -m 1 /dev/sda5

Files that can be cleared by main partitions/folders, to reduce disk usage on cPanel servers:

Reduce /home usage

Several files and folders can be truncated or removed on /home.

When EasyApache is run, it will leave file behind, that were used for Apache/PHP build, that can be removed if space is needed.

EasyApache files can be removed with following command.

rm -rfv /home/cpeasyapache

cPanel FileManager can leave temporary files, that were created during user uploads.
These can be removed with following command:

rm -fv /home/*/tmp/Cpanel_*

If you were moving any accounts to the server with WHM Transfer Tool, temporary account migration files can be left on drive.

These can be removed with following command:

rm -rvf /home*/cpanelpkgrestore.TMP*

Disk space can be recovered by deleting Softaculous and Fantastico backups from user folders, if they are used.

rm -fv /home*/*/.softaculous/backups/*
rm -rfv /home/*/fantastico_backups

If you were making cpmove file manually, they will by default be created inside /home.
You can clean any leftover cpmove files with following command:

rm -rvf /home/cpmove-*

Often large portions of disk space can be used up by large error_log files inside account home folders.

You can empty all error_log files to 0 bytes usage with following command:

find /home/ -name error_log -type f -print -exec truncate --size 0 "{}" \;

If users have large number of account backups in their home folders, those can use up a lot of space.

Accounts backups can be removed from user folders with following command:

for user in `/bin/ls -A /var/cpanel/users` ; do rm -fv /home/$user/backup-*$user.tar.gz ; done
Summary of all used commands, for clearing /home
#Emtpy all error logs
find /home/ -name error_log -type f -print -exec truncate --size 0 "{}" \;
#Remove EasyApache files
rm -rfv /home/cpeasyapache
#Remove Softaculous backups
rm -fv /home*/*/.softaculous/backups/*
#Remove account backups
for user in `/bin/ls -A /var/cpanel/users` ; do rm -fv /home/$user/backup-*$user.tar.gz ; done
#Remove Fantastico backups
rm -rfv /home/*/fantastico_backups
#Remove temporary cPanel files
rm -fv /home/*/tmp/Cpanel_*
#Remove any cpmove files
rm -rvf /home/cpmove-*
#Remove temporary account migration files
rm -rvf /home*/cpanelpkgrestore.TMP*
Reduce /var usage

Disk space in /var can be cleared by deleting archived logs, which will usually end with .gz, or contain year inside their name, like such as “maillog-20161113”.

Archived logs can be cleared with following commands:

rm -fv /var/log/*.gz
rm -fv /var/log/*201*

Disk space in /var can get also get used up by core dump files inside /var/spool/abrt/ directory, which get created in cases of kernel panic.

These file can be cleared up with following command:

rm rfv /var/spool/abrt/*

Check the size of exim stats database, which can sometimes take several gigabytes in size, depending on settings:

du -sh /var/lib/mysql/eximstats/

In case eximstats database is large, consider emptying the database, and changing retention settings.

How to clear or disable eximstats on cPanel

Reduce /usr usage

Disk space in /usr can be cleared by removing cPanel and Apache archived logs, or old installation files of Apache, and if installed, maldet.

Every time you rebuild Apache with EasyApache, old installation files will be moved to “apache.backup*” directory.

Remove old Apache files with following command:

rm -rfv /usr/local/apache.backup*

Similar thing happens with maldet, if it is installed, on updates, old installation will be moved to “maldet.bk*” folder.

Remove old maldet files with following command:

rm -rfv /usr/local/maldet.bk*

Clear disk space by removing archived cPanel logs:

rm -fv /usr/local/cpanel/logs/archive/*.gz

Remove archived Apache logs:

rm -fv /usr/local/apache/logs/*.gz
rm -fv /usr/local/apache/logs/archive/*.gz

Although not often, sometimes maldet logs can use up a lot of space.
Remove maldet logs:

rm -fv /usr/local/maldetect/logs/*
Summary of all used commands, for clearing /usr
#Remove old Apache files
rm -rfv /usr/local/apache.backup*
#Remove old maldet files
rm -rfv /usr/local/maldet.bk*
#Remove maldet logs
rm -fv /usr/local/maldetect/logs/*
#Remove archived cPanel logs
rm -fv /usr/local/cpanel/logs/archive/*.gz
#Remove archived Apache logs
rm -fv /usr/local/apache/logs/*.gz
rm -fv /usr/local/apache/logs/archive/*.gz

How to Free Up Disk Space on a cPanel Server

11 Ways to Free Up Disk Space on a cPanel Server

How to clear or disable eximstats on cPanel

What is eximstats

Eximstats, on WHM/cPanel servers, is used to maintain statistics and information about email messages processed by Exim mail service.

If the data in it is not cleared often enough it can grow, and cause issues with disk space, or MySQL resource usage, as the size of the database can cause higher memory and disk consumption.

Disabling eximstats

If you do not have any need for Exim statistics, which are used for Mail Delivery Reports on  Home »Email »Mail Delivery Reports, gathering exim statistics can be disabled from WHM or command line.

In WHM it can be disabled by going to Home »Service Configuration »Service Manager, and unchecking the service, and then clicking on the Save button on the bottom.

This will stop the database from being populated with new data.

Eximstats in Service Manager
Service Manager

From command line, you can disable the database from being populated by running a following command:
/usr/local/cpanel/bin/tailwatchd --disable=Cpanel::TailWatch::Eximstats

Lowering Eximstats retention time

Database is periodically cleaned, and by default Exim stats are retained in database for 10 days, which can be changed in WHM by going to Home »Server Configuration »Tweak Settings and changing the “The interval, in days, to retain Exim stats in the database” setting on the “Stats and Logs” tab.

Setting can also be changed by altering the “exim_retention_days” value in “/var/cpanel/cpanel.config” file.

Empty eximstats database

Database can be cleared either by deleting from its four tables, defers, failures, sends and smtp, or by dropping the database completely, and creating a fresh one with empty tables from “/usr/local/cpanel/etc/eximstats_db.sql” file.

To delete all of the data from the tables following command can be used:

mysql -e "use eximstats;delete from defers;delete from failures;delete from sends;delete from smtp;delete from smtp;"

To drop the database and recreate it again, following commands can be used:

mysqladmin drop eximstats
mysqladmin create eximstats
mysql eximstats < /usr/local/cpanel/etc/eximstats_db.sql

blob data length is greater than 10% of the total redo log size

On MySQL 5.6.20, and above you might be getting errors when trying to import tables, databases, if you innodb_log_file_size is too small.

If you are seeing error message like this, you will need to increase your innodb_log_file_size inside your my.cnf or my.ini MySQL configuration file.

The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
2015-09-07 17:29:33 12298 [ERROR] InnoDB: The total blob data length (10066357) is greater than 10% of the total redo log size (100663296). Please increase total redo log size.

As of MySQL version 5.6.20 changes were implemented in regards to InnoDB and BLOB data size in you tables, and you InnoFB log should be at least 10 times higher than the largest BLOB data size found in the rows of your tables, plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields).

InnoDB Notes

Important Change: Redo log writes for large, externally stored BLOB fields could overwrite the most recent checkpoint. The 5.6.20 patch limits the size of redo log BLOB writes to 10% of the redo log file size. The 5.7.5 patch addresses the bug without imposing a limitation. For MySQL 5.5, the bug remains a known limitation.

As a result of the redo log BLOB write limit introduced for MySQL 5.6, the innodb_log_file_size setting should be 10 times larger than the largest BLOB data size found in the rows of your tables plus the length of other variable length fields (VARCHAR, VARBINARY, and TEXT type fields). No action is required if your innodb_log_file_size setting is already sufficiently large or your tables contain no BLOB data.

In MySQL 5.6.22, the redo log BLOB write limit is relaxed to 10% of the total redo log size (innodb_log_file_size * innodb_log_files_in_group).

Once you increase innodb_log_file_size inside your my.cnf or my.ini file, error should be resolved.

2015-09-07 17:29:38 5345 [Note] InnoDB: Highest supported file format is Barracuda.
2015-09-07 17:29:38 5345 [Warning] InnoDB: Resizing redo log from 2*3072 to 2*65536 pages, LSN=702949287837
2015-09-07 17:29:38 5345 [Warning] InnoDB: Starting to delete and rewrite log files.
2015-09-07 17:29:38 5345 [Note] InnoDB: Setting log file ./ib_logfile101 size to 1024 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000
2015-09-07 17:29:42 5345 [Note] InnoDB: Setting log file ./ib_logfile1 size to 1024 MB
InnoDB: Progress in MB: 100 200 300 400 500 600 700 800 900 1000
2015-09-07 17:29:46 5345 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2015-09-07 17:29:46 5345 [Warning] InnoDB: New log files created, LSN=702949287837


MySQL failing to start with message “Can’t find file: ‘./mysql/plugin.frm’ (errno: 23)”

This is a repost of a post from an old blog, made on December 28, 2013, that used to be on:

Original post:

Recently I had a problem, where MySQL service was failing to start.
When tailing the MySQL log the following would be recorded while service was being started.

131224 06:04:53 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
/usr/libexec/mysqld: Can't find file: './mysql/plugin.frm' (errno: 23)
131224 6:04:53 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
/usr/libexec/mysqld: Can't create/write to file '/tmp/ibqcFQMW' (Errcode: 23)
131224 6:04:53 InnoDB: Error: unable to create temporary file; errno: 23
131224 6:04:53 [ERROR] Plugin 'InnoDB' init function returned error.
131224 6:04:53 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
131224 6:04:53 [ERROR] Can't create IP socket: Too many open files in system
131224 6:04:53 [ERROR] Aborting

131224 6:04:53 [Note] /usr/libexec/mysqld: Shutdown complete

131224 06:04:53 mysqld_safe mysqld from pid file /var/run/mysqld/ ended

Now, the message ‘Can’t find file: ‘./mysql/plugin.frm’ (errno: 23)‘ at the begging of the startup process might make you think that the problems is a missing file, but you can see that at the end of a startup process  this message is logged[ERROR] Can’t create IP socket: Too many open files in system.

This suggest that there is a problem with the number of files that is open on the system.
You can confirm this by using a perror utility, which prints system error messages.

If we check the error number 23, which is reported in the error message, we see that the cause of the failure is not a missing file, but that the file can’t be open because to many file handles are in use.

# perror 23
OS error code 23: Too many open files in system

You can check the current maximum number of file descriptors by checking the fs.file-max value in /etc/sysctl.conf, or use the sysctl command to check the current value.

# sysctl -a | grep file-max
 fs.file-max = 65536

To increase the maximum number of file handlesm you can edit /etc/sysctl.conf, change the value of fs.file-max to 200000 or some other value higher then the one you currently have, and then run sysctl -p to apply the new value to the system.

Now, after the file handle number has been increased, you should be able to start the MySQL service normally.