Restoring Movable Type From Backup

| 1 Comment
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.

1 Comment

"It'll read the file, tell you that it's successful, but it won't actually create the entries."

I found that the answer is usually because your import file is saved as ANSI. Re-save it as UTF-8 (probably without BOM) and try importing again. Unfortunately, you cannot import custom fields, which does, indeed, suck.

Thanks for this entry, though! I am about to redo my site and I don't necessarily want to overhaul if I can't back up properly!

Leave a comment

Recent Entries

10 Things in 2009 Which Will Be Obsolete By 2019
In my vision for 2019, I see some everyday devices and services going away.…
10 Things I Bought in 1999 Which Are Now Obsolete
Everyone is working on their 10/25/50/100 best lists of the year or the decade, for categories like television, movies, music,…
Aliens Vs. Predator Hunter Edition
Now you can own your very own replica facehugger alien in the special Hunter edition of Aliens vs. Predator.…