Restoring Movable Type From Backup

As you might notice, all the entries from the old blog have successfully made the transition onto this new installation of Movable Type. It was not without a lot of time and effort, mostly spent reattempting uploads as well as fixing errors; the last blog_id assigned was 57, and that was after I had deleted a Movable Type installation which had worked its way up to 15. To say that I made a lot of attempts to restore the database is quite the understatement. (my hosting provider shows that in the course of 3 days, I've transfered several hundred megabytes of data).

You'd think after 5 or 6 years of using Movable Type, I'd at least have a pretty easy time backing it up and restoring it on another server. While it's definitely gotten better from the old days, Movable Type could still use some improvement in the Backup/Restore area.

First of all, the import and export functions in Movable Type don't work. Don't even waste your time trying. The problem I kept having was that the export was only a partial export -- while my blog had nearly 2800 entries, the export was only taking in the first 1600 of those entries, leaving the rest unexported. To make things worse, the import doesn't really work. It'll read the file, tell you that it's successful, but it won't actually create the entries. I even used Movable Type's Import/Export Format along with their instructions on how to export, as well as attempting a customized export. None of these yielded any results.

Since Import/Export didn't work, I decided to try the other way of reading entries into the blog, via the Backup/Restore functions of Movable Type. The documentation for Backing Up and Restoring is woefully incomplete, as it describes how to back up, but not to restore, which is a somewhat more complicated process.

To Restore from Backup, you will need to be in the 'System' Tools Menu. (Restore is not available on the 'Blog' Tools Menu). You will see a box for the backup file. If you click on Browse, you can select your backup manifest file. If you have multiple files and try to restore from the xml files directly, you will get error messages. After it reads the manifest file, it will start to ask for the Movable_Type-Year-Month-Date-Hour-Min-Second-Backup-Number.xml. When you initially did your backup, Movable Type asked whether you wanted the files segmented. I recommend sizes of 1 megabyte or less -- while the option for 2 megabytes is certainly available, most servers/and or browsers will time out before the 2MB file is transfered, and you'll have to start all over again.

One of the early problems that I had restoring the blog from the backup was this puzzling error message:

Uploaded file was backed up from Movable Type but the different schema version () from the one in this system (4.0067). It is not safe to restore the file to this version of Movable Type.

In the interest of saving someone else hours of time in trying to figure this error out, the answer to this is because the XML file created by Movable Type's Backup function doesn't account for the fact that the file is broken up into pieces. For instance, in my case, my blog was broken up into ten 1-megabyte XML files, and only the first file had a full XML header which contained the schema information. Simply copy the first line of the first .xml file and replace the default line with

Save the file in utf-8 format which is the default format that Movable Type generates for the backup file.

As the backup is restored on Movable Type, you should occasionally see that MT:Entry records are being transferred over.and restored. If you saved the xml files as utf-8 character set, there shouldn't be any problem here -- however, if you're using a character set like latin1-swedish_ci, you may end up with errors such as this:

Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) or some kind of perl error.

To resolve this error, make sure the file is saved in utf8 character set.By default notepad and wordpad save in ANSI -- ANSI is not correct and will result in errors..

Provided that you've gotten this far, the only thing left to do now is to restore the files one by one; after all the xml files are restored, then it's time to restore the assets; and you'll need to upload them when prompted one by one.

In any part of these processes if you cancel or get disconnected, you'll have to start over from the manifest, and everytime you attempt a restore, it should create a new blog -- there's no way to really add onto a previous attempt unless you're willing to do some SQL magic.