I guess you forgot to update version of the xtrabackup. It still reports “xtrabackup Ver rc-0.7 for 5.0.83 pc-linux-gnu (x86_64)”.

Regards,
Eugene.

1. We do not plan to produce 32bit binaries, only by special requests.

2. I would say we observed corruption with stream=tar once per month doing daily backups. Corruption is noticed on –prepare stage. So if you see –prepare was OK, you should be safe.

Thanks for these updates. A couple of questions:

1. I see there are no RHEL 32-bit packages. Are you planning to release any?

2. What’s the probability of old backups made with stream=tar are corrupt? Are old backups unusable?

Thanks,
Oren

Please see my comment to that post, I think it was misleading.

xtrabackup does not change any files on original server and can’t cause any corruption on working server.

xtrabackup does change already copied ( destination files), but that is exactly how ibbackup works also.

Sure as any software xtrabackup may have bugs and writes “possible” may get destination files “corrupted”, but again it is similar to ibbackup.

But in comparison with ibbackup we have open all source code and you can check how our backup solution works.

So far we faced corruption only in case with streaming via tar, and that’s why we implemented tar4ibd stream.

I saw a post a couple days ago talking about possible downfalls of innobackupex and I noticed one of the items says that xtrabackup writes to the ibdata* files. Could you clear up what/why/if this happens as this has worried me a little bit about the possibility of corrupting Innodb?

No, we are doing it like regular MyISAM files, under LOCK TABLES.

Awesome on supporting Archive files!

Are you doing this in the manner that archive_reader does, aka as an online backup?

Cheers,
-Brian