在生产环境中使用的是xtrabackup，对mysql进行备份，每天0点开始备份，周日是全量备份，其他时间是基于周日做的增量备份，通过脚本实现，每天备份完成后会发送短信，突然有一天，备份全部失败，手动执行也无法备份，报错的日志如下：

/usr/bin/xtrabackup version 2.4.8 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 97330f7)
incremental backup from 70857650633 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /usr/local/mysql/mysqldata/data1
xtrabackup: open files limit requested 8192, set to 1048576
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 536870912
InnoDB: Number of pools: 1
23:04:07 UTC - xtrabackup got signal 11 ;
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
/usr/bin/xtrabackup(my_print_stacktrace+0x35)[0xd19635]
/usr/bin/xtrabackup(handle_fatal_signal+0x273)[0xbccf03]
/lib64/libpthread.so.0[0x383920f7e0]
/usr/bin/xtrabackup(_Z8log_initv+0x24f)[0x7f0bcf]
/usr/bin/xtrabackup(_Z22xtrabackup_backup_funcv+0x44c)[0x7424ac]
/usr/bin/xtrabackup(main+0x9a1)[0x747e21]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3838a1ed1d]
/usr/bin/xtrabackup[0x7354e9]

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

　　在这种情况下，通过手动重启mysql数据库，就能解决。