# ibbackup failed at /usr/bin/innobackupex line 2632 **URL:** \ **Category:** Percona XtraBackup\ **Created:** [November 21, 2014, 2:32pm UTC](https://forums.percona.com/t/ibbackup-failed-at-usr-bin-innobackupex-line-2632/3900 "2014-11-21T14:32:49Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Rusty\_Kroboth](https://avatars.discourse-cdn.com/v4/letter/r/47e85d/32.png) [@Rusty\_Kroboth](https://forums.percona.com/u/Rusty_Kroboth)\ **Post date:** [November 21, 2014, 2:32pm UTC](https://forums.percona.com/t/ibbackup-failed-at-usr-bin-innobackupex-line-2632/3900/1 "2014-11-21T14:32:49Z")
I am trying out Percona XtraBackup. I installed rpm for centos 5.5 with no problem. Then ran the command: /usr/bin/innobackupex --user=xxxxxx --password=xxxxxx /var/local/backup/mysql/ and that worked fine - the output ended with “141121 14:36:31 innobackupex: completed OK!” then I ran the command: /usr/bin/innobackupex --apply-log /var/local/backup/mysql/2014-11-21\_14-30-01/ And that failed with the below output. Am I missing something? Thank you in advance for anybody’s input! xtrabackup version 2.2.6 based on MySQL server 5.6.21 Linux (x86\_64) (revision id: ) xtrabackup: cd to /var/local/backup/mysql/2014-11-21\_14-30-01 xtrabackup: This target seems to be not prepared yet. xtrabackup: xtrabackup\_logfile detected: size=69238784, start\_lsn=(33311868765843) xtrabackup: using the following InnoDB configuration for recovery: 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 = 69238784 xtrabackup: using the following InnoDB configuration for recovery: 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 = 69238784 xtrabackup: Starting InnoDB instance for recovery. xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter) InnoDB: Using atomics to ref count buffer pool pages InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw\_locks use GCC atomic builtins InnoDB: Memory barrier is not used InnoDB: Compressed tables use zlib 1.2.3 InnoDB: Using CPU crc32 instructions InnoDB: Initializing buffer pool, size = 100.0M InnoDB: Completed initialization of buffer pool InnoDB: Highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 33311868765843 InnoDB: Database was not shutdown normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files… InnoDB: Restoring possible half-written data pages InnoDB: from the doublewrite buffer… InnoDB: Doing recovery: scanned up to log sequence number 33311874008576 (8%) InnoDB: Doing recovery: scanned up to log sequence number 33311879251456 (17%) InnoDB: Doing recovery: scanned up to log sequence number 33311884494336 (25%) InnoDB: Doing recovery: scanned up to log sequence number 33311889737216 (34%) InnoDB: Doing recovery: scanned up to log sequence number 33311894980096 (42%) InnoDB: Starting an apply batch of log records to the database… InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 33311900222976 (51%) InnoDB: Doing recovery: scanned up to log sequence number 33311905465856 (59%) InnoDB: Doing recovery: scanned up to log sequence number 33311910708736 (68%) InnoDB: Doing recovery: scanned up to log sequence number 33311915951616 (76%) InnoDB: Doing recovery: scanned up to log sequence number 33311921194496 (85%) InnoDB: Doing recovery: scanned up to log sequence number 33311926437376 (93%) InnoDB: Starting an apply batch of log records to the database… InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 56072678, file name ./mysql-bin.014543 2014-11-21 14:37:35 2ace9d43c4a0 InnoDB: Assertion failure in thread 47066890093728 in file pars0pars.cc line 865 InnoDB: Failing assertion: sym\_node-\>table != NULL InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](http://bugs.mysql.com). InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: [url][http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html%5B/url%5D) InnoDB: about forcing recovery. 19:37:35 UTC - xtrabackup got signal 6 ; This could be because you hit a bug or data is corrupted. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Thread pointer: 0x16cdceb0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong… stack\_bottom = 0 thread\_stack 0x10000 xtrabackup(my\_print\_stacktrace+0x32) [0xa3c6f9] xtrabackup(handle\_fatal\_signal+0x335) [0x911661] /lib64/libpthread.so.0 [0x35a260eb10] /lib64/libc.so.6(gsignal+0x35) [0x35a1a30265] /lib64/libc.so.6(abort+0x110) [0x35a1a31d10] xtrabackup [0xaa12b5] xtrabackup(pars\_update\_statement(upd\_node\_t\*, sym\_node\_t\*, void\*)+0x2c) [0xaa1f2c] xtrabackup(yyparse()+0xc18) [0xbc979e] xtrabackup(pars\_sql(pars\_info\_t\*, char const\*)+0xc2) [0xa9fa60] xtrabackup(que\_eval\_sql(pars\_info\_t\*, char const\*, unsigned long, trx\_t\*)+0x7f) [0x704251] xtrabackup(row\_drop\_table\_for\_mysql(char const\*, trx\_t\*, bool, bool)+0xaaf) [0x6bb13f] xtrabackup(row\_mysql\_drop\_temp\_tables()+0x213) [0x6bc025] xtrabackup(recv\_recovery\_rollback\_active()+0x2c) [0x6d39ac] xtrabackup(innobase\_start\_or\_create\_for\_mysql()+0x17e3) [0x7968d3] xtrabackup [0x5db351] xtrabackup [0x5e0603] xtrabackup(main+0x962) [0x5e2ed4] /lib64/libc.so.6(\_\_libc\_start\_main+0xf4) [0x35a1a1d994] xtrabackup(\_\_gxx\_personality\_v0+0x389) [0x5d64d9] Please report a bug at [url][https://bugs.launchpad.net/percona-xtrabackup[/url]](https://bugs.launchpad.net/percona-xtrabackup%5B/url%5D) innobackupex: got a fatal error with the following stacktrace: at /usr/bin/innobackupex line 2632 main::apply\_log() called at /usr/bin/innobackupex line 1561 innobackupex: Error: innobackupex: ibbackup failed at /usr/bin/innobackupex line 2632. ---
**Author:** ![mirfan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/mirfan/32/16890_2.png) [@mirfan](https://forums.percona.com/u/mirfan)\ **Post date:** [November 22, 2014, 2:39am UTC](https://forums.percona.com/t/ibbackup-failed-at-usr-bin-innobackupex-line-2632/3900/2 "2014-11-22T02:39:53Z")
You may be impacted with the bugs listed below. Check If It matches your case. [url][https://bugs.launchpad.net/percona-server/+bug/1257266[/url]](https://bugs.launchpad.net/percona-server/+bug/1257266%5B/url%5D) [url][MySQL Bugs: #68987: MySQL crash with InnoDB assertion failure in file pars0pars.cc](http://bugs.mysql.com/bug.php?id=68987%5B/url%5D) [url][MySQL Bugs: #69274: MySQL 5.6 crashes during startup with assertion failure "sym\_node-\>table != NUL"](http://bugs.mysql.com/bug.php?id=69274%5B/url%5D)