Percona XtraBackup

Percona XtraBackup is an open source, portable, free and non-blocking command-line software that acts as a standalone backup solution for the well-known XtraDB and InnoDB storage engines. It features automatic backup verification and offers higher uptimes than other similar products.

The program is fully compatible with both MySQL and MariaDB database servers, and it is heavily used by the popular Facebook social networking service for incremental backups. It’s designed to solve real-world problems when backing up very large, heavily loaded databases.

Features at a glance

Key features include the ability to perform backups online while avoiding interrupting your database, the ability to perform streaming backups to another server, as well as the ability to perform incremental backups while saving money on disk space and network bandwidth.

With Percona XtraBackup your backups will complete reliably and quickly. You can also create new replication slaves easily, perform advanced analysis of data and index files, and move individual tables between servers without restarting, a task that requires XtraDB for import.

The software supports various MySQL flavors, among which we can mention MySQL, MariaDB, MariaDB Galera Cluster, Percona Server and Percona XtraDB Cluster. It also supports all GNU/Linux operating systems, running well on 32-bit and 64-bit hardware.

Among other features, we can mention blocking MyISAM backups, full compressed backups, incremental compressed backups, fast incremental backups, incremental backups with archived logs and REDO log only, parallel local backups, copy-back, apply-log, compression and encryption.

Furthermore, is also comes with rsync support for state-of-the-art file synchronization, individual tables export, enhanced FTWRL handling, compact backups, point-in-time recovery support, offline backups, as well as support for cloud backups.

Under the hood and availability

Percona XtraBackup is written in the C, C++ and Perl programming languages. It’s a command-line software, distributed as pre-built binary packages for Ubuntu, Debian and Red Hat Enterprise Linux distributions, as well as universal binary and source archives.

What is new in this release:

• Percona XtraBackup would segfault during the prepare phase of certain FTS pages. Bug fixed #1460138.
• Fixed compilation error due to missing dependency caused by the upstream bug #77226. Bug fixed #1461129.
• Regression introduced by fixing a bug #1403237 in Percona XtraBackup 2.2.8 could cause xtrabackup to read a redo log from incorrect offset which would cause an assertion. Bug fixed #1464608.
• Fixed uninitialized current_thd thread-local variable. This also completely fixes bug #1415191. Bug fixed #1467574.
• After the release of Percona XtraBackup 2.2.11, innobackupex issues a FLUSH TABLE before running the FLUSH TABLES WITH READ LOCK. While it will help the backups in some situation, it also implies that the FLUSH TABLE will be written to the binary log. On MariaDB 10.0 with GTID enabled, when backup was taken on the slave, this altered the GTID of that slave and Percona XtraBackup didn't see the correct GTID anymore. Bug fixed #1466446 (Julien Pivotto).
• RPM compilation of Percona XtraBackup was still requiring bzr. Bug fixed #1466888 (Julien Pivotto).
• Compiling Percona XtraBackup RPMs with XB_VERSION_EXTRA option would create an incorrect RPM version. Bug fixed #1467424 (Julien Pivotto).
• Percona XtraBackup would complete successfully even when redo log wasn't copied completely. This means that backup were considered successful even when they were corrupt. Bug fixed #1470847.
• In rare cases when there are two or more tablespaces with the same ID in the data directory, xtrabackup picks up the first one by lexical order, which could lead to losing the correct table. Bug fixed #1475487.
• Percona XtraBackup was missing revision_id in binaries. Bug fixed #1394174.

What is new in version 2.4.8:

• Percona XtraBackup would segfault during the prepare phase of certain FTS pages. Bug fixed #1460138.
• Fixed compilation error due to missing dependency caused by the upstream bug #77226. Bug fixed #1461129.
• Regression introduced by fixing a bug #1403237 in Percona XtraBackup 2.2.8 could cause xtrabackup to read a redo log from incorrect offset which would cause an assertion. Bug fixed #1464608.
• Fixed uninitialized current_thd thread-local variable. This also completely fixes bug #1415191. Bug fixed #1467574.
• After the release of Percona XtraBackup 2.2.11, innobackupex issues a FLUSH TABLE before running the FLUSH TABLES WITH READ LOCK. While it will help the backups in some situation, it also implies that the FLUSH TABLE will be written to the binary log. On MariaDB 10.0 with GTID enabled, when backup was taken on the slave, this altered the GTID of that slave and Percona XtraBackup didn't see the correct GTID anymore. Bug fixed #1466446 (Julien Pivotto).
• RPM compilation of Percona XtraBackup was still requiring bzr. Bug fixed #1466888 (Julien Pivotto).
• Compiling Percona XtraBackup RPMs with XB_VERSION_EXTRA option would create an incorrect RPM version. Bug fixed #1467424 (Julien Pivotto).
• Percona XtraBackup would complete successfully even when redo log wasn't copied completely. This means that backup were considered successful even when they were corrupt. Bug fixed #1470847.
• In rare cases when there are two or more tablespaces with the same ID in the data directory, xtrabackup picks up the first one by lexical order, which could lead to losing the correct table. Bug fixed #1475487.
• Percona XtraBackup was missing revision_id in binaries. Bug fixed #1394174.

