Friday, 13 March 2015
How-to: Develop a backup policy and procedure
You will find no end of statistics on the number of companies that fail and the people who get fired in the aftermath of a data disaster; fire, flood and electrical failures cause interruptions to normal business and if you can't avoid it, the key thing is how you recover and get back up and running.
Your various systems - sales, logistics, HR, payroll, accounts, membership, inventory - these are all databases that contain the data critical to the overall success of your organization; not only does that need to be backed up regularly, but you also need to test the restore process.
That does not change whether all of that resides on premises, at a third party or on-line in the Cloud.
Are you content relying on the standard backup policies of your hosting provider? Don't be. That is just abdicating responsibility for your continued operation to someone else, which may be fine while you sue and counter-sue each other (most contracts aren't worth the paper, etc.). You need your own robust plan and additional backup mechanisms to ensure your data is preserved and protected.
There is no such thing as a universal backup policy for all organisations. You are going to have to perform your own risk assessment based on volumes and usage, nature of the organisation, type of data you are maintaining, level of exposure, and a raft of other factors (like continuing to pay and be paid) to determine what policy to should put in place.
If you really don't know how to do this, there are disaster recovery consultants whose flip-side is to do disaster-avoidance and disaster-mitigation; getting someone external to run a system and organisation analysis, eyes-open, blinkers off, for the purpose of developing a backup policy and procedure statement might be the way to go.
The good ones should tell you:
1) Don't rely on your hosting provider as your sole backup solution. theirs is only a backup of the backup; the first resort but not the last report. Should your systems fail, they may be
able to pull a recent backup and restore it, but there are no guarantees. Suppose you find an error from three months ago and need to wind back your billing system? Can the hosting provider do that?
Unless you put it in the contract and standard operating procedures, you don't have control over how they back up the database and files, when they do it, how frequently they do it, how long they keep the backup sets, how quickly they can provide you the files or restore it for you. Are they tested?
Let the hosting provider perform the standard backups, but consider them your a measure of convenience.
2) Create a formal policy and procedure document; methods, media, frequencies, roles, responsibilities. The who, where, when, what and why. Be clear.
3) Backups should be automated; people are unreliable. The backup needs to happen without the
need for human intervention.
4) Periodically check your backups and verify their integrity. An untested backup is worthless. Discovering at the critical point that your last three month's backups are all corrupted, incomplete and otherwise un-restorable is not conducive to a long career.
Quite how you prove the integrity of your backups is a case-by-case task; at the very least you need to be able import the database dump into an empty database to make sure it is complete and functional.
5) Understand what needs to be included in the backup. The database backup will be vitally important, but what about the rest of the file-system? The application code, changes less and should be contained in a version-control system. And don't forget the file uploads for all the images, PDF's and non-binary blobs that are linked in, but not stored in, the database.
6) Back up to multiple locations, or, backup off-site. You don't want fire and flood taking out the primary system and all the backups in the same building. RC