**Reported in Launchpad by Ceri WIlliams last update 11-06-2017 04:17:25

https://bugs.launchpad.net/percona-xtrabackup/+bug/1161280
https://bugs.launchpad.net/percona-xtrabackup/+bug/1177206

2 similar bugs (based on the assertion error) exist but refer to incremental backups. They also relate to earlier versions.

The following was seen whilst preparing a backup:

---------------
2017-03-27 04:32:41 0x7f1e406f4700 InnoDB: Assertion failure in thread 139767906780928 in file log0recv.cc line 2008
InnoDB: Failing assertion:

!page_is_comp(page) == dict_table_is_comp(index->table)
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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:32:41 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

Thread pointer: 0x0
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 = 0 thread_stack 0x10000
innobackupex(my_print_stacktrace+0x3b)[0xc98a2b]
innobackupex(handle_fatal_signal+0x281)[0xa58ac1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f239747e390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f239544a428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f239544c02a]
innobackupex[0x6d65c3]
innobackupex[0x86faba]
innobackupex(_Z22recv_recover_page_funcmP11buf_block_t+0xa9e)[0x870a7e]
innobackupex(_Z20buf_page_io_completeP10buf_page_tb+0x339)[0x7577b9]
innobackupex(_Z12fil_aio_waitm+0x11f)[0x7ede6f]
innobackupex(io_handler_thread+0x28)[0x931c38]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f23974746ba]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f239551b82d]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

---------------
This backup was restored on 3 other machines without an issue and was successful on the same machine on the second run.

PS 5.7.17 - 2.4.6-2.xenial (both are the same version as the source server)

innobackupex --defaults-file=./backup-my.cnf --use-memory=20G --apply-log ./

---------------
backup-my.cnf

[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=strict_crc32
innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=1572864000
innodb_fast_checksum=false
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_directory=./
innodb_undo_tablespaces=0
server_id=167772931

redo_log_version=1

---------------
Unfortunately the full output was not captured at the time.

The only known difference was that the first decompress happened with an earlier version of innobackupex (2.3.7-2.xenial)