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 😄
Markus (2012-01-15)
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).
💬 Reply 💬