# Attempting to restore table from xtrabackup (v2.2.11)

**URL:** https://forums.percona.com/t/attempting-to-restore-table-from-xtrabackup-v2-2-11/4323
**Category:** Percona XtraBackup
**Created:** [July 27, 2015, 5:46am UTC](https://forums.percona.com/t/attempting-to-restore-table-from-xtrabackup-v2-2-11/4323 "2015-07-27T05:46:19Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![rdb-support](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@rdb-support](https://forums.percona.com/u/rdb-support)
#### Post date: [July 27, 2015, 5:46am UTC](https://forums.percona.com/t/attempting-to-restore-table-from-xtrabackup-v2-2-11/4323/1 "2015-07-27T05:46:19Z")

</div>

So I have a backup I’m trying to restore into a new environment, but every time I attempt to prepare the backup for restoration, the defaults file in the backup location is ignored, and there is an error that the innodb\_data\_file\_path parameter is not there. I figured this was related to permissions, as it is world-writable on a cifs share, and so copied it off to my pwd. However, the error is the same, except that it is now showing the same error but with the new defaults file name in it instead. The file I set as the new defaults file apparently doesn’t have the innodb\_data\_file\_path entry in it (I am 100% certain that it does, I am looking at it right now!!).

The file permissions on the new file are 644. I have no idea why this is happening. I suspect this may be related to the fact the backup is on a CIFS share, but need to be sure this is the case, however we don’t have any spare disks to use to put the backup on to before restoring. See output from innobackupex command below:

# innobackupex --defaults-file ./backup-my.cnf --apply-log --export /backups/20150723

InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy  
and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved.

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

Get the latest version of Percona XtraBackup, documentation, and help resources:  
[http://www.percona.com/xb/p](http://www.percona.com/xb/p)

150727 11:59:19 innobackupex: Starting the apply-log operation

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

Warning: World-writable config file ‘/mnt/backup/mysql/20150723/backup-my.cnf’ is ignored  
innobackupex: got a fatal error with the following stacktrace: at /usr/bin/innobackupex line 4545  
main::get\_option(‘innodb\_data\_file\_path’) called at /usr/bin/innobackupex line 2631  
main::apply\_log() called at /usr/bin/innobackupex line 1578  
innobackupex: Error: no ‘innodb\_data\_file\_path’ option in group ‘mysqld’ in server configuration file ‘/root/backup-my.cnf’ at /usr/bin/innobackupex line 4545.

---

<div class="post-metadata">

### Author: ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)
#### Post date: [July 28, 2015, 10:16pm UTC](https://forums.percona.com/t/attempting-to-restore-table-from-xtrabackup-v2-2-11/4323/2 "2015-07-28T22:16:57Z")

</div>

Can you run it with innobackupex --apply-log /backupdir only without --defaults-file=, let us know how it goes.

---

<div class="post-metadata">

### Author: ![rdb-support](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@rdb-support](https://forums.percona.com/u/rdb-support)
#### Post date: [July 31, 2015, 5:26am UTC](https://forums.percona.com/t/attempting-to-restore-table-from-xtrabackup-v2-2-11/4323/3 "2015-07-31T05:26:11Z")

</div>

Hi,

Yes I did, but it didn’t work. The issue was down to the fact the backup was on a CIFS share. When I took the backup off to a local disk and altered the permissions, it worked fine. However, now when I try to restore the table it complains with the following:

error -1 from storage engine

There is enough space on the server for the table to sit (over 100GB free on the local disk), and the --apply-log --export command worked fine. No errors reported. I am using MariaDB 5.5, so no need for the .cfg file. Any ideas where to go next? The error log shows me this:

150730 12:11:17 InnoDB: Error: trying to open a table, but could not  
InnoDB: open the tablespace file ‘./t2m\_client\_71/RECOVERY.ibd’!  
150730 12:11:17 InnoDB: Error: cannot reset lsn’s in table `t2m_client_71`.`RECOVERY`  
InnoDB: in ALTER TABLE … IMPORT TABLESPACE  
150730 12:11:34 InnoDB: Error: tablespace id and flags in file ‘./t2m\_client\_71/RECOVERY.ibd’ are 15300 and 0, but in the InnoDB  
InnoDB: data dictionary they are 16270 and 0.

The ibdata file was restored from the same backup as the table, so I’m not sure why it would come up with this error…anyone got any ideas what to do next?

Regards,

Tom
