Results 1 to 5 of 5

Thread: compression issue with backup

  1. #1

    Default compression issue with backup

    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]root@vega:/backups/mysql/vega.daily[/email]# 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 !

  2. #2

    Default

    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

  3. #3

    Default

    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.

  4. #4
    Join Date
    Sep 2014
    Posts
    2

    Default

    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!

    Quote Originally Posted by shakalandy View Post
    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.

  5. #5
    Join Date
    Sep 2014
    Posts
    2

    Default

    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";

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •