Lots of times when I talk to site owners, one of my first question that I ask them is "what is your backup strategy?"  And shockingly enough I've seen so many with strategies that would make me not want to sleep at night.

I've seen people who are so sure in their code that they decide that they don't actually need to make backups.  Which just tells me how immature they are.  They really think the only thing that could affect their code's well-being is the code itself?  How about the thing that it runs on (i.e. the server)?  They crash from time to time and you lose data.

The next "backup strategy" that I've seen is people use cPanel or some other tool in order to make a local backup of the site and just leave it there.  That's great if your database gets hacked or messed upend you have to revert it. However, what happens if your server goes into an unrecoverable state?  Well then, you are out of luck because you put all of your eggs in one basket.  The funny thing is, sometimes these peoples backup requires them to manually go in and click a button.  I personally would at least look for a somewhat automated approach to doing this because the last thing you would want to do is have to revert your site's content back 1-2 months because you "forgot to take a backup".

Now that we have gone through two of the most common backup "strategies" that I have seen, let me talk about some that I would prefer to see people having.

Code:

• Source Control - in this day in age there really isn't a reason why your code couldn't be in source control.  You can choose the flavour that you would like (be it subversion, git, mercurial, etc), there are normally free services available for private source control repositories.  This means that repopulating your code is a simple "get/pull" command.
• Offsite Backup - Normally fairly cheap to set up (assuming you know how), you can get a virtual private server (VPS) where you just "rsync" or "scp" data from one server to the other.  As long as this is in a different data centre than the main hosting service is, the likelihood of both going down is much lower.  Your recovery strategy would be copy the latest code back to your server and deploy the database.

Database:

• Master/Slave Server - A master/slave server will allow for a constant syncing of your database between two servers.  The actual name varies depending on the platform however they all use the same concepts.  Every X minutes the slave server will poll the master server asking for any new/updated data which it then replays these changes on it's local database and everything.  Then if you are really paranoid (like I am), you could have a backup run off of the slave server every so often that way you have an extra copy of the complete database (which can be stored externally) and it doesn't impact the performance of your actual application.
• Offsite Backup - Similar to code, a database backup is fairly easy to export and ship to another location.  It can all reside in a single file.   Zipping this up and secure copying it to another server will have yet again a bit more overhead when you are forced go into disaster recovery mode.  But, it will at least protect you in the unfortunate event of a server failure.

If you don't take much away from this article, there are two key points that I want you to take away.  

They are:

• Servers fail, make sure you have a backup plan if your primary server goes down
• Don't rely on someone remembering to take a backup of something.  Because it will be forgotten.  Set up some regular scheduled jobs to make your backups and lock them up in a safe facility for you.

I hope you found this informative!

Thanks for reading.