compression issue with backup

[mister.noodle]

Hello,
I'm actually facing an weird issue whan using mysql-zrm backup. Here is my server settings :

Ubuntu 14.04 LTS server
ZRM for MySQL Community Edition - version 2.2.0

Let me explain the issue. When I test a daily backup set it works successufully but my backup compressed file seems to be corrupted, something went wrong when zrm compress the file "backup-data.sql" not no error has been displayed. Anyone has already face this behaviour ? When I disable in the compression in "mysql-zrm.conf" my backup file is ok. Here is the outpout of the backup process :

[email protected]:/backups/mysql/vega.daily# mysql-zrm-scheduler --now --backup-set vega.daily
schedule:INFO: ZRM for MySQL Community Edition - version 2.2.0
Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
backup:INFO: ZRM for MySQL Community Edition - version 2.2.0
vega.daily:backup:INFO: START OF BACKUP
vega.daily:backup:INFO: PHASE START: Initialization
vega.daily:backup:INFO: The quick backup-type is supported only for snapshot backups. Setting backup-type to 'regular'
vega.daily:backup:WARNING: Binary logging is off.
vega.daily:backup:INFO: backup-set=vega.daily
vega.daily:backup:INFO: backup-date=20140627113346
vega.daily:backup:INFO: mysql-server-os=Linux/Unix
vega.daily:backup:INFO: backup-type=regular
vega.daily:backup:INFO: host=localhost
vega.daily:backup:INFO: backup-date-epoch=1403861626
vega.daily:backup:INFO: retention-policy=7D
vega.daily:backup:INFO: mysql-zrm-version=ZRM for MySQL Community Edition - version 2.2.0
vega.daily:backup:INFO: mysql-version=5.5.37-0ubuntu0.14.04.1
vega.daily:backup:INFO: backup-directory=/backups/mysql/vega.daily/20140627113346
vega.daily:backup:INFO: backup-level=0
vega.daily:backup:INFO: backup-mode=logical
vega.daily:backup:INFO: PHASE END: Initialization
vega.daily:backup:INFO: PHASE START: Running pre backup plugin
vega.daily:backup:INFO: PHASE END: Running pre backup plugin
vega.daily:backup:INFO: PHASE START: Flushing logs
vega.daily:backup:INFO: PHASE END: Flushing logs
vega.daily:backup:INFO: PHASE START: Creating logical backup
-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.
vega.daily:backup:INFO: logical-databases=kayako mysql performance_schema phpmyadmin
vega.daily:backup:INFO: PHASE END: Creating logical backup
vega.daily:backup:INFO: PHASE START: Calculating backup size & checksums
vega.daily:backup:INFO: last-backup=/backups/mysql/vega.daily/20140627010002
vega.daily:backup:INFO: backup-size=1.40 GB
vega.daily:backup:INFO: PHASE END: Calculating backup size & checksums
vega.daily:backup:INFO: PHASE START: Compression/Encryption
vega.daily:backup:INFO: compress=
vega.daily:backup:INFO: backup-size-compressed=0.00 MB
vega.daily:backup:INFO: PHASE END: Compression/Encryption
vega.daily:backup:INFO: read-locks-time=00:02:33
vega.daily:backup:INFO: flush-logs-time=00:00:00
vega.daily:backup:INFO: compress-encrypt-time=00:02:33
vega.daily:backup:INFO: backup-time=00:02:33
vega.daily:backup:INFO: backup-status=Backup succeeded
vega.daily:backup:INFO: Backup succeeded
vega.daily:backup:INFO: PHASE START: Running post backup plugin
vega.daily:backup:INFO: PHASE END: Running post backup plugin
vega.daily:backup:INFO: PHASE START: Mailing backup report
vega.daily:backup:INFO: PHASE END: Mailing backup report
vega.daily:backup:INFO: PHASE START: Cleanup
vega.daily:backup:INFO: PHASE END: Cleanup
vega.daily:backup:INFO: END OF BACKUP
/usr/bin/mysql-zrm started successfully


