There are many good Plug-ins for backing up WordPress. None of them did exactly what I wanted. They either did too much, or not enough.
On top of that every time I’ve restored a server backup copy on my development (dev) machine the custom menus and header images inexplicably disappeared.
It’s no good having the best back-up routine in the world if the restore doesn’t quite work!
The disappearing custom header images seems to be a common problem according to Google search results. The common “answer” – upload the header image again through the Admin Appearance Header menu.
Hrumpff! Not exactly an explanation, not even a proper solution. Just another kludge that left you with multiple redundant copies of the header image scattered through the upload directories.
Well, this one time I wouldn’t take “upload it again” as an answer, and went digging deeper for an explanation.
Experimenting on my own site first (this one – www.kathyw.org) and examining the dev server page code compared to the live server gave the first clue. There were some lines of code missing that appeared to be generated out of the database.
The sql backup file was fine, except for discrete references to the live server URL. The usual remedy given – edit the sql file to change the ‘siteurl’ references from the live server URL to the new (in this case dev) server URL. Easy enough. The dev site runs and “looks” just like the live one.
Enter problem #2 – all the images in the “restored” site point to the original site. NOT what you want if you’re going to be moving domains.
So, edit the sql file again, and replace ALL references to the live URL with the dev URL. This can take a while. Update the dev database from the sql file and now with the database image catalogue entries updated the image links all point to the right server.
Enter problem #3 – now the header image has inexplicably disappeared and the menus have reset to default.
So Google some more, and eventually discovered this tasty tid-bit from 2010:
Moved to new subdomain – Lost text widgets and custom header images.
“Sometimes it’s not quite as simple as copying and pasting the new site domain over the old in the database. This is because the information contained in meta_values is often serialized. So it looks like:
“This” (s:69) “basically refers to the number of characters within the quotation marks.”
Serialized data in the database. Hrumpfff!! Their solution – change the s:number to match the new URL length.
If you’re moving domains to a live one that is completely different, this is probably the only other option to manually resetting header images and menus and anything else thus affected.
However, if you are restoring to a development server where you have absolute control over the local URL it’s even simpler. When you do the search and replace on the SQL file to reset the siteurl and image URLs, make sure the new URL is the same length. Make your development virtual server name the same length for example by using (in my test case) www.kathyw.org locally as a copy of www.kathyw.org live.
I wanted to post my solution to the site where I found it as it might help others in the same situation, but alas only their paid-up members can post there. I hope by posting it here it may be discoverable by anyone else wanting an explanation, and an easy solution.
Matching the site URL to the serialized data length using either method above may resolve a number of backup restoration headaches. During one of my first restore tests cForms II managed to corrupt it’s database entry. I manually reset it and restored it settings with a backup txt file from cForms own “Save Settings” on the live server. After the final sql restore with the matching URL/data length numbers cForms II was still working fine and dandy.
The same SQL file was used for all tests, with only the URL references changed with a search and replace.
Off course, having just added this new post, my backup of this morning is now out of date …