A while ago I posted about a software product that lets you run backups and store them on Amazon.com’s S3 data center service. It was an interesting idea, but mostly it got me thinking about how to determine an optimal backup strategy for other board owners. I do my backups every night. I guess I should actually say I never do backups; I have a script do them for me instead. That’s one aspect to consider when setting up a backup strategy for your board.
For this post I would like to cover what are probably some fairly obvious concepts for experienced board owners. The first question that needs to be asked is: What do I need to include in my backup strategy?
Code and Data
There are two components of your board: code and data. If you need to move or restore your board you need both parts; one is useless without the other. I will submit that data is more important than code. If you have code with no data, you’ve lost what makes your board unique. If you have data with no code, you can at least download a free set of code for phpbb and use it. But the question remains… what should I include in my backups? The answer is, of course, both.
Backing Up Source Code
There are some folks that run very sophisticated code management systems. They might include SVN (an open source code management system, link at end of post) or something similar. I don’t do that. Sometimes I wish I did but I have never needed anything that complex because I am the only developer on the system. I don’t have to deal with supporting more than one developer. I could use a system like SVN for tracking code changes, but so far I have not needed anything that sophisticated.
But I do back up my code. It’s not done on a scheduled basis, because code changes only happen when I make them. I started off on a tangent about my development process and decided to move all of that information to a new blog post rather than here, so for now let me just assume that there are code changes that happen. Before I put new code onto my production web server I will make a copy of the existing code and keep it easily available on the server. If some sort of bug managed to slip through my testing, I need to be able to fix it immediately, or if I cannot, I have to copy the old code back so that the board doesn’t go down. Once the the board has been updated and verified then the copy of the code will be downloaded off of the server and archived on my home network. I include a “readme” file that details the changes made and store it with the copy of the code.
I then will also make a copy of the current production code, and that is also downloaded to my home network. In the event of a hardware failure I would restore my code backup to a new server and follow that with my most recent database backup and my site is up and running. Which brings me to the next concept…
Backing Up Your Database
Code is not supposed to change unless you know about it. Database content can literally change every second. For that reason it is much more important to make regular database backups as compared to your code backup process. How often do you back up your database? There is a simple answer to that… how much data are you willing to lose?
I used to run my database backup process on Saturdays. That worked fine until I messed up the database on Thursday afternoon. By going to my backup file I lost everything that happened from Sunday through Thursday afternoon, or over 100 hours of board activity. With the level of activity I had at the time, that was about 50 new users.
I now run my backup process every night, so the maximum data loss would be one day rather than 4+ days that I had lost before. Of course my board is a lot more active today than it was years ago. An average twenty four hours of activity on my board today is:
- 31 new users
- 387 new posts
- 77 new topics
Are daily backups enough, given this information? For now, yes. At some point I may shift to capturing the data every six hours (four times a day) to cut down my potential losses, but for now I am comfortable with these numbers.
Next Post: Database Backup Scripts
In the next post I plan to go into more detail about how I manage the automatic database backups. It’s fairly simple (which is good) and automatic (which is even better).