innobackupex is derived from the same GPL and open-source
wrapper script that InnoDB Hot Backup uses, it does not execute
xtrabackup binary does not execute or link to
can use Percona XtraBackup without any license; it is completely separate
from InnoDB Hot Backup.
Because innobackupex is a patched version of Oracle ’s innobackup script (now renamed to mysqlbackup), it is quite similar in some ways, and familiarity with innobackup might be helpful.
Aside from the options for specific features of innobackupex, the main differences are:
See The innobackupex Option Reference for more details.
Zmanda Recovery Manager is a commercial tool that uses Percona XtraBackup for Non-Blocking Backups:
“ZRM provides support for non-blocking backups of MySQL using |Percona XtraBackup|. ZRM with |Percona XtraBackup| provides resource utilization management by providing throttling based on the number of IO operations per second. |Percona XtraBackup| based backups also allow for table level recovery even though the backup was done at the database level (needs the recovery database server to be |Percona Server| with XtraDB).”
In most of the cases this is due to not having install the required libraries (and version) by xtrabackup. Installing the GCC suite with the supporting libraries and recompiling xtrabackup will solve the issue. See Compiling and Installing from Source Code for instructions on the procedure.
In case the
ib_log files are located in different
directories outside of the datadir, you will have to put them in their proper
place after the logs have been applied.
This usually happens when database being backed up contains large amount of
files and Percona XtraBackup can’t open all of them to create a successful
backup. In order to avoid this error the operating system should be configured
appropriately so that Percona XtraBackup can open all its files. On Linux,
this can be done with the
ulimit command for specific backup session or by
/etc/security/limits.conf to change it globally (NOTE:
the maximum possible value that can be set up is
1048576 which is a
hard-coded constant in the Linux kernel).
To prevent creating corrupted backups when running DDL operations, Percona XtraBackup aborts if it detects that redo logging is disabled. In this case, the following error is printed:
[FATAL] InnoDB: An optimized (without redo logging) DDL operation has been performed. All modified pages may not have been flushed to the disk yet. Percona XtraBackup will not be able to take a consistent backup. Retry the backup operation.
Redo logging is disabled during a sorted index build
To avoid this error, Percona XtraBackup can use metadata locks on tables while they are copied:
--lock-ddloption that issues
LOCK TABLES FOR BACKUP.
LOCK TABLES FOR BACKUPis not supported, you can block DDL for each table before XtraBackup starts to copy it and until the backup is completed using the
For general inquiries, please send us your question and someone will contact you.