What is new in version 2.4.7:

• Percona XtraBackup would segfault during the prepare phase of certain FTS pages. Bug fixed #1460138.
• Fixed compilation error due to missing dependency caused by the upstream bug #77226. Bug fixed #1461129.
• Regression introduced by fixing a bug #1403237 in Percona XtraBackup 2.2.8 could cause xtrabackup to read a redo log from incorrect offset which would cause an assertion. Bug fixed #1464608.
• Fixed uninitialized current_thd thread-local variable. This also completely fixes bug #1415191. Bug fixed #1467574.
• After the release of Percona XtraBackup 2.2.11, innobackupex issues a FLUSH TABLE before running the FLUSH TABLES WITH READ LOCK. While it will help the backups in some situation, it also implies that the FLUSH TABLE will be written to the binary log. On MariaDB 10.0 with GTID enabled, when backup was taken on the slave, this altered the GTID of that slave and Percona XtraBackup didn't see the correct GTID anymore. Bug fixed #1466446 (Julien Pivotto).
• RPM compilation of Percona XtraBackup was still requiring bzr. Bug fixed #1466888 (Julien Pivotto).
• Compiling Percona XtraBackup RPMs with XB_VERSION_EXTRA option would create an incorrect RPM version. Bug fixed #1467424 (Julien Pivotto).
• Percona XtraBackup would complete successfully even when redo log wasn't copied completely. This means that backup were considered successful even when they were corrupt. Bug fixed #1470847.
• In rare cases when there are two or more tablespaces with the same ID in the data directory, xtrabackup picks up the first one by lexical order, which could lead to losing the correct table. Bug fixed #1475487.
• Percona XtraBackup was missing revision_id in binaries. Bug fixed #1394174.

What is new in version 2.4.6:

• Percona XtraBackup would segfault during the prepare phase of certain FTS pages. Bug fixed #1460138.
• Fixed compilation error due to missing dependency caused by the upstream bug #77226. Bug fixed #1461129.
• Regression introduced by fixing a bug #1403237 in Percona XtraBackup 2.2.8 could cause xtrabackup to read a redo log from incorrect offset which would cause an assertion. Bug fixed #1464608.
• Fixed uninitialized current_thd thread-local variable. This also completely fixes bug #1415191. Bug fixed #1467574.
• After the release of Percona XtraBackup 2.2.11, innobackupex issues a FLUSH TABLE before running the FLUSH TABLES WITH READ LOCK. While it will help the backups in some situation, it also implies that the FLUSH TABLE will be written to the binary log. On MariaDB 10.0 with GTID enabled, when backup was taken on the slave, this altered the GTID of that slave and Percona XtraBackup didn't see the correct GTID anymore. Bug fixed #1466446 (Julien Pivotto).
• RPM compilation of Percona XtraBackup was still requiring bzr. Bug fixed #1466888 (Julien Pivotto).
• Compiling Percona XtraBackup RPMs with XB_VERSION_EXTRA option would create an incorrect RPM version. Bug fixed #1467424 (Julien Pivotto).
• Percona XtraBackup would complete successfully even when redo log wasn't copied completely. This means that backup were considered successful even when they were corrupt. Bug fixed #1470847.
• In rare cases when there are two or more tablespaces with the same ID in the data directory, xtrabackup picks up the first one by lexical order, which could lead to losing the correct table. Bug fixed #1475487.
• Percona XtraBackup was missing revision_id in binaries. Bug fixed #1394174.

What is new in version 2.4.3:

