February 3rd, 2010, 05:28 PM
ZRM 2.2 released
ZRM 2.2 includes bug fixes and following features:
- Support for pre-restore and post-restore plugins
- Support for mixed replication mode binary logs
- Support for producing html output after parsing binary logs
- Support for mail notification policy
- Added support for exclude pattern for databases and tables in the backup set
Documentation/Man pages are available at
Images can be downloaded from [url]http://www.zmanda.com/download-zrm.php[/url]
February 6th, 2010, 07:11 PM
Have a few problems with 2.2
If I run the following command:
mysql-zrm-reporter --destination /data2/backup --latest --fields innodb_logs,innodb_data
backup_set innodb_logs innodb_data
set1 ---- ----
Of course, in the tar file itself, is in fact the innodb data and log files.
Could the report be this way because the backup is compressed?
Or, perhaps it's because we use innodb_file_per_table = 1?
Or, some other reason?
I unzipped the backup, and, did a tar tvf, and, the innodb files were there with the standard names.
Secondly, I don't believe the times to be accurate in the reports. compressed_encrypt_time was reported as 12 minutes, when in fact, it took over an hour (monitored with top, bzip2 used 100% cpu, tar used < 1%). So, I suspect it is counting that as backup (tar) time, not, bzip2 time. Without bzip, the backup would have completed almost an hour sooner, so, 12 minutes is not correct. This is a snapshot backup via copy socket of remote server, so, perhaps the correct time is not really possible.
But it is still strange. backup_time was 01:47:37, which I know is 1 hour+, compress_encrypt_time was 12:39:00, is that 12 hours? If so, obviously, it can't take longer than the backup!
From the log file:
Sat Feb 06 16:31:45 2010: shivafull:backup:INFO: PHASE START: Compression/Encryption
Sat Feb 06 17:47:20 2010: shivafull:backup:INFO: compress=/usr/bin/bzip2
Sat Feb 06 17:47:20 2010: shivafull:backup:INFO: backup-size-compressed=1.85 GB
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: PHASE END: Compression/Encryption
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: read-locks-time=00:00:01
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: flush-logs-time=00:00:00
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: compress-encrypt-time=12:39:00
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: backup-time=01:47:37
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: backup-status=Backup succeeded
Sat Feb 06 17:47:39 2010: shivafull:backup:INFO: Backup succeeded
February 8th, 2010, 12:20 PM
1. mysql-zrm-reporter command gets data from the index files. Can you please check the ///index has these entries?
2. compress_encrypt_time does include the "tar" time. ZRM does creates tar archive of all files and sends out the output to compress and encrypt programs if specified. So, compress and encrypt programs are running for this time.
3. 12:39:00 appears to be a bug. Can you please set "verbose=1" and attach /var/log/mysql-zrm/mysql-zrm.log?
February 8th, 2010, 01:29 PM
Ok, attached the verbose log from the incremental today. Obviously, the compress time is way off!
In the index file for the report which did not show innodb_logs, or innodb_data, is:
Your syntax requires the underscore, but, it had a - in the file. Could that be it?
If I wanted to use the backup to start MySQL replication by restoring on another machine, this line is in the index:
Would I use that in the change master to command?
February 8th, 2010, 05:10 PM
Thanks for the logs. We will get back to you.
Please try with "-". The parameter should match the index file contents.
next-binlog can be used for change master.
February 8th, 2010, 09:56 PM
I cannot use - instead of _ as it then gives a syntax error, and, the help text comes up, and, the help text shows underscore! So, I think the mysql-zrm-reporter command has an error in it as it wants you to type underscore, yet, the data is a dash.
If next-binlog can be used for change master to, then, what position? I don't see it in the file.
March 10th, 2011, 05:22 AM
You can install it in MacBook provided you have perl. To backup MySQL servers running
on Mac, backup from another Linux machine.
June 6th, 2011, 12:52 PM
@ the website, i found the chart showing the diffs bet community and enterprise ZRM.
what's not clear is, which versions does that refer to? community 2.2.x i guess, but enterprise 2.2.x or 3.3.x?
other way of asking, what does the version# disparity between current community & enterprise represent? something real? or just numbering randomness?
June 6th, 2011, 01:12 PM
Community 2.2 and Enterprise 3.3. The version numbers between community and enterprise do not match and represents real differences.
June 6th, 2011, 01:23 PM
is there, then, a Community 3.3 in the works?