PDA

View Full Version : ZRM raw backup and restore strategy for InnoDB only databases



nuvan
January 7th, 2016, 10:29 AM
Hello, experts.

I'm trying to build a raw backup and restore strategy for an InnoDB only DB, hosted on a CentOS 6.6 machine with LVM.

Currently, I use a logical backup strategy but restore time is unacceptable since we host databases that can span up to 5 TB of data. The smallest one contains 1.5 TB and takes more than 24 hours to restore. Last time that I've attempted a raw backup I had a mix of MyISAM and InnoDB tables and thought that, that mix did not permit such type of backup.

Apparently, I'm having success with my raw backup strategy, but when I restore in a similar machine and attempt to access any restored table I get the message "Table '<db>.<table>' doesn't exist.".
I've roamed the internet, and the best match that I've found is a StackOverflow question with an answer that points out when using "innodb_file_per_table" we need to copy the ibdata and iblogfiles also.

Here:
http://stackoverflow.com/questions/7759170/mysql-table-doesnt-exist-but-it-does-or-it-should

So, I guess that I need to include some option to backup those files also since when I execute my restore procedure, those files don't have the same size on my destination server. Nevertheless, the StackOverflow question refers that this is needed just to dump the tables with mysqldump, and it isn't a solution to restore data in a production environment.

Can someone help me with the adequate zrm backup and restore options/flags that I need to use to achieve a raw backup and restore strategy with the previously mentioned configuration?

I'm using zrm3.0 and MySQL 5.6 hosted on a CentOS 6.6 (as stated before) machine.

Thanks in advance.
Nuno Valente.

nuvan
January 11th, 2016, 02:35 AM
After iterating over all available Q&As I've found this one:

https://forums.zmanda.com/showthread.php?5193-Support-Mysql-5-6-x

My problem was that mysql bin logs weren't copied as they should.

I couldn't apply the patch directly since "patch" yielded that the file wasn't correctly structured but after finding the target ZRM code file I've edited inline and solved the problem.

Regards,
Nuno Valente.



Hello, experts.

I'm trying to build a raw backup and restore strategy for an InnoDB only DB, hosted on a CentOS 6.6 machine with LVM.

Currently, I use a logical backup strategy but restore time is unacceptable since we host databases that can span up to 5 TB of data. The smallest one contains 1.5 TB and takes more than 24 hours to restore. Last time that I've attempted a raw backup I had a mix of MyISAM and InnoDB tables and thought that, that mix did not permit such type of backup.

Apparently, I'm having success with my raw backup strategy, but when I restore in a similar machine and attempt to access any restored table I get the message "Table '<db>.<table>' doesn't exist.".
I've roamed the internet, and the best match that I've found is a StackOverflow question with an answer that points out when using "innodb_file_per_table" we need to copy the ibdata and iblogfiles also.

Here:
http://stackoverflow.com/questions/7759170/mysql-table-doesnt-exist-but-it-does-or-it-should

So, I guess that I need to include some option to backup those files also since when I execute my restore procedure, those files don't have the same size on my destination server. Nevertheless, the StackOverflow question refers that this is needed just to dump the tables with mysqldump, and it isn't a solution to restore data in a production environment.

Can someone help me with the adequate zrm backup and restore options/flags that I need to use to achieve a raw backup and restore strategy with the previously mentioned configuration?

I'm using zrm3.0 and MySQL 5.6 hosted on a CentOS 6.6 (as stated before) machine.

Thanks in advance.
Nuno Valente.