Being wholly unimpressed with the implications of a purely XML backup option for my databases, I sought further options.
Oh wait, you cannot believe how moronic a solution like backing up an RDBMS to XML is? Neither can some other people.
Firstly, let’s discuss the specifics of an XML backup solution. Or better yet, let’s look at the size of an exported SQL file in comparison to its XML equivalent.
I chose to backup *all* tables relating to my WordPress installation, excluding Spam Karma’s blacklist, and spam entries logs. They exceed 80 Megabytes in case you are wondering why.
So, I am left with a gzip’d SQL file containing *EVERYTHING* needed to fully restore my WordPress blog. That means, all my author’s, subscriber’s information, all their comments, and all of my posts and comments, including categories and related tags.
The file is a whopping 234 Kilobytes. The XML file is 1,620 Kilobytes (1.6 Megabytes roughly).
To be fair, let’s go ahead and gunzip (decompress) the SQL file. OK, now we have a file 1,163 Kilobytes (1.1 Megabytes roughly). Still 457 Kilobytes less than the XML option, that’s almost a half a megabyte!
Here is the kicker though. The XML export option backs up *only* core WordPress tables. There is no option to add additional tables, thereby limiting the effectiveness of the XML backup solution. In fact, I retract calling it a solution.
The SQL file on the other hand, contains all the relevant information to create anew, rebuild, restore, or share with another RDBMS. Granted you may need to run a conversion on the storage engine to insure compatibility, but this is a trivial item in and of itself.
The XML file contains WordPress-specific code, and I am sure anyone bothering to read this understands the dilemmas raised from proprietary standards. Also, the XML file is cluttered with markup, whereas the SQL contains relevant field data type and values only.
Granted, this may become a full-fledged backup solution, but I don’t see it happening anytime soon. XML as a storage solution is simply not a mature technology. The closest thing I have seen to XML as a backup is Runtime’s DriveImage XML.
1. Matt Mullenweg/Automattic will most likely never listen to reason and provide options to backup whichever tables the user sees fit.
2. I wonder which brave soul is going to write the ridiculously regressive “WordPress WXR/XML to SQL” plug-in. Or other such application: “to Blogger,” “to TypePad,” hell, even “to Habari.” I bet Skippy would just love that one.
3. I wonder which slightly less brave soul is going to add to the mess, kiss Mullenweg’s arse, and add the aforementioned items for him. Seeing as how if it is in development, Mullenweg’s code release cycle will dictate it takes far much more time than it should.
Some of the politics that the egomaniacal “#1 most important Matt in the world” religiously lives by can be seen in this post by Scott Merrill, er… Skippy.
In fact, it is in part due to this “Autocrattic” imperialism that we, as loyal WordPress users have been deprived an ingenious programmer, and author of *several* well known WordPress plug-ins.
As a side note, I have had issues with DreamHost before, but all in all have been more than satisfied with them. One thing that I can say about them is that they are Nazis when it comes to security risks and updates.
If there is a problem with *anything* to do with any of their One-Click installs, versions of whatever server-side technology, vulnerabilities in kernels… *anything*… they are on it.
Despite having the fanciful XML export feature, DreamHost, by default in it’s WordPress 2.2 One-Click install still offers Skippy’s original wp-db-backup 1.7.
As far as I can tell, the one and only vulnerability to ever be reported (at least publically), and the solitary bug it had, are both patched in the version DreamHost has.
If it’s good enough for DreamHost, it’s definitely good enough for me.
Of course, Skippy has discontinued this, and several other plug-ins, so some may find a better alternative in the new maintainer, Austin Matzko or an entirely separate plug-in altogether.
A note on the first one though, it does not support gzip’ing the resulting SQL as far as I can tell. That is a definite no-no in my book. Another reason why I won’t be upgrading.