We recently tweaked our percona backup scripts to ensure the backups were encrypted. We see a jump in backup size from 163GB to 612GB
/usr/bin/innobackupex --safe-slave-backup --safe-slave-backup-timeout=120 --slave-info --user=XXXXX–password=YYYY --no-timestamp --encrypt=AES256
–encrypt-threads=4 --encrypt-key-file=zzzz /var/backup_mysql/mysql_20200114-enc.busy
This gave the 163GB file.
Vs the original command
/usr/bin/innobackupex --safe-slave-backup --safe-slave-backup-timeout=120 --use-memory=4G --apply-log /var/backup_mysql/20191209/
-rw-rw-r-- 1 root pirum 163G Dec 5 14:44 mysql_20191205_135128.tar.gz
Is there anything obvious I have missed or something I need to do get get the file size down.
Something for you to check out. The second one is compressed, but compressing after encryption will likely not give you a great compression ratio. In this case, it would be worth you trying the compress option of Percona Xtrabackup (–compress ) to compress before encryption.
Thanks, I was so focused on pgp encryption, I had forgotten that encryption does not compress. Adding --compress did the trick. Without compress my 268GB myisam db took 51min and was 256GB in size after taring, which took another 59min.
Using –compress --compress-threads=10 took 46min and a tar of the backup was 86GB which took 19min. A massive improvement, a third of the size and half he time. Adding in the --parallel=1 and repeating the encrypted backup only affect the timing by a few seconds. I played about with several settings on my 56 core server and settled down on --compress-threads=10 --parrallel=10 --encrypt-threads=10