------------------------------------------------

My backup file when compression is enabled :

-rw-r--r-- 1 root root 20 Jun 27 01:02 backup-data

My backup file when compression is disabled :

-rw-r--r-- 1 root root 1500578 Jun 27 01:02 backup-data.sql


Thanks in advace for your help !

[shakalandy]

Try enabling verbose=1 in your mysql-zrm.con.

for me the issue seems an incompatibility with newer versions of tar:


web101:backup:INFO: Compressing backup
web101:backup:INFO: Command used is 'tar --same-owner -cpsC "/var/lib/mysql-zrm/web101/20140908182003" --exclude=backup-data --exclude=index --exclude=zrm_checksum --exclude=backup-sql . 2>/tmp/rrbC1WVLdJ | "/bin/gzip" 2>/tmp/SBQIKJI0Va > "/var/lib/mysql-zrm/web101/20140908182003/backup-data" 2>/tmp/KvlJzrvjk4'
web101:backup:INFO: Output of command: 'tar' is {
tar: --same-order option cannot be used with -c
Try 'tar --help' or 'tar --usage' for more information.
}
web101:backup:INFO: compress=/bin/gzip
web101:backup:INFO: backup-size-compressed=0.00 MB

[shakalandy]

I haven't added that this is a critical issue and incompatibility with newer versions of tar (in debian everything 1.27 up)
What is even more critical is that Mysql-zrm says the Backup finished successfully, even when it didn't store anything.. :(

Downgrade back to tar_1.26+dfsg-8_amd64.deb on Debian and everything works fine again.

[colin49]

Confirming this issue as well. Running Ubuntu 14.04 with Tar version 1.27.1.

When compression is turned on backup claims to complete successfully. However, the backup file is 20bytes compressed when when you uncompress it via gzip -d it becomes 0bytes.

Major bug as you have no idea your backups are failing!


I haven't added that this is a critical issue and incompatibility with newer versions of tar (in debian everything 1.27 up)
What is even more critical is that Mysql-zrm says the Backup finished successfully, even when it didn't store anything.. :(

Downgrade back to tar_1.26+dfsg-8_amd64.deb on Debian and everything works fine again.

[colin49]

After digging around some more it looks like the new version of tar doesn't allow the --same-order or -s option when creating a tar file. It's possible it was always this way but the new version is now enforcing it. Looking at the tar docs (GNU Tar Chapter 4 SEC89) for this option you can see that the option is valid for creating tars only when extracting them.

Here is a small patch that removes the -s / --same-order option from the TAR_COMPRESS_OPTIONS.

--- /usr/lib/mysql-zrm/ZRM/Common.pm 2014-09-20 19:31:49.288321911 -0400
+++ /usr/lib/mysql-zrm/ZRM/Common-Fix-Tar-Failing-On-Same-Order-Option.pm.patch 2014-09-20 19:22:18.776321911 -0400
@@ -91,7 +91,7 @@
our $MYSQL_ZRM_CONFIG_FILE=catfile( $MYSQL_ZRM_BASEDIR, "mysql-zrm.conf");
#Compress & Encrypt progs
our $TAR="tar";
-our $TAR_COMPRESS_OPTIONS=" --same-owner -cpsC ";
+our $TAR_COMPRESS_OPTIONS=" --same-owner -cpC ";
our $TAR_UNCOMPRESS_OPTIONS=" --same-owner -xpsC ";
our $TAR_EXCLUDE_OPTION=" --exclude";
our $COMPRESS_FILENAME="backup-data";

[saleck]

Hi,

I must admit I am shocked to find this thread here today since we have upgraded our ancient backup server (together with upgrade of ZRM to 3.0) and discovered this problem still hasn't been repaired! :(

Thank you colin49 for a quick solution!