Xtrabackup fails every once in a while with a page corruption error

This doesnt happen every time (over the last month, it has happened thrice). During the prepare phase, I get a page dump/corruption (output below). The server version is 5.0.45, and the backup is made to a remote server, using the --remote-host option in innobackupex.

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

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

IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints “completed OK!”.

110628 14:55:27 innobackupex: Starting ibbackup with command: xtrabackup_51 --prepare --target-dir=/home/backups/temp/taTJF7rXDkSHH4F9

xtrabackup: cd to /home/backups/temp/taTJF7rXDkSHH4F9
xtrabackup: This target seems to be not prepared yet.
xtrabackup: Temporary instance for recovery is set 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 = 1
xtrabackup: innodb_log_file_size = 888668160
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
110628 14:55:28 InnoDB: Initializing buffer pool, size = 100.0M
110628 14:55:28 InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 1310 2100691723
110628 14:55:28 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files…
InnoDB: Doing recovery: scanned up to log sequence number 1310 2105934336 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1310 2111177216 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 1310 2116420096 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 1310 2121662976 (2 %)
InnoDB: Doing recovery: scanned up to log sequence number 1310 2126905856 (3 %)
110628 14:55:31 InnoDB: Starting an apply batch of log records to the database…
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 44855.
InnoDB: You may have to recover from a backup.
110628 14:56:08 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex [HEX_DUMP_REMOVED]; InnoDB: End of page dump
110628 14:56:08 InnoDB: Page checksum 3548349607, prior-to-4.0.14-form checksum 1927545439
InnoDB: stored checksum 3548349607, prior-to-4.0.14-form stored checksum 3337421518
InnoDB: Page lsn 1310 2689600555, low 4 bytes of lsn at page end 2701119941
InnoDB: Page number (if stored to page already) 44855,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 86447
InnoDB: Page may be an index page where index id is 0 538
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 44855.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recove ry.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
innobackupex: Error:
innobackupex: ibbackup failed at /usr/bin/innobackupex line 345.

This may be hard to tell without more details i.e. any errors during backup, network errors?

I’d suggest you try a different method. If you must copy straight to the remote server, try one of the streaming options found here http://www.percona.com/docs/wiki/percona-xtrabackup:innoback upex:how_to_recipes

You can also try and backup locally, apply-log on the same if possible then transfer to remote if all OK.