# page dump, page corruption during prepare
**URL:** https://forums.percona.com/t/page-dump-page-corruption-during-prepare/2119
**Category:** Percona XtraBackup
**Created:** [February 22, 2011, 6:17am UTC](https://forums.percona.com/t/page-dump-page-corruption-during-prepare/2119 "2011-02-22T06:17:30Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@CaptTofu](https://forums.percona.com/u/CaptTofu)
#### Post date: [February 22, 2011, 6:17am UTC](https://forums.percona.com/t/page-dump-page-corruption-during-prepare/2119/1 "2011-02-22T06:17:30Z")
When I try to run prepare (I’ve tried with an new backup twice) on a backup made on Ubuntu 9.10 and run prepare on 10.04, I get the following error (does anyone know what this is?):
root@client:~# xtrabackup --prepare --use-memory=24G --target-dir=/mysql/2011-02-18\_05-54-38
xtrabackup Ver 1.5 Rev 203 for 5.1.53 unknown-linux-gnu (x86\_64)
xtrabackup: cd to /mysql/2011-02-18\_05-54-38
xtrabackup: This target seems to be not prepared yet.
110222 3:42:11 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Warning: cannot open ./xtrabackup\_logfile. will try to find.
xtrabackup: ‘ib\_logfile0’ seems to be ‘xtrabackup\_logfile’. will retry.
xtrabackup: xtrabackup\_logfile detected: size=3418193920, start\_lsn=(1588924650071)
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 = 3418193920
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 25769803776 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw\_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Warning: innodb\_file\_io\_threads is deprecated. Please use innodb\_read\_io\_threads and innodb\_write\_io\_threads instead
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
InnoDB: You may have to recover from a backup.
110222 3:42:12 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 26b54d6100000005000000000000000000000171f49bb68d000000000000 0000000000000000000000002e776200000000000000000200f200000000 0000000600000000ffffffff
P[ pK ;
InnoDB: End of page dump
110222 3:42:12 InnoDB: Page checksum 2533584674 (32bit\_calc: 649416033), prior-to-4.0.14-form checksum 2591050710
InnoDB: stored checksum 649416033, prior-to-4.0.14-form stored checksum 2591050710
InnoDB: Page lsn 369 4103845517, low 4 bytes of lsn at page end 4103845517
InnoDB: Page number (if stored to page already) 5,
InnoDB: space id (if created with \>= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 5.
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 [URL=“[http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html](http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html)”] [http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html[/URL]](http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html%5B/URL%5D)
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
---
### Author:  [@CaptTofu](https://forums.percona.com/u/CaptTofu)
#### Post date: [March 3, 2011, 10:52am UTC](https://forums.percona.com/t/page-dump-page-corruption-during-prepare/2119/2 "2011-03-03T10:52:33Z")
So…
It turns out that the issue is that if the backup is made on a server with “innodb\_fast\_checksum=1” turned on, you will get this error if you try to use a restored (prepared) backup on a box NOT using innodb\_fast\_checksum. This also includes using the generated backup file “backup-my.cnf”, which even if you make a backup on a server using fast checksum, this file will NOT have innodb\_fast\_checksum specified and starting MySQL with this file will result in the failure I had.
---
### Author:  [@xaprb](https://forums.percona.com/u/xaprb)
#### Post date: [March 11, 2011, 9:22pm UTC](https://forums.percona.com/t/page-dump-page-corruption-during-prepare/2119/3 "2011-03-11T21:22:05Z")
That’s a really good catch, thanks for figuring out this problem. I will file a bug report.