meskyanichi/backup — pull request #547 by chesterbr (2014-06-03 01:52:48+00:00)
Title: Innobackupex

Implements [Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/2.1/) support (a more feasible alternative to `mysqldump` for large databases).

It does so by enabling the [`innobackupex`](http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html) utility and adding some options to the MySQL database model:

- **`backup_engine`**: set to `:innobackupex` to use it; defaults to `:mysqldump` (for drop-in backwards compatibility).

- **`prepare_options`** (optional): XtraBackup backups are done in two steps: *copy* and *prepare* (see below). In the same fashion that `additional_options` (which already existed for `mysqldump`) are applied to the copy command, these are applied to the prepare one.

- **`sudo_user`** (optional): if set, will run the commands on behalf of that user (e.g., `root`). It also works for `mysqldump` backups.

- **`verbose`** (optional): `innobackupex` outputs operational messages to stderr by default, causing a warning even on successful completion, so it is suppressed by default. Setting this paremeter to `true` will display those (which is useful during implementation/debugging), but will log/notify the bacup as "successful with warnings".

**Implementation notes**:

Percona XtraBackup needs two steps to have readily restore-able backups:

1) [Creating](https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/creating_a_backup_ibk.html) the backup by copying the;
2) [Preparing](https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html) it for restoring (by applying any pending transaction logs, which will leave it on a consistent state).

Some admins prefer to do preparation as an offline process on a separate machine, whereas others don't bother to prepare at all (and only find out they need this time-consuming step during a disaster recovery!)

To make things simple, this implementation will create the backup, then prepare (apply the logs), then stream the tar-ed result (allowing it to work with the gem's existing compressors/splitters/storages/etc.). This is very convenient, but has two caveats:

- It requires extra space during the backup process (for the temporary database that will be prepared)

- The backup is generated as a tar-ed directory within the specified compression schema (which typically will be another .tar.gz). A command like the one below will generate the restore-able files while copying them from wherever they are stored into the machine where the database will be restored:

```
|
tar xf - --to-stdout mysql/databases/MySQL.tar.gz |
tar -xzf -
```

(closes #450)