Comment 2 for bug 1170806

The root cause is that if the log copying thread fails, it does not terminate the process immediately. Instead only the thread is terminated. The main xtrabackup thread will later check if the 'log_copying_succeed' flag is FALSE, and terminate the process. But that happens later, after xtrabackup is done with copying InnoDB files and signalling innobackupex to lock tables and proceed with copying non-InnoDB files.

The fix should be to terminate the xtrabackup process immediately on log copying failure. I don't see any reasons to delay checking its status and fail much later.