1915 – What Can I Do?

Interesting question. Now you know what I did when my hosting provider messed up my account, but what can you do, especially when you understood exactly nothing of what I wrote in the last post?

Well, the first thing to realize is, that nobody’s gonna help you. Whatever needs to be done to fix a problem with your blog, you either have to do it yourself, or you have to find (and probably pay) someone who can do it for you. If you do nothing, nothing will happen. That’s just the way it is in today’s competitive server business. Cheap accounts have no regular backups and you can’t rely on your hosting provider to fix anything, most likely, as in my case, you won’t even get a notification when things go wrong.

Thus the most important lesson is, to never trust your data to a system that you can’t manage. Don’t start blogging on your own server, if you can’t fix a server. Use a blogging service like Blogger.com, WordPress.com or TypePad.com instead. They also let you make backups (or “exports”) and restore from a backup.

Be careful with your content though. A backup of the database, that you should regularly make, at least once a week or better after every post, is pretty worthless when you can’t tell from the URLs of your images, what images they actually point to. Can you really match all the texts that you’ve written a year ago with the images that you used in the post? This is a photo blog, but frequently my texts are not about the images at all. I’m sure I would have trouble in more than a few cases.

Thus try to avoid media uploader plugins that create random media file names. Make sure that at least a part of the URL contains the original file name. Also make sure that your original file names are unique. I for instance use the EXIF timestamp as a file name, thus from the image name alone I can tell when I have taken it.

Keep your images on local hard drives. It’s nice and convenient to have things “in the cloud”, but clouds are complex systems beyond your control. They can fail, and because they can, they do.

I have all my images locally, and as a consequence, all I really needed was a database backup. That I could avoid uploading the images again was a bonus, but the database was essential.

Be careful again: a database backup, at least for WordPress, but I suspect that’s true for other systems as well, is only valid together with the particular WordPress version that was used when it was taken. You don’t need to keep many backup generations (though keeping the current backup and the one before that is a good idea), but you probably won’t be able to restore from a really old backup. Thus you need to backup often.

Well, that’s it. Just keep cool, but not too cool. You may regret it.

The Song of the Day is “What Can I Do?” from the 2005 Antony And The Johnsons album “I Am A Bird Now”. Hear the song, with a guest appearance of Rufus Wainwright, on YouTube.

And now please excuse me, I’m going to make a backup 😀

7 thoughts on “1915 – What Can I Do?”

  1. Precise warning you articulated here, Andreas. I experienced pretty much the same when my first hoster terminated my account for alleged violation of their TOS by using too much ressources. I am glad that I had to switch, as the new hoster seems to be much more professional and the server less crowded, but the most glad I am about the fact that my backup strategy worked and – that I could restore. As they say: nobody is interested if you can do a backup, the only thing that counts is if you can do a restore…
    What I do is to daily rsync my web presence on my local NAS and get mysql backups by commandline magic. As I do test major modifications of the blog locally, I was aware of the quirks of the wordpress database.
    In the end it really boils down to the fact that you either have to know your trade, or pay for it, or stay with one of the cost-free solutions (but there you are at the mercy of the company again).

  2. What a nightmare. I’m the most terrible example of someone who not backs up the blog at all. If I would have to restore the images, though, it wouldn’t be that difficult. Most images are so far located on flickr, and linked to the blog. The database, though… I will look for a plug-in, now. Thanks.
    Good for you that you succeed in restoring the site, it would have been terrible, otherwise.

  3. Thanks for the warning!

    I must say that even though I have multiple copies and backup systems of my local data – e.g. the photographs, music and movies – I haven’t made regular backups of my Blogger or Flickr accounts.

    So far so good, though. Anyway, of my photographs the only thing which I really value and want to preserve are the family ones.

    There are new photographs to be taken and new blog postings to be written, so I feel it wouldn’t be too terrible if the blog content at Light Scrape would be erased at some point. It is work in progress anyway, looking forward rather than backward.

    However,I wouldn’t want to lose the content of my Finnish language blog Valopolku where I have written several hundred book reviews. Losing those would be a setback.

    Is there an automatic (Unix command line?) way of exporting the Blogger xml database to a local directory? Putting a backup reminder to the calendar isn’t as good as something which happens automatically.

    1. Juha, you should be able to download the content of any url with the wget command. You can even specify username and password as wget parameters or a special cookie file that should be used. I’ve never tried that with blogger, but it worked well with my previous hoster’s database dumps.

  4. Thanks!

    I searched for recipies on the net and found a script using the curl command. I modified the script heavily and it seems to work.

    However, the bash script requires writing the gmail address and password on the script, so it is not very secure. Maybe I’ll fix this at some point. Would the cookie file be a way to do this?

    In any case, now the script should be running once every week.

    1. Having passwords in clear text in a file is obviously not the best idea, especially if the disk is not fully encrypted. Of course the script could be modified to require the password entry on the commandline, but then it won’t run on its own, started from a scheduler.

      A classic dilemma, where you have to choose between security of the data, security of the password or convenience.

Comments are closed.