A good recovery plan is a necessity to any company
The existence of a coherent and effective Disaster Recovery Plan for telecommunications is of increasing importance to organizations.
While the probability of disasters occurring are low, if that "one in a million shot" did happen, then the impact upon a business is likely to be catastrophic.
Organizations which rely heavily on Information Technology are particularly at risk from disasters. Many organizations are increasingly judged on their ability to survive disasters. Since they affect not only the organization itself, but also their clients, whom rely on the continued and undisrupted service it provides.
The first question a business need to answer is "How long can my business survive without access to the internal data?" The answer should be expressed in terms of minutes, hours, or days.
If the recovery time is in minutes, then database backup and recovery is critical to the business needs and it is paramount that a backup and recovery strategy is implemented . If recovery can take hours, then there is more time to perform the tasks. If recovery can be expressed in terms of days, then the urgency to recover the database still exists, but time appears to be less of a factor.
How to set up a good Backup and Recovery Strategy
For an on-site backup:
|
Develop: Create backup and recovery commands. Test that these commands work as designed. Does your full or incremental online backup work? Verify that your commands produce the desired results. |
|
Time: Time estimates from executing backup and recovery commands to help get a feel for how long these tasks may take. Use this information to identify what commands will be executed and when. |
|
Document: Document the backup commands and create written procedures outlining where your backups are kept and identifying the naming conventions used, as well as the kind of backups performed. This information is very important when an individual must check the backups or perform a database recovery when the database administrator is not available. |
|
Health check: Incorporate health checks into the backup procedures. You should check the database to ensure that the database is not corrupt. You can perform a database health check prior to backing up a database or on a copy of the database from your backup. |
|
Deploy: Deployment of your backup and recovery consists of setting up your backup procedures on the production server. Verify that the necessary hardware is in place, as well as any other supporting software that is necessary to perform these tasks. Change the user id, password, server, and database name to reflect the change in environment. |
|
Monitor: Monitor backup procedures to avoid unexpected errors. Make sure that any changes in the process are reflected in the documentation. |
For Off-Site Recovery:
|
Off-site Location: Establish an offsite location with compatible system and network hardware. Establish procedures for retrieving offsite backups. |
|
Multiple Locations: Keep disaster recovery procedures in multiple locations: at the offsite location with the backups for the operating system, system software, database, and application software, as well as with the individuals involved with disaster recovery. |
|
Test: Schedule regular disaster recovery tests and after each test review the outcome. |
|
Software: Ensure that the disaster recovery procedures contain copies of all installation software and the passwords for the operating system, system software, database, and application software. |
|
Information: Attach a current list of all software vendor names, phone numbers, product support plan numbers, and software license information to the disaster recovery procedures. |
|
Record time: Record the total time required to complete your disaster recovery procedure. |
|
Update: Keep the disaster recovery procedures current and update the copies kept offsite. |
Primary System Backup System