Comment 3 for bug 1180922

I just tried xtrabackup-2.1.2 and it looks like it does fix the error I had listed. I now have a separate, but I believe to be a related bug. If you'd prefer I can open a new ticket, but in the meantime I'll post it here:

I'm using percona-server-5.5 and Ubuntu 12.04 with xtrabackup-2.1.2. If I run xtrabackup --stream=tar ./ > backup.tar, I get the appropriate backup file, with no errors, but if I then pipe that command into gzip like the documentation says I can (and which worked fine in xtrabackup-2.0.7) the backup appears to go on forever and doesn't ever finish:

<email address hidden>:~# innobackupex --stream=tar ./ | gzip - > backup.tar.gz

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Ireland Ltd 2009-2012. All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

130521 15:22:39 innobackupex: Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' (using password: NO).
130521 15:22:39 innobackupex: Connected to MySQL server
IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

innobackupex: Using mysql server version 5.5.30-30.2-log

innobackupex: Created backup directory /root

130521 15:22:39 innobackupex: Starting ibbackup with command: xtrabackup_55 --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/tmp --tmpdir=/tmp --stream=tar
innobackupex: Waiting for ibbackup (pid=1855) to suspend
innobackupex: Suspend file '/tmp/xtrabackup_suspended_2'

xtrabackup_55 version 2.1.2 for Percona Server 5.5.16 Linux (x86_64) (revision id: 611)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
xtrabackup: using O_DIRECT
>> log scanned up to (1204575598)
[01] Streaming ./ibdata1
>> log scanned up to (1204576025)
>> log scanned up to (1204576025)
>> log scanned up to (1204576025)
>> log scanned up to (1204576025)
>> log scanned up to (1204576025)
>> log scanned up to (1204576025)
[01] ...done
>> log scanned up to (1204576025)

130521 15:22:47 innobackupex: Continuing after ibbackup has suspended
130521 15:22:47 innobackupex: Starting to lock all tables...
DBD::mysql::db do failed: Lost connection to MySQL server during query at /usr/bin/innobackupex line 1441.
innobackupex: Error:
Error executing 'FLUSH TABLES WITH READ LOCK': DBD::mysql::db do failed: Lost connection to MySQL server during query at /usr/bin/innobackupex line 1441.

>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
>> log scanned up to (1204576452)
...

The log scanning, as far as I can tell just continues to go on forever. Is there any chance this is related to previous bug that you were able to fix?

Thanx!