Unable to reproduce the same with PS 5.6.21 , Xtrabackup 2.2.5 and 1M reccords. There is one bug related to this. I'm not sure its the same. https://bugs.launchpad.net/percona-xtrabackup/+bug/1368846 Can you provide the my.cnf and full output of apply-log? nilnandan@Dell-XPS:~$ sudo innobackupex --apply-log -use-memory=1G /home/nilnandan/backup/2014-10-28_11-10-52 InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. This software is published under the GNU GENERAL PUBLIC LICENSE Version 2, June 1991. Get the latest version of Percona XtraBackup, documentation, and help resources: http://www.percona.com/xb/p IMPORTANT: Please check that the apply-log run completes successfully. At the end of a successful apply-log run innobackupex prints "completed OK!". 141028 11:11:31 innobackupex: Starting ibbackup with command: xtrabackup --defaults-file="/home/nilnandan/backup/2014-10-28_11-10-52/backup-my.cnf" --defaults-group="mysqld" --prepare --target-dir=/home/nilnandan/backup/2014-10-28_11-10-52 --use-memory=1G --tmpdir=/tmp xtrabackup version 2.2.5 based on MySQL server 5.6.21 Linux (x86_64) (revision id: ) xtrabackup: cd to /home/nilnandan/backup/2014-10-28_11-10-52 xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup_logfile detected: size=97845248, start_lsn=(6599591145) xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 97845248 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 1 xtrabackup: innodb_log_file_size = 97845248 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.8 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 1.0G InnoDB: Completed initialization of buffer pool InnoDB: Highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 6599591145 InnoDB: Database was not shutdown normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 6604833792 (6%) InnoDB: Doing recovery: scanned up to log sequence number 6610076672 (12%) InnoDB: Doing recovery: scanned up to log sequence number 6615319552 (18%) InnoDB: Doing recovery: scanned up to log sequence number 6620562432 (24%) InnoDB: Doing recovery: scanned up to log sequence number 6625805312 (30%) InnoDB: Doing recovery: scanned up to log sequence number 6631048192 (36%) InnoDB: Doing recovery: scanned up to log sequence number 6636291072 (42%) InnoDB: Doing recovery: scanned up to log sequence number 6641533952 (48%) InnoDB: Doing recovery: scanned up to log sequence number 6646776832 (54%) InnoDB: Doing recovery: scanned up to log sequence number 6652019712 (60%) InnoDB: Doing recovery: scanned up to log sequence number 6657262592 (66%) InnoDB: Doing recovery: scanned up to log sequence number 6662505472 (72%) InnoDB: Doing recovery: scanned up to log sequence number 6667748352 (78%) InnoDB: Doing recovery: scanned up to log sequence number 6672991232 (84%) InnoDB: Doing recovery: scanned up to log sequence number 6678234112 (90%) InnoDB: Doing recovery: scanned up to log sequence number 6683476992 (96%) InnoDB: Doing recovery: scanned up to log sequence number 6686567149 (100%) InnoDB: 11 transaction(s) which must be rolled back or cleaned up InnoDB: in total 30 row operations to undo InnoDB: Trx id counter is 882688 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: 128 rollback segment(s) are active. InnoDB: Starting in background the rollback of uncommitted transactions 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882248, 1 rows to undo InnoDB: Waiting for purge to start InnoDB: Rollback of trx with id 882248 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882235, 2 rows to undo InnoDB: Rollback of trx with id 882235 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882234, 2 rows to undo InnoDB: Rollback of trx with id 882234 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882228, 1 rows to undo InnoDB: Rollback of trx with id 882228 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882224, 3 rows to undo InnoDB: Rollback of trx with id 882224 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882193, 4 rows to undo InnoDB: Rollback of trx with id 882193 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882172, 4 rows to undo InnoDB: Rollback of trx with id 882172 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882162, 4 rows to undo InnoDB: Rollback of trx with id 882162 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882159, 4 rows to undo InnoDB: Rollback of trx with id 882159 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882136, 1 rows to undo InnoDB: Rollback of trx with id 882136 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rolling back trx with id 882052, 4 rows to undo InnoDB: Rollback of trx with id 882052 completed 2014-10-28 11:11:37 7fe30af22700 InnoDB: Rollback of non-prepared transactions completed InnoDB: 5.6.21 started; log sequence number 6686567149 [notice (again)] If you use binary log and don't use any hack of group commit, the binary log position seems to be: xtrabackup: starting shutdown with innodb_fast_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 6686590200 141028 11:11:40 innobackupex: Restarting xtrabackup with command: xtrabackup --defaults-file="/home/nilnandan/backup/2014-10-28_11-10-52/backup-my.cnf" --defaults-group="mysqld" --prepare --target-dir=/home/nilnandan/backup/2014-10-28_11-10-52 --use-memory=1G --tmpdir=/tmp for creating ib_logfile* xtrabackup version 2.2.5 based on MySQL server 5.6.21 Linux (x86_64) (revision id: ) xtrabackup: cd to /home/nilnandan/backup/2014-10-28_11-10-52 xtrabackup: This target seems to be already prepared. xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'. xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 xtrabackup: using the following InnoDB configuration for recovery: xtrabackup: innodb_data_home_dir = ./ xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 50331648 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.8 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 1.0G InnoDB: Completed initialization of buffer pool InnoDB: Setting log file ./ib_logfile101 size to 48 MB InnoDB: Setting log file ./ib_logfile1 size to 48 MB InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0 InnoDB: New log files created, LSN=6686590200 InnoDB: Highest supported file format is Barracuda. InnoDB: 128 rollback segment(s) are active. InnoDB: Waiting for purge to start InnoDB: 5.6.21 started; log sequence number 6686590476 [notice (again)] If you use binary log and don't use any hack of group commit, the binary log position seems to be: xtrabackup: starting shutdown with innodb_fast_shutdown = 1 InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 6686592163 141028 11:11:43 innobackupex: completed OK! nilnandan@Dell-XPS:~$