It is very important that any production use webserver have a robust backup plan. This generally is accomplished with the combination of a few strategies in order to protect your server from various types of problems.
A good backup plan should first provide you with the ability to save backups of all the important files on the server to an offsite location. This allows you to recover any files accidently deleted / modified by the users, or due to file corruption, malicious malware, etc. We will share some scripts we have used in another post to roll your own scheduled file backups to S3 storage. Files should be saved at minimum at least daily, and for many sites more frequent copies may be desired.
When it comes to modern website applications, most of them rely on databases as well. So you will need to ensure that those databases are also backed up. Often the database and the files should be backed up as closely together as possible, to ensure their are not any concurrency issues. We will share some scripts we have used in another post to roll your own scheduled database backups for both MySQL as well as MS-SQL. If you are having trouble deciding how often is often enough, consider how much data loss would be acceptable to your business. If your website accepts e-commerce orders, and you last all orders from the last 24 hours, would you have the info you need in other places, such as order confirmations in your email?
Disaster Recovery Backups
The idea behind a disaster recovery backup is that there may come a time when you need to restore everything, including the server and its operating system. This can be necessary if the server is no longer functioning properly, or it has been compromised by hackers and can no longer be trusted. To do this manually it can take hours, or sometimes even days of installing software, configuring services, and finally restoring the data itself. With a disaster recovery backup, you can restore to a known working point often in minutes, and then restore the files and data to the most recent point.
A disaster recovery backup does not need to be updated nearly as often, so long as the important file and database data is being backed up regularly. We typically update our disaster recovery backups every couple of months, or whenever we have made significant configuration changes to the server. If you use Amazon Web Services (AWS), Rackspace cloud hosting, or other cloud server offerings, the disaster recovery backup is easily accomplished with imaging or snapshotting the server instance and its related attached storage. If you are still using on-premise hardware for your webservers, you will need to use 3rd-party software for this backup.
A Good Backup Plan Needs Testing
If your business could suffer major losses when your website goes down, a backup plan is not a good plan until it has been tested. Far too many system admins have learned the hard way, and too late that just because a backup said it completed succesfully, that there were crucial files missing, or things that just didn't work as planned. If your site is mission critical, than it is worth the time to occasionally stage a full server recovery on test hardware. Not only does this ensure that your backups are going to work when you need them, it will help you to know what to do to restore them under pressure when it really counts.