I recognised same problem and therefore I would not rely on the XML backup generated with the Tools/Export command. I now use to test first by repeating the Export several times and then compare the sizes of the XML-files generated.
With a 110 post WordPress blog (+ about 200 kbp images) the xml file-sizes varied between 271kb up to 908kb. The 908kb variant was generated 3 times (out of 23).
When I opened this 908kb file (using WordPad, that shows it in a nicely structured manner), I found that only those few ones had the correct </rss> tag at the end and also contained all posts.
All the other XML files (with smaller file sizes) appeared to be truncated, contained only the earlier posts and did not had the </rss> tag at the end. This indicates to me that it is a problem appearing randomly during download of the XML-export file, but not a systematic disability of WordPress to export XML-backups above a certain size. I guess that the larger the blog is, the more likely it is that the XML-backup will be truncated.
Somebody sugegsted that the transfer from the server is timed out. I also recognised in the Download-Window, that the transfer rate dropps before transfer ended of the truncated files.
Therefore, the only advice I can give is to repeat the export as often as possible, than use keep the XML-file of the largest size.
This one will have the largest part of your blog. To make sure if it has indeed the complete blog, open it in wordpad and check if it contains the </rss> tag at the very end.
Thread Starter
cswake
(@cswake)
My intuition that this is related to the webhosting service… who is yours? (1&1 shared here) Your comments are not reassuring about the WordPress export. 🙂 However, I’ve been using the iDrive and WP-DBManager to successfully do backups instead.
@cswake: the problem might be that your database is very large from post/page revisions and 1and1 (not the best host out there) might be choking on the size and timing out. Try using http://ww.wp.xz.cn/extend/plugins/better-delete-revision/ to delete post/page reviisons and bring the overall size of the database down. Revisons aren’t inlcuded in the XML export, but may be effecting the database server due to the large size of the database that it’s trying to process and export from.
@persian cat: There are some problems with the XML export, namely duplicatiing categoeies on large exports with hundreds of categories, but that sounds like a hosting problem. Try http://ww.wp.xz.cn/extend/plugins/better-delete-revision/ and also a few exports without images.
@persian cat and @cswake: and increasing the memory for PHP and WordPress by editing the memory_limit line in your php.ini (if you have access to it) to 64M:
memory_limit = 64M;
If no php.ini, or add this line at the top of .htaccess file:
php_value memory_limit 64M
If that doesn’t work, add this line near the top of your wp-config.php file (right after the opening php )
define('WP_MEMORY_LIMIT', '64M');
Hi, I”d like to add to my recent post an important update: Just by chance, I was offered today a migration “to a new server platform”, when I logged into my web-hoster (STRATO). I agreed and after a single mouse-klick and virtually 4 seconds time the migration was completed by STRATO (sorry, hope nobody blames me for making advertisement for them: I”m sure there are many others and equally good hosters around).
When I again used the Tools/Export command from my WP blog, the transfer was suddenly about 4 times faster than before. Before this migration, transfer always started with 16kb/s and continiously went down during the process to 4kb/s, before it stopped and produced the truncated XML-files mentioned in my post before. The total download time for the truncated files (ranging between ~ 200kb and ~900kb) was around 1min 40sec.
Now, it transfered a 992kb XML file (complete blog with all posts and with the final </rss> tag at the end) within 20 sec.
So for now, the problem with truncated exports seem to be solved. I don”t know, however, what happens if in the future my blog size will be larger, a couple of Mb or so. It might be, that even with this higher transfer rate I will run into the same problem again, as soon as the total download time exceeds 1min 40 secs.
Thread Starter
cswake
(@cswake)
Thanks songdogtech for the suggestions, unfortunately none of them work. I’ve been digging around about 1&1 shared hosting and it seems that they have 12mb/20mb PHP limits as of September 2010:
http://austinpassy.com/2009/08/annoyance-1and1-shared-hosting/
http://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/500-errors-1and1-webhost/
Should I lower the values you provided to 12?
No, you’re probably out of luck. 1and1 isn’t the best host out there. You might have to upgrade to a better hosting package with them just to be able to export.
You may have to use phpmyadmin to manually delete post/page revisions to bring the database down to as small a size as possible, and then export the whole database via phpmyadmin and import it where you want to go.