• Percona XtraBackup would segfault during the prepare phase of certain FTS pages. Bug fixed #1460138.
• Fixed compilation error due to missing dependency caused by the upstream bug #77226. Bug fixed #1461129.
• Regression introduced by fixing a bug #1403237 in Percona XtraBackup 2.2.8 could cause xtrabackup to read a redo log from incorrect offset which would cause an assertion. Bug fixed #1464608.
• Fixed uninitialized current_thd thread-local variable. This also completely fixes bug #1415191. Bug fixed #1467574.
• After the release of Percona XtraBackup 2.2.11, innobackupex issues a FLUSH TABLE before running the FLUSH TABLES WITH READ LOCK. While it will help the backups in some situation, it also implies that the FLUSH TABLE will be written to the binary log. On MariaDB 10.0 with GTID enabled, when backup was taken on the slave, this altered the GTID of that slave and Percona XtraBackup didn't see the correct GTID anymore. Bug fixed #1466446 (Julien Pivotto).
• RPM compilation of Percona XtraBackup was still requiring bzr. Bug fixed #1466888 (Julien Pivotto).
• Compiling Percona XtraBackup RPMs with XB_VERSION_EXTRA option would create an incorrect RPM version. Bug fixed #1467424 (Julien Pivotto).
• Percona XtraBackup would complete successfully even when redo log wasn't copied completely. This means that backup were considered successful even when they were corrupt. Bug fixed #1470847.
• In rare cases when there are two or more tablespaces with the same ID in the data directory, xtrabackup picks up the first one by lexical order, which could lead to losing the correct table. Bug fixed #1475487.
• Percona XtraBackup was missing revision_id in binaries. Bug fixed #1394174.

What is new in version 2.2.9:

• Percona XtraBackup 2.1.2 would hang when performing State Snapshot Transfer. Bug fixed #1182698.

What is new in version 2.2.8:

• Percona XtraBackup 2.1.2 would hang when performing State Snapshot Transfer. Bug fixed #1182698.

What is new in version 2.1.2:

• Bugs Fixed:
• Using Perl's DBD::MySQL package for server communication instead of spawning the MySQL command line client introduced a regression which caused innobackupex -galera-info option to fail. Bug fixed #1180672.
• The format of xtrabackup_galera_info was missing the ‘:' separator between the values of wsrep_local_state_uuid and wsrep_last_committed. Bug fixed #1181222.
• innobackupex automatic version detection did not work correctly for latest Percona Server and MySQL 5.1 releases which could cause innobackupex to fail. Bugs fixed #1181092, #1181099 and #1180905.
• When backing up a server that is not a replication slave with the innobackupex -slave-info option, innobackupex failed with a fatal error. Replaced the fatal error with a diagnostic message about innobackupex -slave-info being ignored in such a case. Bug fixed #1180662.
• Low values for wait_timeout on the server could cause server to close the connection while backup is being taken. Fixed by setting the bigger value for wait_timeout option on the server to prevent server from closing connections if the global wait_timeout value is set too low. Bug fixed #1180922.
• Other bug fixes: bug fixed #1177182.

What is new in version 2.0.7:

