# Using Percona sanity check **URL:** \ **Category:** Percona XtraBackup\ **Created:** [March 24, 2011, 7:43am UTC](https://forums.percona.com/t/using-percona-sanity-check/2135 "2011-03-24T07:43:46Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![bsewell](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@bsewell](https://forums.percona.com/u/bsewell)\ **Post date:** [March 24, 2011, 7:43am UTC](https://forums.percona.com/t/using-percona-sanity-check/2135/1 "2011-03-24T07:43:46Z")
Hi, Using Percona innobackupex-1.5.1 to do my MySQL backups. The process i have is as below: 1. Backup /usr/bin/innobackupex-1.5.1 --user=username --password=password /alf\_data/Backup/`date '+%d%m%y'`/2-MySQL/1-Percona-Backups \> /alf\_data/Backup/`date '+%d%m%y'`/logs/HotBackup.log 1. Prepare /usr/bin/innobackupex-1.5.1 --user=username --password=password–apply-log /alf\_data/Backup/`date '+%d%m%y'`/2-MySQL/1-Percona-Backups/\* \> /alf\_data/Backup/`date '+%d%m%y'`/logs/Recovery-Prep.log There is only one directory in the prepare folder as its moved out of this folder when the cronjob ends. When the prepare is carried out i get the following output message stating that the MySQL database wasnt shutdown correctly and something wrong with the log files. “InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib\_logfiles! 110324 12:24:23 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery.” I’ve uploaded the backup and prepare logs. Is this the right way of doing things? Cheers, Ben ---
**Author:** ![bsewell](https://avatars.discourse-cdn.com/v4/letter/b/e9c0ed/32.png) [@bsewell](https://forums.percona.com/u/bsewell)\ **Post date:** [March 24, 2011, 8:15am UTC](https://forums.percona.com/t/using-percona-sanity-check/2135/2 "2011-03-24T08:15:40Z")
Also tried using the extrabackup with the same commands: Backup: xtrabackup --backup --datadir=/opt/alfresco-3.4.d/mysql/data/ --target-dir=/alf\_data/Backup/innotest Prepare: xtrabackup --prepare --target-dir=/alf\_data/Backup/innotestxtrabackup Prepare 2nd time for recovery: xtrabackup --prepare --target-dir=/alf\_data/Backup/innotestxtrabackup This outputted roughly the same: [root@localhost ~]# xtrabackup --backup --datadir=/opt/alfresco-3.4.d/mysql/data/ --target-dir=/alf\_data/Backup/innotest xtrabackup Ver 1.4 Rev 193 for 5.1.47 pc-linux-gnu (i686) xtrabackup: uses posix\_fadvise(). xtrabackup: cd to /opt/alfresco-3.4.d/mysql/data/ 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 > > log scanned up to (20780164) > > Copying ./ibdata1 > > to /alf\_data/Backup/innotest/ibdata1 > > …done > > xtrabackup: The latest check point (for incremental): ‘20780164’ > > log scanned up to (20780164) > > xtrabackup: Stopping log copying thread. > > xtrabackup: Transaction log of lsn (20780164) to (20780164) was copied. > > [root@localhost ~]# xtrabackup --prepare --target-dir=/alf\_data/Backup/innotest > > xtrabackup Ver 1.4 Rev 193 for 5.1.47 pc-linux-gnu (i686) > > xtrabackup: cd to /alf\_data/Backup/innotest > > xtrabackup: This target seems to be not prepared yet. > > xtrabackup: xtrabackup\_logfile detected: size=2097152, start\_lsn=(20780164) > > 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 = 2097152 > > 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 > > InnoDB: Mutexes and rw\_locks use InnoDB’s own implementation > > 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 > > 110324 13:40:52 InnoDB: highest supported file format is Barracuda. > > 110324 13:40:54 Percona XtraDB ([http://www.percona.com](http://www.percona.com)) 1.0.8-11.2 started; log sequence number 20780164 [notice (again)] If you use binary log and don’t use any hack of group commit, the binary log position seems to be: xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1 110324 13:40:54 InnoDB: Starting shutdown… 110324 13:40:59 InnoDB: Shutdown completed; log sequence number 20780164 [root@localhost ~]# xtrabackup --prepare --target-dir=/alf\_data/Backup/innotest xtrabackup Ver 1.4 Rev 193 for 5.1.47 pc-linux-gnu (i686) xtrabackup: cd to /alf\_data/Backup/innotest xtrabackup: This target seems to be already prepared. xtrabackup: notice: xtrabackup\_logfile was already used to ‘–prepare’. 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 = 2 xtrabackup: innodb\_log\_file\_size = 5242880 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 InnoDB: Mutexes and rw\_locks use InnoDB’s own implementation 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 110324 13:41:01 InnoDB: Log file ./ib\_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib\_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait… 110324 13:41:01 InnoDB: Log file ./ib\_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib\_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait… 110324 13:41:01 InnoDB: highest supported file format is Barracuda. InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib\_logfiles! 110324 13:41:01 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… 110324 13:41:02 Percona XtraDB ([http://www.percona.com](http://www.percona.com)) 1.0.8-11.2 started; log sequence number 20780556 [notice (again)] If you use binary log and don’t use any hack of group commit, the binary log position seems to be: xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1 110324 13:41:02 InnoDB: Starting shutdown… 110324 13:41:07 InnoDB: Shutdown completed; log sequence number 20780556 can someone give this a quick once over for my own sanity. Been tinkering with this and other shell commands for the past week. ---
**Author:** ![mandm](https://avatars.discourse-cdn.com/v4/letter/m/ea5d25/32.png) [@mandm](https://forums.percona.com/u/mandm)\ **Post date:** [November 25, 2012, 1:04pm UTC](https://forums.percona.com/t/using-percona-sanity-check/2135/3 "2012-11-25T13:04:45Z")
i have the same issue where my node crashed and would not startup giving this error in the innodb.prepare.log InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Last MySQL binlog file position 0 17886101, file name /var/log/mysql/mysql-bin.000082 121125 4:55:13 InnoDB: Waiting for the background threads to start 121125 4:55:14 Percona XtraDB ([http://www.percona.com](http://www.percona.com)) 1.1.8-20.1 started; log sequence number 15744097292 [notice (again)] If you use binary log and don’t use any hack of group commit, the binary log position seems to be: InnoDB: Last MySQL binlog file position 0 17886101, file name /var/log/mysql/mysql-bin.000082 xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1 121125 4:55:58 InnoDB: Starting shutdown… 121125 4:55:59 InnoDB: Shutdown completed; log sequence number 15744097292 121125 04:55:59 innobackupex: completed OK! please let me know if you have a solution ---
**Author:** ![niljoshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/niljoshi/32/16889_2.png) [@niljoshi](https://forums.percona.com/u/niljoshi)\ **Post date:** [November 27, 2012, 1:10am UTC](https://forums.percona.com/t/using-percona-sanity-check/2135/4 "2012-11-27T01:10:00Z")
Hi, I have checked your attachments but it seems blank files for me. Can you again upload the files? If your issue is that you are seeing “Crash Recovery” in the output message then It’s normal behavior while preparing backup. Because --apply-log is a crash recovery process itself, that how it works, it starts the crash recovery process to apply the redo logs copied during the backup in order to get a clean backup Regards, ---
**Author:** ![niljoshi](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/niljoshi/32/16889_2.png) [@niljoshi](https://forums.percona.com/u/niljoshi)\ **Post date:** [November 27, 2012, 1:14am UTC](https://forums.percona.com/t/using-percona-sanity-check/2135/5 "2012-11-27T01:14:11Z")
Hi Mandm, Your issue seems different. Can you provide commandline of taking backup and preparing backup with full log? It would be also good if you can create separate post for your issue.