I did a "cold" (db offline, all filesystem files) backup of a MySQL db. I wrote the backup to an ISO image. Unfortunately Joliet filenames are not default. I didn't realize that until attempting to restore the backup and notice that the entire set of files are in DOS 8.3 format. Many of the MySQL filesystem files are not 8.3.

Anyone have tips or information on whether this is a lost cause?

If it's not a lost cause for restoring, are there some tips directions that can be offered?

Much appreciated. ========= 4/22/13 I have been able to recover some of the tables. Others respond with 1146 "Table Doesn't exist". Not sure why, as they are tables containing data, but renaming the frm does not appear to work.

As well, most of the time, the table name isn't in the frm file, just the column name data.

1 Answer 1


It might not be a lost cause, if you can figure out which files are which, but you'll most likely have to do that manually. Presumably your 8.3 format preserved the extensions of the files, which should make things somewhat easier.

I would start with a new installation of the same version of MySQL, verify that it works, and then stop it.

References to the "data" directory below would be whatever SHOW VARIABLES LIKE 'datadir' returns. Often, this is either /usr/local/mysql/data or /var/lib/mysql.

Identify which files in the backup were ibdata1, ib_logfile0, and ib_logfile1 in the "data" directory, and rename them to the proper names and copy them into place over the files from your new install.

Each schema should be a directory inside "data" in your backup. Copy all of those directories into "data" from your new install (including, especially the "mysql" directory inside "data"), then rename them to the original names of the schemas.

Then, inside each of those directories, you'll find the table files, views, and triggers, which hopefully have their original extensions... rename those to their original names, also, where .frm is a table or a view, .myi, .myd, .ibd would be tables, .trn would be triggers. Each of these needs its original filename, which would also be the names of the original table/view/trigger.

You can use the strings(1) unix command line utility to get some idea of what's in the files, to help you identify them. The frm files, for example, will have table or view definitions, which you could use to identify which table you're dealing with, if the filenames are ambiguous. Example:

sqlbot@dev:/usr/local/mysql/data/sakila# strings actor.frm

The same thing on the .ibd file will show the row data (assuming the tables weren't stored compressed on disk). It isn't pretty or formatted, but it's readable.

You don't have to go through all of this work, though, to test whether this is going to be a viable route for you. After you've fixed the ibdata1 and ib_log* files and the data/mysql files (compare with the names of the files in the reinstalled data/mysql directory) and fixed up the names of a couple of tables to test, you should be able to start the server and try to access only those tables that you've fixed the names on so far, and see if you can access the data.

If you don't try to access the tables you haven't yet fixed, the server should come up. if not, the hostname.err log should contain hints as to what you might have overlooked.

Then shut it down again to do more renaming.

If this process proves successful, I would then suggest doing a mysqldump of all the databases and restore it elsewhere, since this resurrected instance wouldn't be something I'd want to put in production.

  • Thanks for the tips. This error pops up in the err log when I run mysqld_safe on the backup 2013-04-21 12:16:09 10077 [ERROR] InnoDB: read can't be opened in ./ib_logfile0 mode 2013-04-21 12:16:09 10077 [ERROR] Plugin 'InnoDB' init function returned error. 2013-04-21 12:16:09 10077 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 2013-04-21 12:16:09 10077 [ERROR] Unknown/unsupported storage engine: InnoDB 2013-04-21 12:16:09 10077 [ERROR] Aborting 2013-04-21 12:16:09 10077 [Note] Binlog end Any thoughts on what that means?
    – Ken Ingram
    Commented Apr 21, 2013 at 19:09
  • Only the first message is relevant -- the others are all side-effects of it. Check the file permissions... everything in the data directory needs to be owned and writable by the appropriate system user account, typically 'mysql' is the correct user. Commented Apr 22, 2013 at 1:47
  • i deleted ib_logfiles which i imagine was the rollback log and the db started up. Not sure what the ramifications were. But I was able to get some important older data.
    – Ken Ingram
    Commented Apr 22, 2013 at 18:35
  • 1
    If my answer was helpful, please consider accepting it. The ramifications of removing the ib_log* files depend on whether you had innodb_fast_shutdown = 0 when you did the graceful shutdown before the backup. If you didn't, the data in the tablespace (ibd) files may not represent the latest state of committed transactions when you shut down, but if it was, then you should be fine. Accessing the tables requires that the frm and ibd files both exist and be named as the server expects. Commented Apr 23, 2013 at 2:10
  • Michael I believe your solution is helpful but I couldn't get anything working until I deledted the ib_log files. I don't know what name they are suppose to have and recovery is not happening on the original machine, so I doubt any transactions in the logs will complete successfully. Thanks for the input. It did help in other ways.
    – Ken Ingram
    Commented May 19, 2013 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.