• New Features:
• This version of Percona XtraBackup has implemented full support for new MySQL 5.6 features (GTID, remote/transportable tablespaces, separate undo tablespace, 5.6-style buffer pool dump files).
• Percona XtraBackup has implemented support for the InnoDB Buffer Pool Preloading introduced in MySQL 5.6. Starting with MySQL 5.6 buffer pool dumps can be produced and loaded for faster server warmup after the start. This feature is similar to the Dump/Restore of the Buffer Pool in Percona Server. MySQL 5.6 buffer pool dump is copied into backup directory during the backup stage. During the copy back stage (restore) it is copied back to data directory. After the backup is restored buffer pool dump can be loaded by the server either automatically on startup or on demand.
• Time interval between checks done by log copying thread is now configurable by innobackupex -log-copy-interval. Making the interval configurable allows to reduce the time between checks which can prevent XtraBackup failures that are caused by the log records in the transactional log being overwritten before they are copied by the log copying thread.
• Percona XtraBackup now stores the GTID value in the xtrabackup_binlog_info when doing the backup of MySQL and Percona Server 5.6 with the GTID mode enabled. Example of how this information can be used to create/restore a slave can be found in this blogpost.
• Percona XtraBackup option xtrabackup -export now supports transportable tablespaces introduced in MySQL 5.6. This option can be used to produce 5.6-style metadata files, that can be imported by ALTER TABLE IMPORT TABLESPACE on MySQL and Percona Server 5.6 as described in Exporting and Importing Tables guide.
• Bugs Fixed:
• xtrabackup_56 binary was present in rpm and deb packages, but it was missing from the source .tar.gz package. Fixed by adding the missing binary to .tar.gz as well. Bug fixed #1158948.
• innobackupex could crash when taking the 5.6 backup due to linking the wrong SSL library. Bug fixed #1168540.
• Percona XtraBackup would crash when preparing the 5.6 backup with partitioned tables. Bug fixed #1169169.
• Tables that were dropped between taking a full backup and an incremental one were present in the full backup directory, and were not removed when incremental backups has been merged. Fixed by removing files corresponding to tables that are missing in the incremental backup directory. Bug fixed #856400.
• Percona XtraBackup would leave stale xtrabackup_tmp* files in the datadir after applying incremental backups. Bug fixed #1079135.
• Fixed couple of warnings found in innobackupex when all warnings have been made FATAL. Bug fixed #1116177.
• If there are thousands of tables and slow IO then XtraBackup can spend a lot of time opening all the tablespaces. Optimization has been implemented and XtraBackup now avoids loading non-relevant tablespaces when partial backup is being taken which speeds up the backup process. Bug fixed #1130145.
• Percona XtraBackup didn't initialize per-thread data in the log copying thread which could cause XtraBackup to crash. Bug fixed #1166888.
• Package dependency has been changed from abstract mysql to real /usr/bin/mysql file, because rpm packages from Oracle no longer satisfied mysql dependency which is required by the XtraBackup rpms. Bug fixed #1095972.
• Percona XtraBackup would fail when preparing the MySQL 5.6 backup if the log files were bigger than 4G on the source server. Bug fixed #1164979.
• Due to different implementation in MySQL 5.6 error messages were not printed to stderr directly. Because of that all InnoDB error or diagnostic messages are never printed by xtrabackup_56. Bug fixed #1169971.
• innobackupex would still run with FLUSH TABLES WITH READ LOCK even if xtrabackup would fail when copying logs. Fixed by terminating xtrabackup process immediately on log copying failure. Bug fixed #1170806.
• innobackupex would fail if the SQL_MODE was set to ANSI_QUOTES. Bug fixed #945161.
• Missing space_id from *.ibd.meta would lead to assertion. Fixed by replacing the assertion with the error message. Bug fixed #1112224.
• Fixed the typo in the innobackupex error output. Bug fixed #1157225.
• When building from source innodb56 target didn't have an option to disable DTrace like innodb55 has. Fixed by adding -DENABLE_DTRACE=OFF build option for innodb56 as well. Bug fixed #1169509.
• innobackupex wasn't handling the innodb_data_file_path option which could cause backup to fail. Bug fixed #1169726.
• For the Debian and the Linux binaries, the --version message which should include the revision was showing "undefined". Bug fixed #1171721.
• Redundant code has been removed from xtrabackup.cc. Bug fixed #1162765.
• Other bug fixes: bug fixed #1158154, bug fixed #1170340, bug fixed #1088309, bug fixed #1088307.

What is new in version 2.0.6:

