This is the error message from the xtrabackup:
"
170915 08:05:00 completed OK!
170915 08:05:00 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints "completed OK!".
/usr/bin/innobackupex version 2.4.8 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 97330f7)
xtrabackup: cd to /data/backup/2017-09-15/full-backup/
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=23396352, start_lsn=(76729429855)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = database01:128M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 23396352
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = database01:128M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 23396352
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.8
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 1G, instances = 1, chunk size = 128M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Opened 8 undo tablespaces
InnoDB: 8 undo tablespaces made active
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 76729429855
InnoDB: Doing recovery: scanned up to log sequence number 76734606848 (24%)
InnoDB: Doing recovery: scanned up to log sequence number 76739849728 (50%)
InnoDB: Doing recovery: scanned up to log sequence number 76745092608 (75%)
InnoDB: Doing recovery: scanned up to log sequence number 76750249714 (100%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
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 2017-09-15 08:05:05 0x7f7cf043f700 InnoDB: Assertion failure in thread 140174583658240 in file page0zip.cc line 4399
InnoDB: Failing assertion: slot_rec
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.
08:05:05 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...
40 41 stack_bottom = 0 thread_stack 0x10000
/usr/bin/innobackupex(my_print_stacktrace+0x2c)[0xc7897c]
/usr/bin/innobackupex(handle_fatal_signal+0x261)[0xa20111]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f7d360bb890]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f7d33d59067]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f7d33d5a448]
/usr/bin/innobackupex[0x6f4743]
/usr/bin/innobackupex(_Z19page_zip_dir_deleteP14page_zip_des_tPhPK12dict_index_tPKmPKh+0x2a8)[0x8786e8]
/usr/bin/innobackupex(_Z19page_cur_delete_recP10page_cur_tPK12dict_index_tPKmP5mtr_t+0x3ef)[0x775b7f]
/usr/bin/innobackupex(_Z24page_delete_rec_list_endPhP11buf_block_tP12dict_index_tmmP5mtr_t+0x286)[0x990f86]
/usr/bin/innobackupex(_Z26page_parse_delete_rec_list9mlog_id_tPhS0_P11buf_block_tP12dict_index_tP5mtr_t+0x6b)[0x991c4b]
/usr/bin/innobackupex[0x78cb02]
/usr/bin/innobackupex(_Z22recv_recover_page_funcmP11buf_block_t+0xb8f)[0x78e77f]
/usr/bin/innobackupex(_Z20buf_page_io_completeP10buf_page_tb+0x594)[0x921bf4]
/usr/bin/innobackupex(_Z12fil_aio_waitm+0x12f)[0x7e0d2f]
/usr/bin/innobackupex(io_handler_thread+0x28)[0x8ebeb8]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8064)[0x7f7d360b4064]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f7d33e0c62d]
"
DB is MySQL 5.7.19 Oracle Ent. build and that schema has partitioned tables and that instance has SSL enbaled.
Do you use InnoDB compressed tables? If yes, is innodb_