Recovering an InnoDB table from only an .ibd file.

Sometime you may need to recover a table when all you have is the .ibd file. In this case, if you try to load it into a new instance, your likely to encounter some errors about the table id not matching. And there is not really a way around this.

However, I’ve found two work-arounds for this:

Note: You will need the .ibd file and the CREATE TABLE statement for each table you want to recover using these methods.

  1. Simulate the internal InnoDB table counter. That is, create work tables (with innodb_file_per_table enabled) until you have the internal pointer of table id equal to (1 – id_of_ibd_table_you_need_to_restore). (See Method #1)
  2. Manually hex edit the .ibd file, changing the table id. (See Method #2)

*Note: There are some internal structures with this meta information, so you’ll need to dump/import that data after you get it loaded, so you avoid unpleasantries that will inevitably show their face.

Method #1 – Create work tables

1. Start up clean/fresh instance of MySQL with innodb_file_per_table enabled.

2. Now, we need to find the table id that MySQL is currently set at, as well as the table id for the table we need to recover.

Step 2 (2a – 2f) is simply to find the table id that is stored inside of the .ibd file. I’ve written a PHP script to determine this, so using the script can save a bunch of time. See the bottom of this page (under “Associated Files”) for the exact script.

2a. Create a test database:

mysql> CREATE DATABASE test1;
mysql> USE test1;

2b. Issue the create table command for the table:

mysql> CREATE TABLE `product` (
  `PRODUCT_ID` bigint(20) unsigned NOT NULL auto_increment,
  `BRAND_ID` int(10) unsigned default NULL,
  `PRODUCT_TYPE_ID` int(10) unsigned default NULL,
  `GROUP_ID` int(10) unsigned default NULL,
  `PRODUCT_NAME` varchar(500) NOT NULL,
  `DEFAULT_EMAIL_ID` varchar(48) default NULL,
  `CLIENT_ID` bigint(20) unsigned default NULL,
  `LAST_MODIFIED_BY` varchar(45) NOT NULL,
  ) ENGINE=InnoDB;

2c. Discard the tablespace, which will delete the newly created .ibd file:


2d. Copy the pre-existing .ibd file to the datadir/test1 folder

2e. Import this tablespace:


This should produce the following error (at least this is most likely). The only way it would not is if MySQL’s current table id matched that of the preexisting ibd table id. In which case, you can now dump your table.

ERROR 1030 (HY000): Got error -1 from storage engine

2f. So, now to check the error log (manually). Look for the following entry:

081010 11:47:40  InnoDB: Error: tablespace id in file 
'.test1product.ibd' is 1193, but in the InnoDB
InnoDB: data dictionary it is 1.

So, now we know the internal table id is at 1, and that of the ibd table is 1193.

3. Clean up working database:

3a. Manually move the ibd file from the $datadir to a safe location (as you will need this file again).

3b. Drop this table.

mysql> DROP TABLE product;

Note this does not re-set the internal table counter.

4. You’ll need to create the number of tables you need to increase the internal table id value.

In this case, you’d create 1191 test InnoDB tables (already at 1, and need to leave 1 for the actual table, so 1193-2=1191). Run below in a loop.

for ($1=1; $i<=1191; $1++) {
  CREATE TABLE t# (id int) ENGINE=InnoDB;

I accomplished this via a simple php script. See the bottom of this page (under "Associated Files") for the exact script.

5. After these are created, go ahead and drop this database and all tables (as they are not needed).

DROP DB test1;

6. Now, re-perform steps 2a through 2e.

mysql> CREATE DATABASE test1;
mysql> USE test1;
mysql> CREATE TABLE `product` ( ... ) ENGINE=InnoDB;

<--  Here is where you copy back the original ibd file to /$datadir/test1/ -->



mysql> show tables;
| Tables_in_test1 |
| product         |
1 row in set (0.00 sec)

7. Now, dump the table using mysqldump, and then you can import this to any MySQL instance. Note, you must dump this and re-import it, or you'll run into problems.

However, it's possible to encounter crashes and/or reports of corruption in the logs.

If this happens, try to force innodb recovery (which is most likely), and then dump the table.

Start by setting innodb_force_recovery=1 (and try 2,3,4,5,6) until the dump works.

For this example table, I had to set innodb_force_recovery=5 before the dump would succeed.

The # in the output file name is the value I had innodb_force_recovery set to when trying to perform the dump:

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump1.txt
mysqldump: Couldn't execute 'show table status like 'product'': 
Lost connection to MySQL server during query (2013)

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump2.txt
mysqldump: Couldn't execute 'show table status like 'product'': 
Lost connection to MySQL server during query (2013)

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump3.txt
mysqldump: Couldn't execute 'show table status like 'product'': 
Lost connection to MySQL server during query (2013)

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump4.txt
mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ 
* FROM `product`': Lost connection to MySQL server during 
query (2013)

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump5.txt

C:Program FilesMySQLmysql-5.0.68bin>
mysqladmin -u root -P 3385 shutdown

C:Program FilesMySQLmysql-5.0.68bin>
mysqldump -uroot -P3385 test1 product > product_dump6.txt

In fact, in this case, I could have simply started with 5. This is because the error log stated this:

InnoDB: Error: trying to access update undo rec field 19 
in index PRIMARY of table test1/product
InnoDB: but index has only 12 fields

So, I knew there was a problem trying to look at the undo logs, and from the manual, a setting of 5 says this:

"Do not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed"

However, it's best to start at 1 and work your way forward so as to prevent as much data loss as possible.

Method #2 - Hex Edit .ibd file

First of all, you'll need to backup everything (ibdata files, ib_logfile(s), data). I'd also perform a mysqldump of everything you currently have, just so you have a mysqldump of it in the event that you need it.

Also, very important, be sure to make a copy of the .ibd file for the specific table in question.

Lastly, get a copy of the CREATE TABLE statement that will recreate this table.

Then, you'll follow the steps #1-5 (but do not perform step #6 yet) outlined on the following page:

Let me post them here for completeness, however:

  1. Use mysqldump to dump all your InnoDB tables.
  2. Stop the server.
  3. Remove all the existing tablespace files, including the ibdata and ib_log files. If you want to keep a backup copy of the information, then copy all the ib* files to another location before the removing the files in your MySQL installation.
  4. Remove any .frm files for InnoDB tables.
  5. Configure a new tablespace.
  6. Restart the server.
  7. Import the dump files.

At this point, MySQL should be running fine with an empty slate (and should have just re-created your new ibdata and log files).

Now, you'll want to recreate the table (just using the CREATE TABLE output from above), and its database to hold it.

Then, you'll basically be following the steps #1-3 outlined on the following page:

1. Issue this ALTER TABLE statement:


Caution: This statement deletes the current .ibd file.

2. Put the backup .ibd file back in the proper database directory (the one that you copied above).

3. Issue this ALTER TABLE statement:


Everything should go smoothly until step #3 (above). More than likely, this will produce an error like the following on your console:

"Got error -1 from storage engine"

Now, if you look in the error log, you'll see something like:

"InnoDB: Error: tablespace id in file '.testt2.ibd' is 2, 
but in the InnoDB data dictionary it is 1."

It would not produce the above error and would work fine if the existing table already had a tablespace id of 1. However, this is unlikely.

So, assuming you see the above errors, then you can modify the tablespace id actual ibd file using a hex editor. I would do this on a different copy of the ibd file (other than the original, just in case).

Note that I used "Freeware Hex Editor XVI32" for Windows for this step. Start the program, and then open the .ibd file. You'll see each byte in it's own cell. You can then click on a cell, click edit, and then edit that byte. (

Now, in this file, there are 2 places where this tablespace id is located.

For me, and I assume it should be the same for you, but just look at the values to be sure, I see the tablespace id values listed at position 37 and 41 (positions 25 and 29 in hex). In the actual hex column, if you're previous tablespace id was 2, then in positions 37 and 41, you'd see 02 and 02.

(Note these positions can change. For instance, I tested on a table with an internal id of 1193. This in hex is 04A9. However, when searching the file, for the first instance of the table id, I found the '04' in position 39 and 'A9' in position 40. Then, for the second instance of the table id, the '04' was at position 43 and the 'A9' was at position 44. So, you'll have to convert the table id to hex, and then search for that value, near the beginning of the file.)

Note that this value (02) may vary depending on what your actual tablespace id is.

Then, simply modify both of those fields to 01, and save the file.

Then, re-do the following 3 steps:

2. Put the newly saved .ibd file back in the proper database directory

This time, step #3 works fine.

It is at this point you should dump/import the data. At least, get a good mysqldump of this table now. You may find that this causes corruption in InnoDB, and you may need to start MySQL using --force-innodb-recovery. Forcing InnoDB Recovery

Associated Files :: PHP Scripts

Simple PHP script - Used to create a number of InnoDB tables (to increase internal table id counter):

$dbhost = "localhost:3385";
$dbname = "test1";
$dbuser = "root";
$dbpwd  = "";

mysql_connect($dbhost,$dbuser,$dbpwd) or die(mysql_error());

for ($i = 1033; $i <= 1190; $i++) {
   $dbquery = "CREATE TABLE test1.t" . $i . " (id int) ENGINE=InnoDB";
   echo "" . $dbquery . "";
      $result = mysql_db_query($dbname,$dbquery) or die(mysql_error());
      $j = 0;
      while($row = mysql_fetch_array($result)) {
         echo $row[0];


PHP Internal Table ID Finder - Used to determine the internal Table ID from the binary .ibd file:

Tested with tables from 4.1.23, 5.0.68, 5.1.28, and 6.0.7.

// Set the filename
$filename = "C:\Users\Chris\Desktop\mysql\working\ibds\z1.ibd";

// Read 2 bytes in at a time
$offset = 2;

// Echo filename and path
echo "filename = $filename

"; // Open the filename - need 'rb' for binary file on Windows $handle = fopen($filename, "rb"); // Define redundant, local variables for possible later functionality and/or checks $ibd_id_bin = 0; $ibd_id_hex = 0; $ibd_id_dec = 0; $ibd_id_bin2 = 0; $ibd_id_hex2 = 0; $ibd_id_dec2 = 0; // Find the filesize (note: below command messes up script) //$filesize = filesize($filename)); // Only loop through first 21 bytes - as table is is in $array[18] and $array[20] for ($z = 0; $z <= 20; $z++) { // Set variable $contents equal to 2 ($offset) bytes of binary data $contents = fread($handle, $offset); // Convert $contents from binary data to hex data $contents2 = bin2hex($contents); // Convert $contents2 from hex data to decimal data $contents3 = hexdec($contents2); // Debug Output //echo "contents[$z] = " . $contents . "
"; //echo "contents2[$z] = " . $contents2 . "

"; //echo "contents3[$z] = " . $contents3 . "

"; // If position 19, array position [18], then store the values if ($z == 18) { $ibd_id_bin = $contents; $ibd_id_hex = $contents2; $ibd_id_dec = $contents3; } // If position 21, array position [20], then store the values if ($z == 20) { $ibd_id_bin2 = $contents; $ibd_id_hex2 = $contents2; $ibd_id_dec2 = $contents3; } } fclose($handle); // More Debug output //echo "

The table id is $ibd_id_dec

"; //echo "

The table id is $ibd_id_dec2

"; // Check to see if both values are equal. If so, then it's // most certain this is the correct value. // If not, then there's a chance the positions are off for // this table (due to versions, etc.). if ($ibd_id_dec == $ibd_id_dec2) { echo "

The table id is $ibd_id_dec

"; } else { echo "The values from positions [18] and [20] did not match,"; echo "so please enable debug output, and check for proper positions."; }

23 thoughts on “Recovering an InnoDB table from only an .ibd file.”

  1. This was very valuable, thanks. Hopefully InnoDB or XtraDB can achieve smoother .ibd portability so that these problems don’t exist, but in the meantime your work here is very useful. I know I could have used it at least one time during page corruption.

  2. Note I’ve made a small update to the first attached php script. Thanks to Morgan for pointing this out! 🙂 (Note I moved the connection out of the loop 😉 )

  3. You can probably even remove the first php script with a line of bash:

    shell> for i in `seq 1033 1190`; do mysql test -e “CREATE TABLE t$i (id int) ENGINE=INNODB” ; done;

    The ‘seq’ command is pretty common on Linux, but not on OS X.

  4. Chris, thanks for this well-detailed process. I’m in the process of rebuilding my 104GB database and you just saved me from re-importing everything via a 30-day process.

  5. Hi Gary,

    Thanks for dropping me a line, and letting me know you found this helpful! Hopefully it was able to save you some time 🙂

  6. Hi,

    I’m followed your steps exactly by editing the HEX values. I dumped the tablespace, then perform an import of the tablespace etc.

    The table shows just fine after show tables command however there are 0 records within.

    Have I missed a vital step here?


  7. Hi,
    This procedure saved me. Thanks! There is a problem though when using partitioned tables. When you attempt to discard the tablespace, you get a ‘storage engine does not support that operation’ or something like that.

    The solution, discovered after much painful trial and error, is to follow Chris’ procedure to find the table id, except, edit the table create statement so that it does not have the partitioning clause. Then discard the tablespace, create your dummy tables, and drop in the first partition ibd file. Except, change the name of the ibd file so that it has the same file name as the entire table. TableName#P#P.ibd becomes Tablename.ibd. Then import tablespace.

    At this point, you still can’t do a select statement though. The next step is to execute an alter table statement to add back in the partition. Mysql moves the data back to the correct partition, and at this point you can run a mysql dump to rescue your data.

    I’ve rescued 350GB of data over ten partitions by following this procedure. It’s time consuming, but it works.


  8. Its a very useful and informative post especially for Database Administrators and It really help those peoples.I like this post because I have a deep interest in InnoDB.Well done!

  9. I desperately need help recovering an InnoDB database for which the ibdata file is lost.

    I am not very experienced with this and have spent hours following this and other guides; however, my limited knowledge keeps getting in the way as I get lost repeatedly.

    If anyone is interested, I will pay up to $100 for successful recovery of this database; it’s a ~57mb database from a WordPress site with many hours invested in it.

    Please contact me via email: dcarr /at/ scienceprousa /dot/ com

    Thanks in advance.

  10. @David,

    Unfortunately, the ibdata file is where all main data is stored (unless you have innodb_file_per_table enabled – then individual table data would be stored in their own individual tablespaces – i.e., .ibd files). If you do not have ibdata nor the individual .ibd files (nor a backup), then recovery using these methods is not possible. If you do have individual .ibd files (i.e., innodb_file_per_table was enabled) *and* if you have the table definitions, then perhaps the data could be recovered.

    What happened to the ibdata1 file?

    Did you manually delete it? If so, is this Linux, and did you not stop MySQL yet? If so, then the file would still temporarily exist (until you stop mysqld), and therefore you could run mysqldump while mysqld is still running.


    This just saved me and my team a lot of tears in a lot of beers.

    If you were here, I’d buy you one.


  12. Question: what is the most efficient way to reset the “internal innodb table counter” when you have to repeat this entire process?

  13. @B,

    I drop the ibdata and ib_logfile files and start from fresh (with regards to InnoDB anyway).

    Glad to hear this helped! Many thanks for sharing. 🙂

  14. Hi Chris,

    I have a system that was restored from mondo cd. But the innodb database could not be started without me putting in force recovery 6. And I keep having issues dumping the database out (keep encountering error 2012).

    I’m not good with databases, so am not too sure about playing around with tables and hex… What is an economical route to recover the database?


Comments are closed.