• New Features:
• XtraBackup has implemented basic support for MySQL 5.6, Percona Server 5.6 and MariaDB 10.0. Basic support means that these versions are are recognized by XtraBackup, and that backup/restore works as long as no 5.6-specific features are used (such as GTID, remote/transportable tablespaces, separate undo tablespace, 5.6-style buffer pool dump files).
• Bugs Fixed:
• Individual InnoDB tablespaces with size less than 1MB were extended to 1MB on the backup prepare operation. This led to a large increase in disk usage in cases when there are many small InnoDB tablespaces. Bug fixed #950334 (Daniel Frett, Alexey Kopytov).
• Fixed the issue that caused databases corresponding to inaccessible datadir subdirectories to be ignored by XtraBackup without warning or error messages. This was happening because InnoDB code silently ignored datadir subdirectories it could not open. Bug fixed #664986 (Alexey Kopytov).
• Under some circumstances XtraBackup could fail to copy a tablespace with a high --parallel option value and a low innodb_open_files value. Bug fixed #870119 (Alexey Kopytov).
• Fix for the bug #711166 introduced a regression that caused individual partition backups to fail when used with --include option in innobackupex or the --tables option in xtrabackup. Bug fixed #1130627 (Alexey Kopytov).
• innobackupex didn't add the file-per-table setting for table-independent backups. Fixed by making XtraBackup auto-enable innodb_file_per_table when the --export option is used. Bug fixed #930062 (Alexey Kopytov).
• Under some circumstances XtraBackup could fail on a backup prepare with innodb_flush_method=O_DIRECT. Bug fixed #1055547 (Alexey Kopytov).
• innobackupex did not pass the --tmpdir option to the xtrabackup binary resulting in the server's tmpdir always being used for temporary files. Bug fixed #1085099 (Alexey Kopytov).
• XtraBackup has improved the error reporting for unrecognized server versions. Bug fixed #1087219 (Alexey Kopytov).
• Fixed the missing rpm dependency for Perl Time::HiRes package that caused innobackupex to fail on minimal CentOS installations. Bug fixed #1121573 (Alexey Bychko).
• innobackupex would fail when --no-lock and --rsync were used in conjunction. Bug fixed #1123335 (Sergei Glushchenko).
• Fix for the bug #1055989 introduced a regression that caused xtrabackup_pid file to remain in the temporary dir after execution. Bug fixed #1114955 (Alexey Kopytov).
• Unnecessary debug messages have been removed from the XtraBackup output. Bug fixed #1131084 (Alexey Kopytov).
• Other bug fixes: bug fixed #1153334 (Alexey Kopytov), bug fixed #1098498 (Laurynas Biveinis), bug fixed #1132763 (Laurynas Biveinis), bug fixed #1142229 (Laurynas Biveinis), bug fixed #1130581 (Laurynas Biveinis).

What is new in version 2.0.5:

