Website Data Backups with Version Control

I’ve been tasked with revamping the backup strategy at my new job, and I think I am finally happy with what I’ve come up with. As usual, I’m wondering what others have done when they were tackling such a task, and what you, dear reader, think about my setup. Please leave me a comment if you want to share your thoughts, or links to articles you’ve read that relate to anything discussed here (along with a short description of how it relates).

With websites, it appears there are three distinct data components that require backups: Code, content files, and the database. If you implement a well-thought-out version control setup, you can keep only one backup of the current repository, since it in itself contains all the revisions.

  • Code only ever changes when the developer makes an update, and always changes on the development server (I swear!). The developer commits his changes to version control manually, and then uses a deployment automation tool to publish the changes to the production server.
  • With content files and the database, the changes are mainly done on the production server, and since we are not going to ask the user to commit to our version control system, this should be automated, either at intervals, like daily – or if it is plausible – just-in-time, directly triggered through the CMS when content is added.)

With incremental backups to Amazon S3, we used to pay about $1/month for this service at the medium-size call centre I used to work at, so that part should be fairly inexpensive, but the overall cost of this setup is significantly higher if you are paying for a hosted VCS.

Again, I would really appreciate your thoughts on this, and links to articles written based on what others have learned from experience in this area. Thanks for reading!