Planning disaster recovery ensures that network developers will have an action plan when disaster strikes. Even with a simple action plan, network developers will know where to start and build up the execution.

With a simple plan that only revolves around a concept, the network managers and the whole IT department will have the ability to adjust but it is going to be a lot of work to recover from disaster. On the other hand detailed planning will set network developers with whatever disaster would happen to the network or the entire IT system. Although there are adjustments that should be made, network developers will be able to address the network problem with a detailed planning.

Actual disasters will challenge network developers. As previously indicated, network developers have to adjust to the situation. Most of the time, the detailed planning will never mean anything when disaster strikes if they are not followed up to the heart.

Actual disaster recovery takes on a different level since planning is usually all about sitting down and thinking about the worst case scenario. The actual disaster on the other hand, takes coordination and actual work. Stages have to be observed so that network developers can easily execute the disaster reaction and recovery plan.

I. Problem Detection Stage

Without any notice, network problems could lead to a disaster. If the network problem is not detected as soon as possible, a bigger problem would ensure. That is why it is very important for network administrators to be able to detect the problem as soon as possible. If the network problem is detected earlier, then the issue can be easily addressed.

Once the problem has been detected, it is very important at this stage that the right persons should be informed. This way, the persons who will be getting the hit most with this network disaster will the right preparation such as data backup.

Once the right persons have been notified, it is time to assess the actual damage. Most of the time, the initial information about the problem is just a tip of the iceberg. The whole IT department has to take a look at every network connection and system to ensure that all affected areas are covered.

After damage assessment, the disaster recovery plan has to be implemented. But not all disaster plans was made as a “reactive” answer to the problem. That is where the IT department reviews the disaster recovery plan and modifies them according to the problem.

II. Execution Phase

Executing the network disaster recovery plan is not simple. Adjustments have to be made as soon as the network disaster strikes. The whole IT department has to remember that the solution is not tailor made for the problem.

As previously indicated, network administrators have to assess the damage to their network. This way, they should be able to provide initial remedy to their problem. If a temporary solution has to be implemented, it is going to be in this stage. This should give network developers enough time to adjust their recovery solution plan.

There are two adjustments that the network administrators have to be done. The first adjustment is on the sequence of restoration. Network recovery will not be implemented for everyone at the same time. The sequence for network restoration has to be adjusted based on the most important persons or to those that are hardly hit by the network attack. The next adjustment is on the actual recovery procedures. Most of the time network administrators will have to make some changes in the network recovery plan.

III. Reconstruction Phase

Execution of the network plan not only entails that they answer the network problem. As soon as they answer the network problem, they have to start rebuilding the whole network again. Answering the network problem is just temporary. What is more important is to rebuild the data that was previously lost.

That is why it is very important for network developers to prepare a back-up plan before any network disaster occurs. This will ensure that the data will never be lost. The complexity of rebuilding data in the network depends on the data that was lost. Another variable for network recovery is the amount of data saved. If network administrators have a highly efficient data back-up facility, they should be able to easily restore the network really fast.

Actual network restoration is very challenging since network developers will have to constantly adjust to the situation. As long as there is a detailed plan and a good back up facility, network restoration is very easy and could be implemented in no time.

Restoring Communication after Disaster

Communications are the life blood of any enterprise. Without them, it would be impossible for the enterprise to exist. Therefore, it is critical for enterprises to develop a strategy which can allow them them to restore their communications quickly after a disaster has occured.

Disaster is something that every organization should prepare itself for, since it can happen at any time, and can come in multiple forms. From acts of terrorism to natural disasters like earthquakes and hurricanes, few organizations can afford to be without adequate communications restoration. There are a number of back up tools which are available for this.

While some are relatively simple, others are much more complex. If you want to recover your communications quickly in the face of disaster, one thing that you will want to become familiar with is Exchanges. Many enterprises run full Exchange back ups on a regular basis. Because the Exchange server will make use of the local disks, it is crucial to make use of RAID arrays which are distinct for storing the Exchange transaction logs and the databases. The reason for doing this is because should the RAID array controller stop working, or numerous disks fail, enterprises can still recover.

Should the transaction logs become lost, you will still have the ability to make use of Exchange databases which are up-to-date. If the database drives should become lost, one recovery strategy which you could use would be to use the full backup from the previous day for your Exchange databases, applying the transaction logs of the current day to bring everything up-to-speed. It is crucial to reduce the total size for the Exchange databases, and the reason for this is because this allows each of them to be backed up, and they can also quickly be restored.

Restoration Procedure

The locations in which you choose to place your transaction logs and databases is crucially important. Not only are they important when it comes to back up performance, but they are also important for the speed of the recovery. Most modern servers have support for the redundancy of disk drives, which is commonly known as RAID. RAID is basically a system which gives a disk the ability to crash without causing the whole system to crash. At the same time, the system will perform at a slower level until a new disk is inserted or rebuilt.

Until this occurs, it will be necessary for the array controller to rebuild the data via the remaining disks, and this will need to be done on the fly, and in response to every request that is made for disk access. One of the most powerful features of Exchange is the single instanced database structure it uses.

Inside the Exchange database, only one copy of a certain message will be contained, in addition to one attachment. If this message is sent out to more than one recipient within the identical data store, more pointers towards the average will be attached. At the same time, the objects will not be duplicated.

This is highly beneficial, because it means that the efficiency of the delivery will be very high, and it can also function as a saver for space for Exchange. This goes for the disk as well as the tape. While it is true that Exchange is quite useful when it comes to recovering both the database and communication, this also means that the whole tape must be brought back first. One solution which was introduced for this issue is the Brick Level Backup. However, some experts don't recommend this. Once the total back up for the exchange database has been made(via the recommended ESE Backup), the products can be added to every mailbox within the backup tape.

Communication Recovery Practice

One thing that many enterprises have learned the hard way is that no matter how sophisticated their communication recovery mechanisms are, they are of little use if the enterprise does not regularly practice their implementation. If you are the administrator of an organization, you do not want to find out whether or not your communication recovery mechanisms will work in the face of a disaster. The ideal time to test your communication recovery tools is the day after they have been implemented. It should be done before a lot of users start using it.

If you are working with Exchange, I would advise you to run a complete Exchange Full Backup, along with the regular checkup of your harddrive, and also capturing the System state. The System state should include the files on the system disk which you deem to be critical, along with the IIS metabase, which is the location in which the routing configuration for exchange will be held.