Without hitting Ctrl-C, I'd eventually get an assertion, the full command was: innobackupex --apply-log 2014-12-16_18-02-25

141217 16:21:42  innobackupex: Starting ibbackup with command: xtrabackup  --defaults-file="/mnt/data/localbackup/mysql06-2.hostname.com/full/2014-12-16_18-02-25/backup-my.cnf"  --defaults-group="mysqld" --prepare --target-dir=/mnt/data/localbackup/mysql06-2.hostname.com/full/2014-12-16_18-02-25

xtrabackup version 2.2.7 based on MySQL server 5.6.21 Linux (x86_64) (revision id: )
xtrabackup: cd to /mnt/data/localbackup/mysql06-2.hostname.com/full/2014-12-16_18-02-25
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(6542575355872)
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 = 2097152
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 = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 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.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 100.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: The log sequence numbers 6041770903387 and 6041770903387 in ibdata files do not match the log sequence number 6542575355872 in the ib_logfiles!
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: We scanned the log up to 6542575355392. A checkpoint was at 6542575355872 and the maximum LSN on a database page was 0. It is possible that the database is now corrupt!
[...]
2014-12-17 16:21:44 7f9506c08720 InnoDB: Error: page 98345 log sequence number 6542647464609
InnoDB: is in the future! Current system log sequence number 6542575355872.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
InnoDB: 125 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 32925002752
InnoDB: Last MySQL binlog file position 0 1019564159, file name /mnt/data/master/bin-log.003375
InnoDB: Cleaning up trx with id 32945843215
2014-12-17 16:21:44 7f9506c08720  InnoDB: Assertion failure in thread 140278040135456 in file trx0trx.cc line 292
InnoDB: Failing assertion: trx->update_undo == NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
21:21:44 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Thread pointer: 0x132f010
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = ad6388 thread_stack 0x10000
xtrabackup(my_print_stacktrace+0x2e) [0x912a0e]
xtrabackup(handle_fatal_signal+0x235) [0x819545]
/lib64/libpthread.so.0(+0xf710) [0x7f95067ee710]
/lib64/libc.so.6(gsignal+0x35) [0x7f9504e0a635]
/lib64/libc.so.6(abort+0x175) [0x7f9504e0be15]
xtrabackup(trx_free_for_background(trx_t*)+0x175) [0x5a4715]
xtrabackup(trx_rollback_or_clean_recovered(unsigned long)+0x2b0) [0x5f9060]
xtrabackup(innobase_start_or_create_for_mysql()+0xeca) [0x6e0fda]
xtrabackup() [0x5750bc]
xtrabackup(main+0x87b) [0x5772bb]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x7f9504df6d5d]
xtrabackup(__gxx_personality_v0+0x341) [0x56bcf9]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
innobackupex: got a fatal error with the following stacktrace: at /root/percona-xtrabackup-2.2.7-Linux-x86_64/bin/innobackupex line 2633
        main::apply_log() called at /root/percona-xtrabackup-2.2.7-Linux-x86_64/bin/innobackupex line 1561
innobackupex: Error:
innobackupex: ibbackup failed at /root/percona-xtrabackup-2.2.7-Linux-x86_64/bin/innobackupex line 2633.