• New Features:
• New option --defaults-extra-file has been introduced. This option specifies from what extra file to read the default MySQL options before the standard defaults-file. It can be used to load the user/password combination for the dedicated backup user from a separate configuration file, to avoid storing it in the crontab or a script somewhere in the system.
• Bugs Fixed:
• In case of streaming backups, innobackupex would resume the XtraBackup process and then wait for it to finish before running UNLOCK TABLES. This caused database to be unnecessarily locked with FLUSH TABLES WITH READ LOCK. Innobackupex now waits only till log copying is finished to unlock the databases. Bug fixed #1055989 (Alexey Kopytov).
• innobackupex error messages referencing the data directory have been extended to show the path of the data directory mentioned in the error message. Bug fixed #1089375 (Hartmut Holzgraefe).
• Partitioned tables were not correctly handled by the --databases, --include, --tables-file options of innobackupex, and by the --tables and --tables-file options of XtraBackup. Fixed by removing the partition suffix (#P#...) before doing filtering. Bug fixed #711166 (Sergei Glushchenko).
• When built-in compression was used, XtraBackup was doing unbuffered writes to the destination file or stream in very small chunks which in return caused inefficient I/O. Fixed by using a 1M buffer for output similar to the uncompressed backups. Bug fixed #1095249 (Alexey Kopytov).
• Unnecessary long sleep() in innobackupex lead to FLUSH TABLES WITH READ LOCK taking too long. Fixed by replacing 2 seconds sleep interval with 100 milliseconds one. Bug fixed #1095551 (Sergei Glushchenko).
• If innobackupex would crash it would leave the xtrabackup_suspended file on the filesystem. This could then cause innobackupex to think XtraBackup has suspended itself the moment it started, and then when XtraBackup actually does suspend itself, innobackupex would wait for it to end and wouldn't re-remove the suspend file, leading to a wait deadlock. Fixed by removing the stale xtrabackup_suspended file when innobackupex is started. Bug fixed #1007446 (George Ormond Lorch III).
• innobackupex would fail to recognize MariaDB 5.2 and MariaDB 5.3. Fixed by augmenting version checks in innobackupex. Bug fixed #733665 (Daniel van Eeden, Alexey Kopytov).
• Other bug fixes: bug fixed #924492 (Alexey Kopytov), bug fixed #1097158 (Alexey Kopytov), bug fixed #1081882 (Alexey Kopytov), bug fixed #1096584 (Alexey Kopytov).

What is new in version 1.6.7:

• Bugs Fixed:
• xtrabackup_binary was not included in tar archive when streaming, instead it was written to the current directory. This could lead to a wrong xtrabackup binary being used when preparing backups created with the --stream or --remote-host options. Bugs fixed #723318 and #787988 (Stewart Smith).
• FLUSH TABLES WITH READ LOCK was not used when creating incremental backups, which could lead to inconsistent backups when updates to non-InnoDB tables or DDL statements on any tables occurred during the backup process. Bug fixed #771981 (Alexey Kopytov).
• Option --safe-slave-backup was resulting in incorrect binlog info, because in some cases innobackupex confused the response from SHOW SLAVE STATUS with the one from SHOW MASTER STATUS. Bug fixed #977101 (Alexey Kopytov).
• innodb_data_file_path was not written to backup-my.cnf, this was a regression introduced in XtraBackup 1.6.5. Bug fixed #983685 (Sergei Glushchenko).
• Fixed spurious test suite failures with grep 2.10. Bug fixed #996483 (Alexey Kopytov).
• When innobackupex was running with --apply-log, it was reading configuration from the server configuration file instead of backup-my.cnf in backup directory. Bug fixed #996493 (Sergei Glushchenko).
• innobackupex could copy files to a wrong directory when merging an incremental backup to a full one. Bug fixed #1002688 (Alexey Kopytov).
• XtraBackup binary was leaking file descriptors on --backup. This was fixed by reusing the existing file descriptor so no leak occurs. Bug fixed #713267 (Alexey Kopytov).

What is new in version 2.0.4:

• Bugs Fixed:
• Bug fix for #932623 introduced the regression in XtraBackup 2.0.2 which caused incremental backups to fail because the init parameter values were not normalized to the values used inside InnoDB. Bug fixed #1062684 (Sergei Glushchenko).
• Bug fix for #932623 introduced the regression in XtraBackup 2.0.2 because it didn't take the separate doublewrite tablespace into an account. Bug fixed #1066843 (Sergei Glushchenko).
• XtraBackup was handling the separate doublewrite buffer file incorrectly. File path of the doublewrite buffer wasn't added to the backup-my.cnf and after the restore old doublewrite buffer file was used instead of one made during the prepare stage. Bug fixed #1068470 (Sergei Glushchenko).
• XtraBackup now accepts the --innodb=force option, previously it would throw an error if the option was set. Bug fixed #528752 (Laurynas Biveinis).
• Option safe-slave-backup wasn't working correctly. Bug fixed #887803 (Alexey Kopytov).
• In case safe-slave-backup-timeout was reached when using the safe-slave-backup option, SQL_THREAD was left in stopped state causing the slave thread to lag behind. This was fixed by checking the initial SQL_THREAD state and starting it before terminating with a timeout error and starting the SQL_THREAD only if it was running initially. Bug fixed #1037379 (Alexey Kopytov).
• XtraBackup would fail on --apply-log when filesystem didn't support Linux AIO. Bug fixed #1065561 (Alexey Kopytov).
• XtraBackup binary would ignore innodb_use_native_aio when it's specified either in my.cnf or as a command line option. Bug fixed #1068459 (Alexey Kopytov).
• XtraBackup would print a warning message during the prepare stage about innodb_file_io_threads being deprecated, even if the variable wasn't set. Bug fixed #1068485 (Alexey Kopytov).
• XtraBackup Galera tests can now be run concurrently. Bug fixed #1077800 (Stewart Smith).

What is new in version 2.0.3:

• New Features:
• innobackupex now supports new -move-back option that can be used instead of -copy-back in case there isn't enough free disk space on the server to copy files. As this option removes backup files, it must be used with caution.
• Bugs Fixed:
• Symlink for innobackupex-1.5.1 binary has been broken in the previous version of XtraBackup. Bug fixed #1038198 (Ignacio Nin).
• XtraBackup 2.0.2 was not backwards compatible which caused incremental backups created with previous versions to fail on prepare. Bug fixed #1038127 (Sergei Glushchenko).
• Fix for bug #1022562 introduced a regression that may potentially lead to a 5x increase in disk space occupied by incremental backups. Bug fixed #1043762 (Laurynas Biveinis).
• A regression was introduced in fix for bug #932623 which caused incorrect handling of compressed tablespaces with the page size of 16K, that were created between the last full or incremental and the next incremental backup. Bugs fixed #1049174 and #1044398 (Laurynas Biveinis).

What is new in version 1.6.4:

• It contains important bug fixes to the stable 1.6 series of Percona XtraBackup releases.