Backing up your Blog

It was a very scary moment. I was looking at the home page of my blog, and there was nothing but a WordPress database error of some sort. The irony of it was that I had just gone in, for the first time, to try and protect the history of the blog with the first backup I have ever done of it. And the process had somehow blown it away. Basically, I had gone through the following steps:

  1. Ran PhpMyAdmin, the admin tool for the SQL database
  2. Selected Export
  3. Checked the Gzipped box at the bottom
  4. Clicked on “Go”

Supposedly, this procedure is 100% safe. However, it seems that there is a microscopic chance that the database might be in the middle of an update while it is being written out (so I am told). This seems so 1950′s to me. When I was first learning computer science back in the late 1970′s, the idea of preventing access by others to a computer asset when you are using it was already old.

Be that as it may, matters were made worse by the calls to my hosting company, iPowerWeb. They told me that the Export operation in fact “emptied” the database. While this did not make sense to me, I have no experience at all with SQL, so it added to the fear of the situation (by the way, it’s not true either)

So I got their help to do an import of the backup file I had created. However, at my request, they did not overwrite the original database file, and uploaded it as a new file. However, when they were done, I was still left with the task of getting WordPress to use the new database as opposed to the old one.

I was not willing to do this on my own, as I simply did not want to make a mistake at this point. So I called back the tech support team, and found out that everyone there competent enough to address the problem had gone home! So I was basically flushed for the night, at least as far as they were concerned.

Fortunately, I got one of the people who works with me that has a good background in SQL on the phone. In short order we figured out that the original database still had all the data in it. A little bit later, we decided to run a repair operation on the database, which is easy to do right from the main Admin screen.

Bingo! We were back up and running. It had been a very upsetting sequence of events.

Nonetheless, in its own odd way, it underscored the value of backing up. Weird stuff still happens to your data from time to time. I am not naive about this stuff, so it’s not really black magic to me.

Most likely what happened is that some other application was trying to update the data right at the time I was backing it up, and the simultaneous operations corrupted it. It’s a shame, really, because this can only result from sloppy programming, as it’s 100% preventable. However, this is why we backup. Humans are involved in designing and implementing the programs we use, and they are prone to error.

Comments

  1. says

    It is amazing some of the errors you can get with SQL, but they only really pop up when you are doing a massive task like that.
    I wrote an indexer which requires approximately 10,000,000,000 SQL requests, and every time it runs there are about 10 requests which just fail because (it happens) someone browsing the site is looking at the same field at that exact second.
    It is easy to write your code so this has no effect, but I could browse my site for years and never see it have an effect, as it will only occur about one time in one thousand million (I think thats what you americans call a billion). Even then, though, do you want to leave that one user with a partial content header?

Leave a Reply

Your email address will not be published. Required fields are marked *

*