PDA

View Full Version : Innodb : integration with ibbackup? raw innodb ?



trrrrev
February 6th, 2007, 03:22 PM
Greetings,

First of Zmanda glad u exist. I am tired or extending my perl scripts. However after a brief evaluation I have one major obstacle to adoting Zmanda..... raw innodb backups.

Currently each backup exists on its own logical volume and volume group. When I restore a backup I actually export the vg and import on the machine to restore. This means I can restore very large data sets quickly. With mysqldump backups you cannot avoid the reading of the entire database and the writing out ( and the innodb processing of every statement, is the Zmanda restore multi-threaded?). This is a biggie.

Solution 1 :

Why can't we have a raw copy of innodb tables or any other storage engines by server shutdown?

Solution 2 :

What about ibbackup?

ibbackup is a powerful tool, that does not handle replication checkpointing but I am sure you could figure a solution. This would be a great addition to the Zmanda backup arsenal.

Oh yeah, any plans for Solaris?

Cheers,

Trev

paddy
February 11th, 2007, 11:14 AM
Solution 1:

Server shutdown would of course, work. ZRM's goal is to create consistent backup of the database with minimal impact to the server. Database server shutdown is usually not acceptable to many users.

Solution 2:

Yes. ibbackup can be integrated with ZRM for MySQL as one of the backup methods for InnoDB. This is in the roadmap (Please see http://mysqlbackup.zmanda.com). This will only work for users who have bought the ibbackup license.

ZRM on Solaris is also in the works.

Can you please explain how you use VG export/import to restore backups? You still need to recreate the database from the backup image.

Thanks,
Paddy

trrrrev
February 12th, 2007, 02:10 PM
Hello Paddy,

Good to know its on the roadmap. Although I am suprised that server shutdown backup is not supported. Would have thought most MySQL backups are from designated backup slaves.

About vg.

First you need a storage network.
Then take a raw backup onto the designated backup vg
export the backup vg.
remove scsi devices associated with vg lun devices
Change the lun/luns in the backup vg to be seen by the new host.
detect luns on new machine
Import the backup vg on the new host.
For myisam I just make symlinkgs between the datadir and the actual database contents. For innodb I would have to copy in the ibdata1 and log files too. Then apply as many logfiles as I have since last backup.

problem with this setup is the need for another production performance level set of storage and having to copy the last backup before it is overwritten by the next backup. In addition if you want to hold several backups in this hot restore state it can be expensive.

The most useful application of this setup is when tables are accidentaly dropped.