> The symptoms sound similar to this bug -
https://bugs.launchpad.net/percona-xtrabackup/+bug/690822
> If you are using a 32 bit binary of tar4ibd it will silently fail to send
> the entire contents of a (what I thought) was a file more than 64GB but that
> threshold could be less as I didn't check what the biggest possible file
> was. If this turns out to be your issue the patch is included in the bug
> report and is just a one line change changing a size_t type to a long long.
> On Fri, Feb 4, 2011 at 12:31 PM, Aaron Gould <ibel...@gmail.com> wrote:
> > I've got a 50GB database that I'm trying to backup using the tar
> > streaming feature of innobackupex.
> > Here's my backup command:
> > innobackupex-1.5.1 --slave-info --stream=tar ./ | gzip - > /var/
> > backup/mysql/db_2011-02-04.tar.gz
> > The entire procedure takes several minutes, and appears to complete.
> > There's even a successful "innobackupex: completed OK!" on the last
> > line of output.
> > However, the resuling tar.gz file seems to be bad every time.
> > Whenever I list the file's contents via the tar command ("tar -iztvf
> > db_2011-02-04.tar.gz"), tar exits due to failure.
> > The server is running RedHat Enterprise 4 AS, and the tar and gzip are
> > the standard ones included in the distribution. innobackupex is
> > version 1.5.1.
> > Has anyone experienced this?
> > Oddly, I tried a much smaller database (< 1GB) on another server, and
> > everything seems to be ok with the above commands...
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Percona Discussion" group.
> > To post to this group, send email to percona-discussion@googlegroups.com.
> > To unsubscribe from this group, send email to
> > percona-discussion+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/percona-discussion?hl=en.
