innobackupex 2.4 --host backup remote database(5.7.11) failure

[ycc]

innobackupex --defaults_file=/etc/my.cnf --user=bk2 --password=bk2016 --host=192.168.1.196 /backup_data/
160309 11:58:50 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

160309 11:58:50 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;host=192.168.1.196;mysql_socket=/var/lib/mysql/mysql.sock' as 'bk2' (using password: YES).
160309 11:58:50 version_check Connected to MySQL server
160309 11:58:50 version_check Executing a version check against the server...
160309 11:58:50 version_check Done.
160309 11:58:50 Connecting to MySQL server host: 192.168.1.196, user: bk2, password: set, port: 0, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.11-log
2016-03-09 11:58:50 0x7fb5dde8e740 InnoDB: Assertion failure in thread 140419088836416 in file backup_copy.cc line 658
InnoDB: Failing assertion: realpath(second, real_second) != 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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
03:58:50 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+0x2c)[0xe0b60c]
innobackupex(handle_fatal_signal+0x262)[0x9c1a72]
/lib64/libpthread.so.0(+0xf100)[0x7fb5dda6e100]
/lib64/libc.so.6(gsignal+0x37)[0x7fb5dbdc65f7]
/lib64/libc.so.6(abort+0x148)[0x7fb5dbdc7ce8]
innobackupex[0x6e872b]
innobackupex[0x7264dc]
innobackupex(_Z14get_mysql_varsP8st_mysql+0x723)[0x723063]
innobackupex(_Z7xb_initv+0x12b)[0x71316b]
innobackupex(main+0x77c)[0x6f16ac]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fb5dbdb2b15]
innobackupex[0x70b355]

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

[Sergei Glushchenko (sergei.glushchenko)]

It is not possible to backup remote database with xtrabackup. Xtrabackup needs an access to the filesystem where database files are stored in order to copy them. But I agree that error message could be more descriptive.

[Sergei Glushchenko (sergei.glushchenko)]

If you don't mind I'd rename this bug report to something like "xtrabackup should fail with descriptive error if datadir does not exists".

[Launchpad Janitor (janitor)]

[Expired for Percona XtraBackup because there has been no activity for 60 days.]

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1373